FDE W5 Day 7 学习手册 · 整合与边界（Temporal / 多 Agent / A2A 只理解边界）
W5 Day7 · A 级（必须掌握，面试核心）· 3h · 学完能讲透"W5 如何把 Agent 原型升级为企业 Harness，以及什么暂不实作、为什么"
本日定位：W5 收官日。前 6 天积累了 Agent Loop（W1）、Tool Runtime（W2）、RAG（W3）、规划（W4）、Text2SQL（D5）、三路路由（D6）。Day7 把这些能力整合进特药理赔 Agent，并划清边界：Temporal（用简单重试补偿代替）、多 Agent 编排、A2A 协议——本期只理解概念和边界，不实现。你是 36 岁、Java+大数据+医疗保险背景的候选人。
学完能回答：① W5 整体产出如何把 Agent 原型升级为企业 Harness；② 为什么 Temporal/多 Agent 暂不实作、边界和适用场景是什么。
使用方法：通读原理 → 重点看「工程含义」「面试话术」「易错点」→ 做自测清单 → 配合《FDE-W5D7-评测题.md》。选中不熟的词可标注（左下★重要 / 右下📌待查）。
一、W5 周回顾：Harness 能力清单
W5 围绕"企业 Agent Harness"工程化，已沉淀的能力：
| 来源 | 能力 | 工程价值 |
|---|
| W1 | Agent Loop（感知-思考-行动循环） | 主控循环骨架 |
| W2 | Tool Runtime（工具执行隔离/权限） | 安全调工具 |
| W3 | RAG（检索增强生成） | 知识类问答有出处 |
| W4 | 规划（任务分解/反思） | 多步任务可控 |
| D5 | Text2SQL（只读+白名单+安全校验） | 结构化查询安全落地 |
| D6 | 三路数据路由（RAG/SQL/API 编排） | 问题动态分发 |
W5 的核心不是"又加了一个模型能力"，而是把零散的 Agent 能力工程化、可管控化：每一路都有安全、有预算、有审计。这是从"能跑的 Demo"到"能上生产的 Harness"的关键跃迁。
📚 延伸资源（中文/官方，非 OpenAI）：① Temporal Java SDK（仅了解，本期不实作）docs.temporal.io/develop/java；② B站 李宏毅 Agent 原理讲解 BV1aiADewEBC；③ Awesome-Text2SQL github.com/eosphoros-ai/awesome-text2sql。
二、特药理赔 Agent 现状与整合目标
整合前，特药理赔 Agent 可能只是个"原型"：单轮问答、直接调模型、无预算无审计、SQL/API 裸调。整合目标——把它升级成企业 Harness：
- 裁剪：从原型里删掉玩具代码，保留生产必需的编排与安全。
- Runtime：工具执行有隔离、有权限、有超时（W2）。
- 预算：Token/成本/调用次数有上限，超预算降级（不裸奔）。
- 审计：每次决策/工具调用/结果都留 Trace（合规刚需）。
- 路由：问题动态分发到 RAG/SQL/API（D6）。
整合的本质是"给原型套上一层工程外壳"：不是重写模型逻辑，而是加上裁剪、Runtime、预算、审计、路由这五件事，让它从"演示能用"变成"生产可控"。这正好对应你做 Java 服务时从 Demo 到上线的那套工程化动作。
整合目标：把特药理赔 Agent 原型升级为企业 Harness——裁剪玩具代码、Tool Runtime 隔离权限、预算上限、审计 Trace、三路路由。不是重写模型，而是套工程外壳。
三、企业 Agent Harness 整体架构
┌────────────────────────── 企业 Agent Harness ──────────────────────────┐
│ 用户输入 │
│ │ │
│ ▼ │
│ [ 路由 Router ]── 判定 RAG / SQL / API（D6，含置信度门控） │
│ ├─ RAG ──► W3 检索+生成 │
│ ├─ SQL ──► D5 Text2SQL + 安全校验五关 │
│ └─ API ──► W2 Tool Runtime（隔离/权限/超时/审计） │
│ │ │
│ [ Agent Loop ]（W1 主控：感知-思考-行动，W4 规划/反思） │
│ │ │
│ [ 预算 Budget ] ◄── Token/成本/次数上限，超则降级 │
│ [ 审计 Audit ] ◄── 全链路 Trace + 日志（合规） │
└──────────────────────────────────────────────────────────────────────┘
- Agent Loop：主控循环，串起思考与行动（W1 + W4 规划）。
- Tool Runtime：工具执行沙箱，权限/超时/隔离（W2）。
- 路由：上层编排，分发到三路能力（D6）。
- 预算：全局闸口，防止失控成本与无限循环。
- 审计：贯穿全链路的可观测与留痕。
这个架构图是面试"压轴题"——能把 W1/W2/W3/W4/D5/D6 在图里讲清楚位置与数据流，说明你真正建立了企业 Agent 的整体架构观，而不是只会单点。注意：路由、Runtime、预算、审计是"横切"的，所有能力都要过它们。
整体架构=Agent Loop(主控)+Tool Runtime(执行沙箱)+路由(分发三路)+预算(闸口)+审计(留痕)。路由/Runtime/预算/审计是横切层，所有能力都要过。能画出并讲清这张图是面试压轴。
四、裁剪：原型 → 生产的取舍
原型里常有的"玩具成分"要裁掉，生产必需的要保留：
| 原型（裁掉/改造） | 生产（保留/强化） |
|---|
| 裸 SQL / 裸 API 直调 | 过安全校验 + Tool Runtime + 审计 |
| 无限循环 Agent Loop | 有最大步数 + 预算上限 |
| 无错误处理的快乐路径 | 重试补偿 + 降级 + 转人工 |
| 无日志 | 全链路 Trace（问题/路由/工具/结果） |
裁剪体现"生产优先于演示"的工程价值观。原型追求"看起来能跑"，生产追求"失控也能兜住"。你们做 Java 上线最懂：Demo 和生产的差距，全在这些"横切保障"上。
① 裁剪不是"删功能"，是把不安全/不可控的部分换成可控实现（如裸 SQL→带校验的 SQL 路）。② 别为"架构完美"过度设计——本期明确不引入 Temporal/多 Agent，见后文。③ 裁剪后要回归测试，确保保留的能力不被误删。
裁剪=把裸调换成可控实现（裸SQL→带校验SQL路），不是删功能。生产优先于演示，差距全在横切保障上。别过度设计，本期不引入 Temporal/多Agent。
五、Tool Runtime：工具执行隔离与权限（联动 W2）
所有工具（含业务 API、SQL 执行）都在 Tool Runtime 里跑，保证：
- 隔离：工具在受控环境执行，不能访问未授权资源。
- 权限：每个工具带最小权限（如 SQL 路只读账号、API 路带用户级鉴权）。
- 超时：单工具调用有语句/请求级超时，防挂死。
- 审计：工具入参/出参/耗时/结果全部留痕。
Tool Runtime 是"所有动作的统一出口"——无论 RAG/SQL/API 哪路，最终执行都过它。这把 Day5 的"安全校验"和 W2 的"工具隔离"在工程上收敛到一个点，便于统一管控与审计。你们 Java 背景可类比"统一网关/拦截器"。
Tool Runtime 是所有工具的统一出口：隔离+权限+超时+审计。RAG/SQL/API 最终执行都过它，把安全校验和工具隔离收敛到一个点统一管控。类比 Java 统一网关/拦截器。
六、预算：Token / 成本 / 次数预算
Agent 有"失控"风险：规划出长循环、反复调贵模型、SQL 反复重试烧 token。预算是全局闸口：
- Token 预算：单次会话/单次任务最大 token，超则停止并降级。
- 成本预算：按模型单价估算金额上限，防贵模型滥调。
- 次数预算：最大工具调用次数 / Agent Loop 步数，防无限循环。
- 超时预算：整体任务最长时间，超则返回部分结果或转人工。
预算是"防止 AI 失控烧钱/死循环"的硬保障，也是 SLA 的一部分。你们做过高并发 Java 服务，对"限流/配额/熔断"不陌生——预算本质就是 Agent 的配额与熔断。生产没有预算的 Agent，等于没有限流的后端，迟早出事。
① 预算不能只卡模型 token，工具调用（SQL/API）的成本与次数也要算。② 超预算要优雅降级（返回已完成部分/转人工），不是直接报错崩溃。③ 预算值要可配置，不同用户/场景给不同档位。
预算=Token/成本/次数/超时四道闸口，防 Agent 失控烧钱或死循环（类比后端限流熔断）。超预算要优雅降级，不是崩溃。工具调用成本也要算进预算。
七、审计：Trace 与日志（合规刚需）
保险场景，审计不是"可选项"而是合规刚需。Harness 要记录：
- 原始问题、路由类别与 confidence、是否回退；
- 每一步 Agent Loop 的思考摘要、工具调用入参/出参/耗时；
- SQL 原文（校验后）、API 请求/响应（脱敏）、最终结果；
- 越权/拒答事件（如 D5 Q13 的导出敏感数据请求）。
审计让 Agent 可复盘、可问责、可合规。出了问题（如错误赔付建议）能回溯"当时为什么走这条路、调了什么、模型怎么答的"。你们做金融/保险系统最懂：没有审计日志的系统，上线即违规。Trace 也是前面所有评测指标（路由准确率等）的数据来源。
① 审计日志要脱敏——记 SQL/API 但不能明文存身份证号/银行卡号（反而制造泄密）。② 审计和性能要平衡，全量 Trace 有成本，可按重要程度分级采样。③ 审计要防篡改（存独立日志系统），否则失去问责价值。
审计=全链路 Trace（问题/路由/工具/结果/拒答事件），保险合规刚需。让 Agent 可复盘可问责。日志要脱敏、防篡改，且是各评测指标的数据源。
八、路由：上层编排（联动 D6）
在 Harness 里，路由是横切的"第一道闸门"：所有用户输入先过路由，再分发到 RAG/SQL/API。它与预算、审计协作：
- 路由决策本身记 Trace（问题/类别/conf/是否回退）；
- 路由低置信→回退（多路/反问/人工），不消耗额外预算盲执行；
- 路由把请求导向对应 Tool Runtime 能力，由 Runtime 统一执行与审计。
路由 + Runtime + 预算 + 审计，四者是 Harness 的"横切保障层"，所有能力都要过。理解这点，面试时能清晰说明 W5 各模块不是孤岛，而是被这几层编织成一个可控整体。
路由是横切第一闸门，与预算/审计协作：决策记 Trace、低置信回退不盲执行、导向 Tool Runtime 统一执行。路由+Runtime+预算+审计=横切保障层，所有能力都过。
九、为什么暂不实现 Temporal：用简单重试补偿代替
Temporal 是 workflow 编排引擎，提供"持久化执行、自动重试、状态恢复"的分布式工作流能力（Java SDK 可用）。听起来很香，但本期不引入：
- 复杂度代价：引入 Temporal 要部署/运维一套 workflow 集群，学习曲线陡，对当前规模是过度工程。
- 当前需求够用：特药理赔 Agent 的"失败处理"用应用层简单重试 + 补偿即可（如 SQL 超时重试一次、API 失败转人工、幂等防重）。
- 边界清晰：理解 Temporal 的"持久化工作流、exactly-once、状态恢复"概念即可，知道它适用于"长流程、多步骤、需跨服务可靠编排"的场景（如跨系统理赔审批流）。
概念边界（面试够用）：Temporal 用"Workflow + Activity"模型，Workflow 状态持久化、崩溃可恢复，Activity 失败自动按策略重试。适用于跨多个微服务、需保证最终一致性的长事务。当前 Agent 的重试用"循环+退避+补偿"足矣。
工程判断力体现在"知道什么现在不做"。Temporal 解决的是"分布式长事务可靠性"，而我们当前是单 Agent 内的失败处理，用重试+补偿+转人工完全覆盖，且运维成本极低。等真出现跨服务长流程可靠性需求时再引入——这是"按需演进"而非"提前过度设计"。
① 不实现 ≠ 不知道。面试要能说清 Temporal 是什么、解决什么、为什么现在不合适。② 简单重试要带退避与上限，否则"重试风暴"反而压垮下游。③ 补偿要幂等：重复触发（如用户刷新）不能重复提交理赔。
暂不实现 Temporal：它是分布式长事务编排引擎（Workflow+Activity、持久化、自动重试），对当前规模是过度工程。我们用应用层重试+退避+补偿+转人工就够。但要懂它适用"跨服务长流程可靠编排"的边界。
十、为什么暂不实作多 Agent 编排：边界与适用
多 Agent 编排指多个专职 Agent（如"理赔审核 Agent""药品知识 Agent""额度计算 Agent"）互相协作、委派任务。本期不实作：
- 当前是单 Agent + 工具：特药理赔 Agent 用"一个主控 Loop + 多工具（RAG/SQL/API）"已能覆盖，无需多 Agent 互相委派。
- 复杂度与可观测性：多 Agent 带来 Agent 间通信、状态同步、责任归属难题，调试与审计更难。
- 边界：多 Agent 适用于"子任务差异极大、需不同专长大模型/不同上下文隔离"的场景（如"研究 Agent + coding Agent"）。我们当前子任务差异可用"单 Agent + 路由 + 工具"表达。
概念边界：多 Agent 常见模式有 Supervisor（主管派活）、Delegation（委派）、黑板（共享状态）。它在"任务可自然拆分为独立专长"时有价值，但要付出通信与可观测成本。我们当前用"路由分发到工具"已等价覆盖大部分价值。
同样体现"按需演进"：多 Agent 不是更先进就一定要用。单 Agent + 路由 + 工具 + 横切保障，在当前规模下更可控、更好审计、更快上线。等子任务确实需要强隔离/不同模型专长、且单 Agent 上下文撑不住时，再考虑拆多 Agent。
① 别把"单 Agent 调多个工具"和"多 Agent 编排"混为一谈——前者是工具调用，后者是 Agent 间协作委派。② 多 Agent 的"责任归属"在审计上更复杂，保险合规场景要谨慎。③ 不实现但要能讲清边界与适用场景，这是面试考察点。
暂不实作多 Agent 编排：当前用"单 Agent Loop + 路由 + 工具"已覆盖，多 Agent 带来通信/状态/审计复杂度。它适用"子任务差异极大、需不同专长/上下文隔离"的场景。边界要懂，但本期不做。
十一、A2A 协议：概念与边界（仅理解）
A2A（Agent-to-Agent）指 Agent 之间的标准化通信协议，让不同厂商/系统的 Agent 能互相发现、委派、交换结果。本期仅理解边界：
- 它解决什么：跨组织/跨系统的 Agent 互操作（如保险 Agent 与医院 Agent 对接核验）。
- 当前不做：我们的特药理赔 Agent 是单域内闭环，工具都是内部能力，没有跨 Agent 通信需求。
- 边界：A2A 涉及协议标准、身份鉴权、跨域信任——这是平台/生态层的事，不是单 Agent 工程化的事。
概念边界：A2A 类似"Agent 的 HTTP 协议"——定义 Agent 卡片（能力描述）、任务协议、消息格式，让 Agent 可被发现与协作。理解它即可，本期不落地，避免把"单 Agent 内部工具调用"误当成"跨 Agent 协议通信"。
划清 A2A 边界很重要：很多人把"Agent 调工具"和"Agent 间用 A2A 协议通信"混为一谈。前者是内部函数调用（我们已做），后者是跨系统协议（生态层）。当前阶段关注内部 Harness 可控性，比追 A2A 协议务实得多。
A2A=Agent 间标准化通信协议（类似 Agent 的 HTTP），解决跨组织 Agent 互操作。当前单域闭环、内部工具即可，无跨 Agent 需求，故仅理解边界不做。别把"调工具"误当"跨 Agent 协议"。
十二、面试达标线①：W5 如何把 Agent 原型升级为企业 Harness
原型(单轮/裸调/无保障) ──整合──► 企业 Harness = Agent Loop + Tool Runtime(隔离/权限/超时/审计) + 路由(分发三路) + 预算(Token/成本/次数/超时) + 审计(Trace)
- 裁剪：裸 SQL/API 换成带安全校验与 Runtime 的可控实现，加最大步数/预算。
- Runtime：所有工具统一出口，隔离+权限+超时+审计（W2+Day5）。
- 路由：上层编排分发 RAG/SQL/API（D6），横切第一闸门。
- 预算：Token/成本/次数/超时四闸口，防失控（类比限流熔断）。
- 审计：全链路 Trace，合规刚需（W5 各评测指标的数据源）。
达标核心：能讲清 W5 用"裁剪+Runtime+路由+预算+审计"五件事，把原型（裸调/无保障）升级成可控的企业 Harness，并能在架构图里标出 W1/W2/W3/W4/D5/D6 的位置与数据流。
十三、面试达标线②：为什么 Temporal/多 Agent 暂不实作、边界与适用场景
暂不实现 Temporal：它是分布式长事务 workflow 引擎（Workflow+Activity、持久化、自动重试），解决"跨服务长流程可靠编排"。当前单 Agent 内失败处理用"重试+退避+补偿+转人工"已够，引入是过度工程。但要懂概念与适用边界。
暂不实作多 Agent 编排：当前"单 Agent Loop + 路由 + 工具"已覆盖，多 Agent 带来通信/状态/审计复杂度。它适用"子任务差异极大、需不同专长/上下文隔离"场景。当前用路由分发到工具等价覆盖大部分价值。
A2A 仅理解边界：Agent 间标准化通信协议（跨组织互操作），当前单域闭环无需求。别把"调内部工具"误当"跨 Agent 协议通信"。
达标核心：能讲清"不实现 ≠ 不知道"——Temporal 解决分布式长事务可靠性（现在用重试补偿）；多 Agent 适用强隔离/不同专长（现在单 Agent+工具够）；A2A 是跨域协议（现在单域闭环）。重点是按需演进、划清边界。
十四、Day 7 自测清单
- 能列出 W5 各天沉淀的 Harness 能力（Loop/Tool/RAG/规划/SQL/路由）。
- 能说清整合目标：把原型升级为企业 Harness（裁剪/Runtime/预算/审计/路由）。
- 能在架构图里标出 Agent Loop / Tool Runtime / 路由 / 预算 / 审计 的位置与关系。
- 能讲清路由/Runtime/预算/审计是"横切保障层"，所有能力都要过。
- 能说清裁剪是"把裸调换成可控实现"，不是删功能。
- 能讲清 Tool Runtime 的四件事（隔离/权限/超时/审计）及与 W2 联动。
- 能列出预算的四道闸口（Token/成本/次数/超时）及"优雅降级"原则。
- 能讲清审计为什么是保险合规刚需，以及脱敏/防篡改要点。
- 能解释为什么暂不实现 Temporal（过度工程，用重试补偿代替），并说清 Temporal 概念与适用边界。
- 能解释为什么暂不实作多 Agent 编排，并说清多 Agent 适用场景与代价。
- 能讲清 A2A 是什么、为什么当前只理解边界（单域闭环无跨 Agent 需求）。
- 能讲清"不实现 ≠ 不知道"，体现按需演进的工程判断力（达标线②）。
十五、高频面试题速记卡
Q：W5 怎么把 Agent 原型升级成企业 Harness？
五件事：裁剪（裸调换可控实现）、Tool Runtime（隔离/权限/超时/审计）、路由（分发三路）、预算（四闸口）、审计（Trace）。给原型套工程外壳，不是重写模型。
Q：架构图里路由/Runtime/预算/审计是什么关系？
它们是横切保障层，所有能力（RAG/SQL/API）都要过。Agent Loop 是主控，路由是第一闸门，Runtime 是统一执行出口，预算是闸口，审计贯穿全链路。
Q：为什么暂不实现 Temporal？
它是分布式长事务 workflow 引擎，对当前单 Agent 规模是过度工程。失败处理用应用层重试+退避+补偿+转人工已够。但要懂它解决"跨服务长流程可靠编排"。
Q：Temporal 适用什么场景？
跨多个微服务、需保证最终一致性、可持久化恢复的长事务（如跨系统理赔审批流）。当前没有这种需求，故不引入。
Q：为什么暂不实作多 Agent 编排？
当前"单 Agent Loop+路由+工具"已覆盖；多 Agent 带来通信/状态/审计复杂度。它适用子任务差异极大、需不同专长/上下文隔离的场景。
Q：多 Agent 和"单 Agent 调多个工具"区别？
前者是 Agent 间协作委派（独立 Loop/上下文），后者是单 Loop 内函数调用。我们做的是后者，别混淆。
Q：A2A 是什么，为什么只理解边界？
A2A 是 Agent 间标准化通信协议（跨组织互操作），类似 Agent 的 HTTP。当前单域闭环、内部工具即可，无跨 Agent 需求，故仅理解边界不做。
Q：预算有哪些闸口？超预算怎么办？
Token/成本/次数/超时四道闸口（类比后端限流熔断）。超预算要优雅降级（返回部分结果/转人工），不是崩溃；工具调用成本也要算进预算。
Q：审计为什么是保险合规刚需？
让 Agent 可复盘/可问责/可合规：出错能回溯路由与工具调用。日志要脱敏、防篡改，也是各评测指标的数据源。
Q：不实现这些技术，面试怎么体现水平？
讲清"不实现 ≠ 不知道"——说清每项是什么、解决什么、为什么现在不合适、适用边界。体现按需演进、划清边界的工程判断力。
FDE W5D7 学习手册 · 整合与边界（面试级）· 配合《FDE-W5D7-评测题.md》自测
📌 待查★ 重要