# FDE W5D7 评测题 · 整合与边界
> 配套《FDE-W5D7-整合与边界-学习手册.html》。场景统一为「特药理赔 Agent」。
> 每个题目含：**考察点**、**评分维度**（1~5 分）、**参考答案**（折叠展开）。
> 评分维度通用：① 正确性 ② 完整性 ③ 工程与风险意识（裁剪/预算/审计/边界判断）。
---
## L1 基础（概念识别）
### Q1. W5 周沉淀了哪些 Harness 能力？整合的目标是什么？
- **考察点**：能力清单 + 整合定位。
- **评分维度**：
- 正确性（2 分）：能列 W1/W2/W3/W4/D5/D6 对应能力。
- 完整性（2 分）：整合目标=把原型升级为企业 Harness（裁剪/Runtime/预算/审计/路由）。
- 工程意识（1 分）：不是重写模型，是套工程外壳。
参考答案（点击展开）
能力清单：W1 Agent Loop、W2 Tool Runtime、W3 RAG、W4 规划/反思、D5 Text2SQL（只读+白名单+安全校验）、D6 三路数据路由。
整合目标：把"单轮/裸调/无保障"的特药理赔 Agent 原型，升级成"裁剪+Runtime+路由+预算+审计"的企业 Harness。本质不是重写模型逻辑，而是给原型套一层工程外壳（横切保障）。
参考答案（点击展开）
- **Agent Loop**（W1+W4）：主控循环，串起思考与行动、规划与反思。
- **Tool Runtime**（W2）：工具执行沙箱，隔离/权限/超时/审计，所有工具统一出口。
- **路由**（D6）：上层编排，分发到 RAG/SQL/API，横切第一闸门。
- **预算**：Token/成本/次数/超时四道闸口，防失控。
- **审计**：全链路 Trace，合规刚需。
关键：路由/Runtime/预算/审计是"横切保障层"，RAG/SQL/API 所有能力都要过它们。
参考答案（点击展开）
裁剪是"原型→生产"的取舍：把不安全/不可控的部分（裸 SQL、裸 API、无限循环、无错误处理）换成可控实现（过安全校验、Tool Runtime、加预算/最大步数、加降级）。
它不是删功能，而是把"玩具实现"替换为"生产实现"。同时裁剪要避免过度设计——本期明确不引入 Temporal/多 Agent。你们 Java 上线最懂：Demo 和生产的差距全在横切保障上。
参考答案（点击展开）
Tool Runtime 四件事：① 隔离（受控环境，不访问未授权资源）；② 权限（最小权限，SQL 路只读账号、API 路用户级鉴权）；③ 超时（语句/请求级，防挂死）；④ 审计（入参/出参/耗时/结果留痕）。
它源自 W2 的"工具执行隔离与权限"，在 Harness 里成为所有工具（RAG/SQL/API）的统一执行出口，把 Day5 安全校验和 W2 工具隔离收敛到一个点统一管控。类比 Java 的统一网关/拦截器。
参考答案（点击展开）
四道闸口：① Token 预算（单次任务最大 token）；② 成本预算（按模型单价估算金额上限）；③ 次数预算（最大工具次数/Loop 步数，防死循环）；④ 超时预算（任务最长时间）。
处理：超预算要**优雅降级**（返回已完成部分结果 / 转人工），不是直接报错崩溃。注意预算不能只卡模型 token，工具调用（SQL/API）成本与次数也要算。类比后端限流/熔断——没有预算的 Agent 等于无限流的后端。
参考答案（点击展开）
保险场景审计是合规刚需：让 Agent 可复盘、可问责、可合规。出了问题（如错误赔付建议）能回溯"当时为什么走这条路、调了什么工具、模型怎么答的"。
注意：① **脱敏**——记 SQL/API 但不能明文存身份证号/银行卡号（反而制造泄密）；② **防篡改**——存独立日志系统，否则失去问责价值；③ 平衡性能，可按重要程度分级采样；④ 审计 Trace 也是路由准确率等评测指标的数据来源。
参考答案（点击展开）
路由是横切第一闸门，与另三者协作：
- **审计**：路由决策（问题/类别/conf/是否回退）记 Trace；
- **预算**：低置信→回退（多路/反问/人工），不消耗额外预算盲执行；
- **Runtime**：路由把请求导向对应 Tool Runtime 能力，由 Runtime 统一执行与审计。
路由 + Runtime + 预算 + 审计四者是 Harness 的"横切保障层"，RAG/SQL/API 所有能力都要过，不是孤岛。
参考答案（点击展开）
- **单 Agent 调多个工具**：一个主控 Loop 内，通过工具调用（function calling）使用 RAG/SQL/API 等能力。我们当前做的就是这种。
- **多 Agent 编排**：多个专职 Agent（如审核 Agent、药品知识 Agent）互相通信、委派任务，各有独立 Loop 与上下文隔离。
区别在"是否 Agent 间协作委派"。当前子任务用"单 Agent + 路由 + 工具"已覆盖，多 Agent 会带来通信、状态同步、责任归属（审计更复杂）的代价，故本期不实作。
参考答案（点击展开）
Temporal 用"Workflow + Activity"模型：Workflow 状态持久化、崩溃可恢复，Activity 失败按策略自动重试，解决"分布式长事务可靠性"（跨多微服务、保证最终一致性）。
当前不引入：特药理赔 Agent 是单 Agent 内的失败处理，用**应用层简单重试 + 退避 + 补偿 + 转人工**已完全覆盖，引入 Temporal 要部署运维一套 workflow 集群，是过度工程。它适用于"跨服务长流程可靠编排"（如跨系统理赔审批流），等真有此需求再引入——按需演进而非提前过度设计。
注意：简单重试要带退避与上限（防重试风暴），补偿要幂等（防重复提交理赔）。
参考答案（点击展开）
当前不实作：特药理赔 Agent 用"一个主控 Loop + 多工具（RAG/SQL/API）"已能覆盖，无需 Agent 间互相委派。多 Agent 带来通信、状态同步、责任归属（审计更复杂）的难题。
适用场景：子任务差异极大、需不同专长大模型或不同上下文强隔离时（如"研究 Agent + coding Agent"）。我们当前用路由分发到工具已等价覆盖大部分价值。等单 Agent 上下文撑不住、或确实需要强隔离/不同模型专长时再考虑拆分。重点：不实现但要能讲清边界与代价。
参考答案（点击展开）
A2A（Agent-to-Agent）是 Agent 之间的标准化通信协议，定义 Agent 卡片（能力描述）、任务协议、消息格式，让不同厂商/系统的 Agent 能互相发现、委派、交换结果——类似"Agent 的 HTTP 协议"，解决跨组织/跨系统 Agent 互操作（如保险 Agent 与医院 Agent 对接核验）。
本期只理解边界不落地：我们的特药理赔 Agent 是单域内闭环，工具都是内部能力，没有跨 Agent 通信需求；A2A 涉及协议标准、身份鉴权、跨域信任，是平台/生态层的事。关键是别把"Agent 调内部工具"误当成"跨 Agent 协议通信"——前者我们已做，后者是生态层。
参考答案（点击展开）
1. **裁剪**：删掉裸 SQL 直调，换成 Day5 带只读+白名单+安全校验的 SQL 路；加最大 Loop 步数。
- 例：原型直接 `SELECT` 查理赔库 → 改为过安全校验五关 + Tool Runtime。
2. **Tool Runtime**：所有工具统一出口，隔离+权限+超时+审计。
- 例：SQL 路用只读账号，API 路带用户级鉴权，调用超时 3s。
3. **路由**：上层编排分发 RAG/SQL/API（D6）。
- 例："规定怎么报"→RAG；"上月报多少"→SQL；"到哪步了"→API。
4. **预算**：Token/成本/次数/超时四闸口，超则降级。
- 例：单次会话最多 8 次工具调用，超则转人工，防规划死循环烧钱。
5. **审计**：全链路 Trace（问题/路由/工具/结果/拒答）。
- 例：记录"用户请求导出身份证号被拒答"事件，合规留痕。
不是重写模型，是给原型套工程外壳。
参考答案（点击展开）
恰恰相反，正是因为懂才现在不做——这是按需演进的工程判断：
- **Temporal**：分布式长事务 workflow 引擎（Workflow+Activity、持久化、自动重试），解决跨服务长流程可靠编排。我们当前是单 Agent 内失败处理，用应用层重试+退避+补偿+转人工已够；引入要运维一整套集群，是过度工程。等出现跨系统理赔审批流需求再上。
- **多 Agent 编排**：多个专职 Agent 互相委派，适用子任务差异极大、需不同专长/强隔离的场景。我们当前"单 Agent+路由+工具"已覆盖，多 Agent 会带来通信/状态/审计复杂度，保险合规场景下责任归属更难。
- **A2A**：Agent 间标准化通信协议，解决跨组织互操作。我们是单域闭环、内部工具即可，无跨 Agent 需求，故仅理解边界。
结论：不是不会，是判断当前规模用"单 Agent+横切保障层"最可控、最好审计、最快上线。技术选型看适配度，不看出身——这才是工程成熟度。