FDE W5 Day 4 学习手册 · 业务状态归属与审计
W5 Day4 · A 级（必须掌握，面试核心）· 4h · 学完能讲透"业务状态由谁拥有（Agent 不拥有）、审计字段怎么设计、为什么企业级必须可溯源"
本日定位： 前三天讲"Agent 自己的状态"（Context/Checkpoint/Runtime）。Day4 讲更关键的边界——业务状态（理赔单、审批）不归 Agent 所有 ，以及"每一次动作都要留痕"。这是企业级 AI 合规的底线。学完能回答： ① 业务状态归属原则（Agent 只驱动、业务系统才拥有）；② 审计字段设计（who/what/when/result）和为什么企业级必须可溯源；③ 与 W4 HITL 的关系（人工审批是状态变更关键节点，必须留痕）。使用方法： 通读原理 → 重点看「工程含义」「面试话术」「易错点」→ 做自测清单 → 配合《FDE-W5D4-评测题.md》。选中不熟的词可标注（左下★重要 / 右下📌待查）。候选人背景：36岁，Java+大数据+医疗保险行业，示例围绕特药理赔/保险知识库。
一、业务状态归属原则：Agent 不拥有业务状态
核心原则一句话：Agent 是业务流程的"驱动者"，不是业务状态的"所有者" 。理赔单状态、审批结论、报销金额——这些是企业核心业务数据，必须有唯一可信的 owner，而这个 owner 是业务系统（核心交易/理赔系统） ，不是 LLM Agent。
Agent：提议 / 推荐 / 执行动作（在授权内） │ 业务系统：拥有状态、做最终权威记录、保证一致性
Agent 内部状态 （当前步骤、已收集字段、中间草稿）可以存在 Agent 侧（W5D1 Checkpointer），但这是"临时工作态"，不是业务真相。业务状态 （理赔单=已提交/审批中/已赔付）的权威副本必须在业务系统，Agent 只读或经授权写入。
把"业务真相"放在 Agent/LLM 侧是灾难：模型可能前后不一致、可能被注入改口、可能崩溃丢失。业务系统用数据库事务 + 状态机保证权威性和一致性，这才是 owner 该做的事。Agent 只是"聪明的操作员"。
原则：Agent 不拥有业务状态，只驱动流程。理赔单/审批的权威状态归业务系统，Agent 只读或经授权写。Agent 内部的中间态只是临时工作态，不是真相。
① 最危险的错：把 Agent 里"算出的报销金额"当成理赔结论直接展示给用户，而不写回业务系统由它确认——模型算错就是错赔。② Agent 的"草稿态"和业务系统的"正式态"要区分清楚，不能让用户看到草稿以为生效。③ "Agent 拥有状态"会让职责混乱：谁对理赔结果负责？必须是业务系统，可追责。
二、业务状态由谁拥有：业务系统才是 owner
状态 owner Agent 的角色 理赔单状态（草稿/已提交/审批中/已赔付/拒赔） 理赔核心系统（DB + 状态机） 触发状态流转（提交/查询），不自行判定 审批结论 审批系统 / 人工审批人 准备材料、发起审批、读结果 报销金额 计费/理算系统 调用理算工具，展示工具返回，不自己拍板 Agent 工作态（已收集字段/当前步） Agent（Checkpointer） 自管，临时性
示例：特药理赔 Agent 算出"奥希替尼可报 60%"，但这个 60% 只是 Agent 调用"理算工具"得到的返回值 。真正的理赔结论由理算系统落库、审批人确认后才生效。Agent 不能自己宣布"赔你 60%"。
这意味着 Agent 的工具调用本质是"对业务系统的读写请求"，业务系统才是裁判。金额/状态的最终一致性和持久化由业务系统的事务保障，Agent 不重造轮子。对 Java 背景：这就像"Controller 调 Service，Service 才操作 DB 并带事务"，Agent ≈ Controller，业务 Service 才是 owner。
理赔单/审批/金额都由业务系统（带事务+状态机）做权威 owner；Agent 只是发请求、读结果。金额必须经理算系统落库、审批确认才生效，Agent 不能自己宣布结论。
① 有人让 Agent 把"结论"存在自己内存/文件当真相——多实例/重启后结论可能不一致，且无事务保障，绝对不可取。② 业务系统做 owner 也意味着"拒绝 Agent 的不合理写入"：若 Agent 想改一个已结案单，业务系统应基于状态机拒绝，而非盲从。③ 权限要分清：Agent 能"发起提交"不代表它能"直接改金额"，关键写操作仍需业务系统+人工审批。
三、Agent 的角色：驱动者而非所有者
明确 Agent 的定位，避免"越权"和"责任不清"：
驱动者（Driver） ：编排流程、调用工具、汇总信息、在授权内执行动作。建议者（Advisor） ：给出推荐（如"建议报销 60%"），但最终决定权在业务系统/人。非所有者（Non-owner） ：不持有权威业务状态，不独自对业务结果负责。
Agent 决策 = 建议 + 受控执行；业务系统 = 权威记录 + 最终判定；人 = 高风险节点裁决
这个边界让"可追责性"成立：出了问题能说清"是模型建议错了、还是业务系统判错了、还是人批错了"。若 Agent 既当运动员又当裁判（拥有状态又下结论），责任链就断了，合规无法交代。
Agent = 驱动者+建议者+非所有者：编排流程、给建议、受控执行，但不持有权威状态、不独自担责。业务系统做权威记录，人做高风险裁决。
① 把 Agent 当"所有者"会导致"黑盒决策不可追责"——监管问"这笔为什么赔"答不上来。② 建议和执行要分开：Agent 可以给"建议报销 60%"，但落库动作必须经过业务系统校验+（必要时）人工确认。③ 角色边界要在架构文档里写清，面试时能画出"Agent / 业务系统 / 人"三方的职责边界是加分项。
四、审计：每次工具调用 / 决策留痕
企业级 Agent 的每一次动作都要可追溯 。审计记录回答四个基本问题：谁（who）、做了什么（what）、什么时候（when）、结果如何（result）。
维度 含义 例子 who 操作者身份 会话用户/角色（保单持有人）、Agent 实例 ID、是否代操作 what 动作 调用 query_policy / 提交 submit_claim / 模型给出建议 when 时间戳 精确到毫秒，含时区 result 结果 成功/失败/拒绝 + 关键输出（如返回金额、拒绝原因）
audit_log: { who, what, when, result, request_id, session_id, tool, args_digest, latency, token_cost }
审计不是"锦上添花"，是保险/金融行业的合规刚需（谁在何时基于什么查了患者病历、改了理赔）。没有审计，既无法复盘事故，也无法满足监管（如个保法、监管要求的可追溯）。审计要"不可篡改"（WORM 存储/追加日志）。
审计四要素：who（谁）/ what（做什么）/ when（何时）/ result（结果如何）。每次工具调用和关键决策都要留痕，且不可篡改，这是金融保险合规刚需。
① 审计要记"决策"不只是"调用"——模型基于什么给出了"建议报销 60%"这个决策，也要留痕（输入摘要+输出），否则只记工具调用查不到"为什么这么赔"。② 审计日志含患者敏感信息，要脱敏/加密存储，且访问受控。③ 审计记录要"防篡改"：用追加日志或 WORM 存储，不能谁都能改历史。
五、审计字段设计
一个企业级审计条目建议包含的字段：
{
"event_id": "uuid",
"session_id": "会话ID",
"agent_id": "Agent实例/版本",
"who": { "user_id": "...", "role": "policy_holder|claim_agent|admin", "on_behalf_of": null },
"what": "tool:query_policy | tool:submit_claim | llm:decision",
"args_digest": "sha256(入参摘要)", // 不全存明文，敏感字段脱敏
"result": "SUCCESS|DENIED|ERROR|PARTIAL",
"result_detail": "返回金额/拒绝原因/错误类",
"request_id": "幂等键",
"when": "2026-07-23T10:23:45.123+08:00",
"latency_ms": 312,
"token_cost": 1840,
"model": "qwen-max",
"parent_event_id": "上游事件（追踪因果链）"
}
幂等键 request_id ：和 W5D3 去重呼应，审计里也要记，便于对账"同一请求重试了几次"。parent_event_id ：串起因果链，一次会话的 N 个动作能还原成树。args_digest + 脱敏 ：敏感入参（身份证号）不存明文，存摘要/脱敏值。agent 版本 ：模型/提示词升级后能定位"当时用的哪个版本"，复盘回归。
字段设计要"够复盘、可追责、护隐私"三者平衡。太粗（只记"调了工具"）复不了盘；太细（全量明文敏感字段）又违反隐私。用摘要+脱敏+权限访问折中。
审计字段至少含：event/session/agent_id、who(用户+角色)、what(工具/决策)、args_digest(脱敏)、result、request_id(幂等)、when、latency、token、model 版本、parent_event_id(因果链)。
① 别为"省事"只记成功不记失败——恰恰失败/拒绝路径（如拒绝查病历）最该记全，用于合规和异常检测。② request_id 必须和重试/补偿链路同源，否则对账时"重试那次算几次"说不清。③ model/agent 版本要记，否则模型升级后出问题无法回溯"当时哪版干的"。
六、与 W4 HITL 的关系：人工审批是状态变更关键节点
W4 讲的 Human-in-the-Loop（人在环）本质是一个高风险业务状态的变更节点 ，它正好落在"业务状态归属"的边界上：
Agent 准备材料 → 触发 HITL（暂停）→ 人工审批（业务系统状态变更：审批中→已赔付）→ 结果回流 → Agent 继续
审批动作属于人 + 业务系统 ：Agent 不能替人做"赔付审批"这个权威决定，只能发起、准备、等结果。审批必须留痕 ：谁审批的、何时、基于什么材料、结论是什么——这是审计里最关键的一条。暂停点 = 状态边界 ：Agent 在 HITL 处用 Checkpointer（W5D1）暂停，审批结果回来后从断点恢复，业务状态由审批系统落库。
HITL 是"业务状态归属原则"的最直接体现：Agent 把"决定权"交还给人，自己不拥有"赔付与否"的结论。这也让 Agent 在保险这类强监管场景里"可被接受"——关键裁决有人负责。
HITL = 高风险状态变更节点。Agent 发起/准备/等结果，不替人做赔付审批；审批由人+业务系统落库并留痕。HITL 处用 Checkpointer 暂停，结果回流后恢复。这正是"Agent 不拥有业务状态"的体现。
① 别让 Agent "模拟"人工审批——比如模型自己输出"审批通过"，这是把决定权偷回给模型，违背 HITL 初衷，合规上不成立。② HITL 暂停期间 Agent 状态（Checkpointer）和业务状态（审批系统）要一致，不能 Agent 显示"待审批"但业务系统已是"已赔付"——状态对账要做。③ 审批留痕要包含"模型给的建议"作为参考，但结论字段必须来自人，不能混。
七、审计的可追溯性与合规
"可追溯"不只是"有日志"，而是能回答：任何一个业务结果，都能还原出完整因果链 ——谁、基于什么输入、调了什么、模型怎么建议、人怎么批、最终怎么落库。
合规要求 对应设计 谁查了患者隐私 who + what=query_policy + args_digest，拒绝也记 为什么这么赔 llm:decision 留痕（输入摘要+建议）+ 审批结论 + 理算返回 记录不可篡改 WORM/追加日志，防事后改 可复盘/可追责 parent_event_id 因果链 + agent 版本
对保险行业，可追溯是监管底线（理赔纠纷时要有完整证据链）。Agent 引入后，传统"人操作的系统"变成了"人+模型协作"，审计必须覆盖模型的每一步决策，否则出现"模型暗箱建议导致错赔"无法举证。
可追溯 = 任一业务结果都能还原完整因果链（谁/输入/调了什么/模型建议/人批/落库）。用 parent_event_id 串因果、WORM 防篡改、agent 版本可复盘——保险监管刚需。
① "有日志"不等于"可追溯"：若日志之间没因果链（parent_event_id），出了事只能看一堆孤立记录，还原不出"这笔为什么赔"。② 模型决策留痕要保留"输入摘要"，否则只记"建议报销60%"不知道是基于什么材料建议的，复盘无效。③ 隐私和审计冲突时要"脱敏记摘要"而非"不记"——不记等于放弃合规。
八、用 Langfuse 等工具做 Trace / 审计
手写审计成本高，生产中常用可观测平台。以 Langfuse 为例（开源 LLM 工程观测）：
能力 对应本节 Trace / Span 树 把一次会话的 LLM 调用、工具调用串成树（= 因果链 parent_event_id） 元数据 / 标签 记 user/role/session/request_id/model 版本 评分 / 反馈 人工审批结论、质量评分也可落为 observation 成本 / 延迟 token_cost / latency 自动统计
注意区分：Langfuse 这类是观测/调试/评测 平台，偏"工程可追溯"；而保险合规要求的"审计台账"往往还要独立落库（WORM）。两者互补：Langfuse 管开发运维期追溯，合规审计系统管监管期留证。
工具能大幅降低审计落地成本，但"记什么字段、是否防篡改、是否满足监管"仍要自己设计（见 s5/s7）。别以为"接了 Langfuse 就合规了"——它不减你的设计责任。
Langfuse 把 LLM 调用+工具调用串成 Trace 树（=因果链），自动记 user/session/request_id/成本/延迟，降低审计落地成本。但它偏工程观测，合规审计台账仍要独立防篡改落库，两者互补。
① 别把 Langfuse 当"合规审计系统"用——它默认不保证 WORM/防篡改，监管可能不认。② 敏感字段（患者身份证）进 Langfuse 前要脱敏，否则观测平台变成隐私泄露点。③ 观测数据量大，生产要采样/分级，但合规要求的"关键业务全量审计"不能靠采样。
九、状态变更与审计的边界
厘清"哪些动作要审计、哪些不必"，避免审计泛滥或遗漏：
动作 是否审计 理由 读业务数据（查保单/知识库） ✅ 记（who+what+结果） 隐私访问必须可查 写业务数据（提交/审批） ✅ 记（含结果+请求ID） 状态变更，关键 模型决策（建议/拒答） ✅ 记（输入摘要+输出） 决策可追溯 Agent 内部工作态（Checkpoint） ⚠️ 轻量记 调试用，非业务真相，可不进合规台账 纯展示/无副作用 ❌ 可不记 无业务影响
审计边界：读/写业务数据、模型决策都记；Agent 内部 Checkpoint 轻量记（调试用，非合规）；纯展示不记。核心是"有副作用/有隐私/有决策"的必记。
① "读"也别漏——谁查了患者病历是隐私合规重点，只读也要审计。② Agent 内部 Checkpoint 是工作态不是业务真相，混进合规审计台账会污染"业务真相"记录，要分层存储。③ 别为了"全记"把每个 token 都写审计库，成本和隐私都扛不住，按"副作用/隐私/决策"分层。
十、资源与监控：审计与状态一致性
监控项 用途 审计落库成功率 审计本身失败=合规缺口，要告警 Agent 态 vs 业务态一致性 发现"Agent 显示待审但业务已赔"等错配 越权/拒绝事件 异常检测（如某角色频繁被拒） 关键节点留痕完整性 确保 HITL 审批必有对应审计条
审计落库失败要告警（否则合规出现缺口）；监控 Agent 态与业务态一致性，防止两者错配；越权/拒绝事件用于异常检测。
① 审计写失败不能"静默忽略"——它是合规缺口，要有降级（本地缓存+重发）和告警。② 状态一致性监控常被忽略：Agent 暂停在"待审批"但业务系统已"拒赔"，用户看到的状态是错的，必须定期对账。
十一、面试达标线①：业务状态归属原则
要点 说明 Agent 不拥有业务状态 只驱动流程；理赔单/审批/金额的权威副本在业务系统 业务系统才是 owner 带事务+状态机，保证权威性与一致性；Agent 只读或经授权写 Agent 角色 驱动者+建议者+非所有者；高风险裁决交人 与 HITL 关系 人工审批是状态变更关键节点，Agent 不替人决定
核心：Agent 只驱动不拥有；业务系统（事务+状态机）是业务状态 owner；Agent 是驱动者/建议者/非所有者；HITL 处把决定权交还人。这样责任链清晰、可追责。
十二、面试达标线②：审计字段设计和为什么企业级必须可溯源
审计四要素：who / what / when / result │ 字段：session/agent_id/args_digest(脱敏)/request_id(幂等)/parent_event_id(因果链)/model版本
必须可溯源：监管刚需(理赔纠纷证据链) + 可追责 + 防篡改(WORM) + 模型决策也要留痕
字段设计 ：event/session/agent_id、who(用户+角色)、what(工具/决策)、args_digest(脱敏)、result、request_id(幂等)、when、latency、token、model 版本、parent_event_id(因果链)。为什么必须可溯源 ：保险/金融监管要求任一业务结果能还原完整因果链（谁/输入/调了什么/模型建议/人批/落库）；模型引入后决策变"人+模型协作"，不覆盖模型步骤就无法举证错赔；且需防篡改(WORM)、可追责。隐私与合规平衡 ：敏感字段脱敏/摘要存储，不记明文；但"不记"等于放弃合规，要脱敏记而非不记。工具 ：Langfuse 等降低落地成本，但合规审计台账仍要独立防篡改落库，工具不减设计责任。
十三、W5D4 自测清单
能说清"业务状态归属原则"：Agent 不拥有业务状态，只驱动流程。
能区分 Agent 内部工作态（Checkpointer，临时）和业务状态（理赔单/审批，权威在业务系统）。
能列出哪些状态由业务系统 owner（理赔单/审批/金额），并解释为什么 Agent 不能自己宣布结论。
能讲清 Agent 的三角色：驱动者、建议者、非所有者，以及为什么这样边界利于可追责。
能说出审计四要素（who/what/when/result）并各举保险例子。
能设计一个审计条目应包含的关键字段（含 request_id 幂等、parent_event_id 因果链、model 版本、脱敏）。
能解释与 W4 HITL 的关系：人工审批是状态变更关键节点，Agent 不替人决定，审批必须留痕。
能解释"可追溯"不只是"有日志"，还要有因果链（parent_event_id）和防篡改（WORM）。
能说出 Langfuse 在 Trace/审计上的能力，以及"接了不等于合规"的原因。
能区分审计边界：读/写业务数据、模型决策必记；Agent 内部 Checkpoint 轻量记；纯展示不记。
十四、高频面试题速记卡
Q：Agent 能拥有理赔单状态吗？
不能。Agent 只驱动流程，理赔单/审批/金额的权威副本在业务系统（事务+状态机）。Agent 内部态只是临时工作态，不是真相。
Q：Agent 算出"报销 60%"能直接告诉用户吗？
不能当成结论。这只是调用理算工具的返回值，必须经理算系统落库、审批确认才生效。Agent 可展示"建议/测算值"，但不自行宣布赔付结论。
Q：审计四要素是什么？
who（谁）/ what（做什么）/ when（何时）/ result（结果如何）。每次工具调用和关键决策都要留痕，且不可篡改。
Q：审计条目要记哪些关键字段？
session/agent_id、who(用户+角色)、what、args_digest(脱敏)、result、request_id(幂等)、when、latency、token、model版本、parent_event_id(因果链)。
Q：HITL 和状态归属什么关系？
人工审批是高风险状态变更关键节点。Agent 发起/准备/等结果，不替人做赔付审批；审批由人+业务系统落库并留痕，正是"Agent 不拥有业务状态"的体现。
Q："有日志"就等于"可追溯"吗？
不等于。还要有因果链（parent_event_id 串起一棵树）和防篡改（WORM），否则只能看孤立记录、还原不出"这笔为什么赔"。
Q：Langfuse 能当合规审计系统吗？
不能。它偏工程观测/调试，默认不保证防篡改，监管可能不认。合规审计台账要独立防篡改落库，两者互补。
Q：模型决策需要审计吗？
需要。模型"建议报销60%"这类决策要留痕（输入摘要+输出），否则出现错赔无法举证"当时基于什么材料建议的"。
Q：读操作（查保单）要审计吗？
要。谁查了患者隐私是合规范重点，只读也要记 who+what+结果，拒绝访问也要记。
Q：隐私和审计冲突怎么办？
脱敏记摘要而非不记。敏感字段（身份证）存 digest/脱敏值，不存明文；"不记"等于放弃合规，不可取。
FDE W5D4 学习手册 · 业务状态归属与审计（面试级）· 配合《FDE-W5D4-评测题.md》自测 · 资源：Langfuse（审计/Trace）langfuse.com
📌 待查 ★ 重要
★0
📌0