# FDE W5D4 评测题 · 业务状态归属与审计 > 配套手册：《FDE-W5D4-业务状态归属与审计-学习手册.html》 > 满分约 117 分。L1 基础(24) / L2 进阶(36) / L3 深度(40) / L4 场景(17)。 > 评分建议：L1≥20、L2≥30、L3≥32、L4≥14 为各档达标；总分 ≥93（约 80%）为本次达标线。 --- ## L1 基础（Q1–Q3，各 8 分，共 24 分） ### Q1. 业务状态归属原则是什么？请用一句话概括。 - **考察点**：归属原则的核心。 - **评分维度**：Agent 不拥有业务状态（3 分）；只驱动流程（2 分）；权威副本在业务系统（3 分）。 - **参考方向**：Agent 是流程驱动者而非业务状态 owner；理赔单/审批/金额的权威状态在业务系统（事务+状态机），Agent 只读或经授权写。
参考答案 一句话：Agent 只驱动业务流程，不拥有业务状态；理赔单状态、审批结论、报销金额的权威副本必须由业务系统（带事务+状态机）持有，Agent 仅读取或经授权写入。 区分：Agent 内部的工作态（当前步骤/已收集字段，存 Checkpointer）是临时态，不是业务真相。
### Q2. 审计的"四要素"是什么？各举一个保险场景例子。 - **考察点**：审计基本要素。 - **评分维度**：who/what/when/result 四要素（各 1.5 分）；保险例子（2 分）。 - **参考方向**：who（谁查了病历）、what（调 query_policy）、when（时间戳）、result（成功/拒绝+金额/原因）。
参考答案 四要素： - **who（谁）**：操作者身份，如保单持有人、理赔员角色、Agent 实例 ID。例：用户 U123（policy_holder）查询。 - **what（做什么）**：动作，如调用 query_policy、提交 submit_claim、模型给建议。例：调 query_policy 查特药目录。 - **when（何时）**：精确时间戳（含时区）。例：2026-07-23T10:23:45+08:00。 - **result（结果如何）**：成功/失败/拒绝+关键输出。例：SUCCESS 返回可报 60%，或 DENIED（无权限）。
### Q3. 为什么"Agent 算出报销金额"不能直接当成理赔结论告诉用户？ - **考察点**：业务状态 owner 与责任。 - **评分维度**：模型可能错/不一致（2 分）；无事务保障（2 分）；应由理算系统落库+审批确认（2 分）；可追责（2 分）。 - **参考方向**：模型算错=错赔；金额必须经理算系统落库、审批确认才生效；Agent 只展示建议/测算值。
参考答案 - 模型输出不可靠：算错（如把目录外药算成可报）就是错赔，且前后可能不一致。 - 无事务/一致性保障：Agent 侧没有数据库事务，崩溃/重启后结论可能丢失或变。 - 正确做法：Agent 调用"理算工具"得到返回值，金额必须经理算系统落库、审批人确认后才生效；Agent 可展示"建议/测算值"，但不自行宣布赔付结论。 - 可追责：谁对理赔结果负责？必须是业务系统+人，不能让模型当黑盒裁判。
--- ## L2 进阶（Q4–Q7，各 9 分，共 36 分） ### Q4. Agent 在企业架构里扮演什么角色？请说明"驱动者 / 建议者 / 非所有者"三者。 - **考察点**：Agent 角色边界。 - **评分维度**：三角色各 2 分；边界利于可追责（3 分）。 - **参考方向**：驱动者=编排/调工具；建议者=给推荐但最终决定权在人/业务系统；非所有者=不持权威状态、不独担责。
参考答案 - **驱动者（Driver）**：编排流程、调用工具、汇总信息、在授权内执行动作。 - **建议者（Advisor）**：给出推荐（如"建议报销 60%"），但最终决定权在业务系统/人。 - **非所有者（Non-owner）**：不持有权威业务状态，不独自对业务结果负责。 为什么这样边界：让责任链清晰——出问题能分清"模型建议错/业务系统判错/人批错"。若 Agent 既当运动员又当裁判（拥有状态又下结论），责任链断，合规无法交代。
### Q5. 一个企业级审计条目应至少包含哪些字段？说明 request_id 和 parent_event_id 的作用。 - **考察点**：审计字段设计。 - **评分维度**：列出关键字段（session/agent_id/who/what/args_digest/result/when/latency/token/model版本，4 分）；request_id（幂等对账，2 分）；parent_event_id（因果链，3 分）。 - **参考方向**：字段清单；request_id 与重试/补偿去重同源便于对账；parent_event_id 串起一次会话的因果树。
参考答案 关键字段：event_id、session_id、agent_id（实例/版本）、who（user_id+role）、what（工具/决策）、args_digest（脱敏摘要）、result、request_id、when、latency_ms、token_cost、model、parent_event_id。 - **request_id（幂等键）**：和 W5D3 重试/补偿同源，审计里记它便于对账"同一请求重试了几次、是否重复提交"。 - **parent_event_id（因果链）**：指向触发本事件的上游事件，把一次会话的 N 个动作还原成树，出问题能回溯完整链路。 - 隐私：敏感入参（身份证）不存明文，存 digest/脱敏值。
### Q6. W4 的 HITL（人在环）和"业务状态归属"有什么关系？ - **考察点**：HITL 与状态归属的衔接。 - **评分维度**：HITL 是高风险状态变更节点（3 分）；Agent 不替人决定（3 分）；审批必须留痕（2 分）；Checkpointer 暂停+恢复（1 分）。 - **参考方向**：人工审批=状态变更关键节点；Agent 发起/准备/等结果，不替人做赔付审批；审批由人+业务系统落库留痕；HITL 处 Checkpointer 暂停。
参考答案 关系：HITL 本质是"高风险业务状态的变更节点"，正好落在状态归属边界上。 - Agent 发起审批、准备材料、等结果，但不替人做"赔付审批"这个权威决定——决定权交还人。 - 审批由人+业务系统落库，是审计里最关键的一条（谁审批、何时、基于什么材料、结论）。 - 技术衔接：Agent 在 HITL 处用 Checkpointer（W5D1）暂停，审批结果回流后从断点恢复，业务状态由审批系统持有。 这正是"Agent 不拥有业务状态"的最直接体现，也让 Agent 在强监管场景"可被接受"。
### Q7. "有日志"就等于"可追溯"吗？请说明真正可追溯需要什么。 - **考察点**：可追溯的内涵。 - **评分维度**：指出不等（2 分）；因果链 parent_event_id（3 分）；防篡改 WORM（2 分）；模型决策也留痕（2 分）。 - **参考方向**：孤立日志还原不出"为什么赔"；需因果链串联、防篡改、覆盖模型决策步骤。
参考答案 不等。"有日志"只是零散记录；真正可追溯要： 1. **因果链**：用 parent_event_id 把事件串成树，能还原"谁→基于什么输入→调了什么→模型怎么建议→人怎么批→怎么落库"。 2. **防篡改**：WORM/追加日志，防止事后改历史（监管证据必须可信）。 3. **覆盖模型决策**：模型的"建议报销60%"也要留痕（输入摘要+输出），否则出现错赔无法举证"基于什么材料建议的"。 4. **版本可追溯**：记 model/agent 版本，模型升级后能定位当时用的哪版。
--- ## L3 深度（Q8–Q11，各 10 分，共 40 分） ### Q8. 如何设计"业务状态"与"Agent 工作态"的分层存储？为什么不能混在一起？ - **考察点**：状态分层设计。 - **评分维度**：业务态在业务系统（DB+状态机，3 分）；Agent 工作态在 Checkpointer（临时，3 分）；混用的危害（错配/责任乱/合规污染，4 分）。 - **参考方向**：业务真相归业务系统带事务；工作态临时存 Agent 侧；混用会导致用户看到草稿当生效、对账困难、审计台账被污染。
参考答案 分层： - **业务状态**：理赔单/审批/金额，存业务系统（DB+状态机+事务），权威、一致、持久。 - **Agent 工作态**：当前步、已收集字段、中间草稿，存 Agent 侧（Checkpointer/外部存储），临时性、可丢失重建。 为什么不能混： 1. **错配**：用户可能把 Agent 草稿当成已生效结论，造成误解/纠纷。 2. **责任混乱**：出事时无法判断"是业务系统判错还是 Agent 自己改的"。 3. **合规污染**：把临时工作态混进合规审计台账，会稀释"业务真相"记录，监管不认。 设计：两者用不同存储、不同生命周期、不同审计策略；Agent 显示给用户的状态要标注"草稿/测算"vs"正式"。
### Q9. 审计字段里的敏感信息（如患者身份证号）应该怎么处理？为什么不"干脆不记"？ - **考察点**：隐私与审计平衡。 - **评分维度**：脱敏/摘要/digest（3 分）；权限访问+加密（2 分）；不记=放弃合规（3 分）；只读也要审计（2 分）。 - **参考方向**：敏感字段存 digest/脱敏值不存明文；访问受控加密；"不记"等于放弃合规（谁查了隐私必须可查）；读操作也审计。
参考答案 处理：敏感字段（身份证/病历号）不存明文，存脱敏值或 digest（sha256 摘要），且审计库加密、访问受控（最小权限）。 为什么不"干脆不记"： - 保险/个保法要求"谁在何时查了患者隐私"必须可查——不记等于主动放弃合规，出现隐私泄露/滥用无法举证。 - 只读操作也要审计：谁查了患者病历是合规范重点，只读不记会留下监管缺口。 平衡：脱敏记摘要而非不记；审计落库失败要告警降级，不能静默丢。
### Q10. Langfuse 这类观测平台和"合规审计系统"有什么区别？生产中如何配合？ - **考察点**：观测 vs 合规审计。 - **评分维度**：Langfuse 能力（Trace 树/成本/延迟，3 分）；不等于合规（不保证 WORM/防篡改，3 分）；配合方式（互补：Langfuse 管运维期、合规台账独立防篡改，4 分）。 - **参考方向**：Langfuse 偏工程观测/调试；监管可能不认其默认存储；合规审计台账要独立防篡改落库；采样 vs 全量。
参考答案 区别： - **Langfuse 等**：开源 LLM 工程观测，把 LLM 调用+工具调用串成 Trace 树，自动记 user/session/request_id/成本/延迟，偏"开发运维期可追溯/调试/评测"。 - **合规审计系统**：监管要求"不可篡改证据链"，通常要 WORM 存储、独立落库、全量（关键业务不采样）。 Langfuse 默认不保证防篡改，监管可能不认——"接了 Langfuse 不等于合规"。 配合：两者互补。Langfuse 管日常运维追溯与调试；合规审计台账独立防篡改落库，覆盖必记字段（who/what/when/result+因果链）。敏感字段进 Langfuse 前脱敏。关键业务审计全量，Langfuse 可对非关键采样。
### Q11. 如何监控"Agent 态"与"业务态"的一致性？为什么要做？ - **考察点**：状态一致性监控。 - **评分维度**：对账手段（定期比对/事件驱动，4 分）；为什么做（错配误导用户/合规/责任，3 分）；审计落库失败告警（3 分）。 - **参考方向**：定期比对 Agent 显示态与业务系统真相；HITL 暂停期间易错配；审计写失败要告警降级；不一致要报警并修复。
参考答案 监控： - **定期/事件驱动对账**：比对 Agent 侧展示的状态（如"待审批"）与业务系统权威状态（如已"拒赔"），不一致即告警。 - **关键节点校验**：HITL 暂停/恢复、补偿/回滚后，主动核对两边状态。 - **审计落库监控**：审计本身写失败要告警+降级（本地缓存重发），否则合规出现缺口。 为什么做： - 错配会误导用户（Agent 显示"待审批"但业务已赔付/拒赔）。 - 合规：监管要的是业务系统真相，两边不一致时责任说不清。 - 故障排查：能快速发现"是 Agent 卡住还是业务系统已变"。
--- ## L4 场景（Q12–Q13，Q12 9 分 / Q13 8 分，共 17 分） ### Q12. 场景题：特药理赔 Agent 给出"建议报销 60%"，用户据此以为赔定了，但实际理算系统算的是 40%且需人工审批。这暴露了哪些设计问题？你怎么改？ - **考察点**：状态归属 + 展示边界的实务。 - **评分维度**：问题（Agent 把建议当结论展示、没区分草稿/正式、缺人工审批节点，4 分）；改法（展示标注"建议"、结论归理算+审批、HITL 留痕，5 分）。 - **参考方向**：问题=混淆建议与权威结论、未走审批；改=UI 标注测算值、金额经理算落库+人批、审批留痕、暂停恢复。
参考答案 暴露的问题： 1. **混淆"建议"与"权威结论"**：Agent 把模型/工具返回的测算值当成赔付结论展示，用户误以为生效。 2. **未区分草稿/正式态**：展示层没标注"建议/测算"，与业务系统权威态混同。 3. **跳过人工审批**：60% 这类结果本应经理算系统落库 + 人工审批（HITL）才生效，却直接呈现。 改法： - 展示层明确标注"测算/建议值，以审批结果为准"，不显示成确定结论。 - 金额必须由理算系统落库为权威值，Agent 只读取展示。 - 引入 HITL：Agent 准备材料→触发人工审批（Checkpointer 暂停）→人批后业务系统落库→结果回流→Agent 展示正式结论。 - 审批动作留痕（who/when/基于什么材料/结论），作为审计关键条。
### Q13. 场景题：监管来检查一笔"错赔"理赔，要求还原完整证据链。你的 Agent 系统要能交出什么？怎么保证这些记录没被篡改？ - **考察点**：可追溯 + 防篡改综合。 - **评分维度**：能交出的证据链（会话 Trace/工具调用/模型决策/审批/落库，4 分）；防篡改手段（WORM/追加/权限/版本，4 分）。 - **参考方向**：交出 who/what/when/result + 模型输入摘要+建议 + 审批结论 + 理算返回 + 因果链(parent_event_id)；防篡改用 WORM、权限隔离、model 版本、独立合规台账。
参考答案 能交出的证据链： - 会话级 Trace：session_id 下所有事件（LLM 决策、工具调用）用 parent_event_id 串成树。 - 每次动作审计条：who（用户/角色/Agent 实例）、what（调了 query_policy/理算/提交）、when、result（含返回金额/拒绝原因）、request_id（幂等）。 - 模型决策留痕：输入摘要 + "建议报销 60%"输出 + model/agent 版本。 - 人工审批：谁审批、何时、基于什么材料、结论。 - 业务系统落库记录：理算返回 40%、最终状态变更。 保证未篡改： - 审计用 WORM/追加日志存储，禁止更新历史，只能追加。 - 访问权限隔离（最小权限 + 审计员独立）。 - 记 model/agent 版本，证明"当时用的哪版"。 - 合规审计台账独立于观测平台（Langfuse）防篡改落库，关键业务全量不采样。
--- ## 评分汇总表（满分 117） | 题号 | 级别 | 主题 | 满分 | 你的得分 | |----|----|----|----|----| | Q1 | L1 基础 | 归属原则 | 8 | | | Q2 | L1 基础 | 审计四要素 | 8 | | | Q3 | L1 基础 | 金额非结论 | 8 | | | Q4 | L2 进阶 | Agent 三角色 | 9 | | | Q5 | L2 进阶 | 审计字段 | 9 | | | Q6 | L2 进阶 | HITL 与归属 | 9 | | | Q7 | L2 进阶 | 可追溯内涵 | 9 | | | Q8 | L3 深度 | 状态分层 | 10 | | | Q9 | L3 深度 | 隐私与审计 | 10 | | | Q10 | L3 深度 | Langfuse vs 合规 | 10 | | | Q11 | L3 深度 | 状态一致性 | 10 | | | Q12 | L4 场景 | 建议当结论 | 9 | | | Q13 | L4 场景 | 监管证据链 | 8 | | | **合计** | | | **117** | | **达标线**： - 各档：L1 ≥ 20 / L2 ≥ 30 / L3 ≥ 32 / L4 ≥ 14。 - 总分 **≥ 93 分（约 80%）** 为本次面试达标；≥ 105（约 90%）为优秀。 - 任一 L3 题得分低于 6 分，建议回看《FDE-W5D4-业务状态归属与审计-学习手册.html》对应章节重做。