# FDE W5D1 评测题 · Agent Loop 企业扩展 > 配套手册：《FDE-W5D1-Agent-Loop-企业扩展-学习手册.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 Loop 的"感知—决策—行动—观察"闭环指什么？ - **考察点**：Agent Loop 基本构成与运转机制。 - **评分维度**：能说清四阶段含义（2 分/阶段）+ 能举一个特药理赔的例子（额外 2 分中给到整体连贯性）。 - **参考方向**：感知=拼 prompt（用户问题+历史+工具描述）；决策=LLM 输出下一步动作（调工具 or 结束）；行动=解析并执行工具调用；观察=工具结果回填上下文进入下一轮。
参考答案 最小闭环：把 system+history+tools_desc 给 LLM，LLM 决定"调某个工具 or 给出最终答案"；若是调工具，解析出工具名和参数执行，把结果回填上下文，再喂回 LLM，直到模型说"答完了"。 示例（特药理赔）：用户问"肺癌靶向药奥希替尼能报多少"→ 模型决定先调"查询保单"→ 拿到保单与特药目录 → 再调"计算报销比例"→ 得出金额 → 输出理赔结论。
### Q2. 原型 Agent Loop 为什么不能直接上生产？列出至少三点硬伤。 - **考察点**：从原型到企业的演进动机。 - **评分维度**：每点硬伤 2 分（共 6 分），点出对应后果（如超窗/故障扩散/状态丢失，2 分）。 - **参考方向**：无 Context 裁剪（超窗、烧钱、注意力稀释）；无工具隔离（一处异常拖垮全流）；无状态持久（重启全丢、不可恢复）；无可观测（不可复盘审计）。
参考答案 三道硬伤： 1. **无 Context 裁剪**：全量历史无裁剪，长对话/长工具结果会超上下文窗口、每次调用更贵更慢、无关信息稀释关键证据（如拒赔条款）。 2. **无工具隔离**：直接调业务函数，工具里 NPE/OOM 会拖垮整个 Loop，主流程崩。 3. **无状态持久**：状态只在内存变量，进程重启全丢，无法恢复，长周期业务（跨天理赔）不可行。 补充：无 Trace 可观测，出问题靠猜、不可审计。
### Q3. 什么是 Tool Runtime？它在 Agent 架构中的位置是什么？ - **考察点**：工具执行抽象层的概念。 - **评分维度**：定义准确（3 分）；能列出至少 3 个职责（注册/调度/隔离/可观测，3 分）；说清"与业务解耦"（2 分）。 - **参考方向**：Tool Runtime 是工具调用的中间件/防腐层，Agent 只发意图，Runtime 负责注册/调度/隔离/可观测，把 LLM 意图转成对业务系统的安全调用，业务代码零改。
参考答案 Tool Runtime 是"工具调用的抽象层/中间件（防腐层）"。位置：Agent 与业务系统之间。Agent 只说"我要调 X（意图）"，Runtime 负责把意图翻译成对核心业务系统的安全调用。 四个职责：注册（统一工具元数据结构）、调度（并发/依赖/限流/重试/超时）、隔离（独立执行单元、异常不污染主流程）、可观测（每次调用入参/结果/耗时/错误全记 Trace）。价值：业务代码零改动即可被 Agent 复用，统一治理一次到位——与业务解耦。
--- ## L2 进阶（Q4–Q7，各 9 分，共 36 分） ### Q4. Context 裁剪有哪两类基本思路？各自适用什么场景？ - **考察点**：裁剪/摘要的两种手段。 - **评分维度**：两类思路（丢弃 eviction / 压缩 compression，各 2 分）；适用场景（2 分）；能举医疗保险例子（3 分）。 - **参考方向**：丢弃=按策略丢低重要消息，适用"近期才重要"；压缩=把多轮/长结果摘要成短文本保留，适用"旧信息仍有价值但不能全留"。
参考答案 两类： - **丢弃（Eviction）**：按策略丢掉最不重要的旧消息/旧工具结果。适用历史很长、近期信息才重要的场景。 - **压缩（Compression）**：把多轮对话/长工具结果摘要成短文本保留。适用旧信息仍有价值但不能全留的场景。 保险例子：一个理赔案涉及多轮沟通+多份医疗文书+知识库检索，原始拼起来几万字；不能全留（超窗烧钱），但老轮"已确认适应症匹配"仍有价值，所以按轮摘要而非直接丢弃。
### Q5. 按轮摘要（summary per turn）和按 token 预算裁剪（token-budget trimming）分别怎么实现？ - **考察点**：两种具体摘要策略的实现。 - **评分维度**：按轮摘要做法（3 分）；按 token 预算做法含"重要性打分+保底"（4 分）；工具结果单独处理（2 分）。 - **参考方向**：按轮摘要=超 N 轮后把最早若干轮压成"进展摘要"；按 token 预算=设上限、按重要性排序、从最低分丢/压直到回到预算；工具长结果 top-k 截断。
参考答案 - **按轮摘要**：对话超 N 轮后，把最早的若干轮压缩成一段"到目前为止的进展摘要"（含已确认事实、待办、未调用工具），替换原始多轮。 - **按 token 预算裁剪**：设预算（如 8k token），每轮给消息打重要性分（系统提示最高、最新用户消息高、工具错误高、陈旧摘要低），超出预算时从最低分开始丢弃或摘要，直到回到预算内。要有"保底白名单"（保单号、当前决策阶段永不丢）。 - **工具结果单独处理**：长工具结果（知识库 top-k 文档）按相关性重排取 top-N，或先 RAG 截断再进上下文，不占对话预算。
### Q6. Context 裁剪和 KV Cache 有什么关系？裁剪时如何维持高缓存命中？ - **考察点**：裁剪与推理缓存的权衡。 - **评分维度**：KV Cache 原理（缓存前缀、命中则快且省，3 分）；"动旧端保尾端"原则（3 分）；反例（频繁重排中间打散缓存，3 分）。 - **参考方向**：KV Cache 缓存已读 token 的 K/V，前缀不变则命中。裁剪应把老轮摘要化放前面、新消息追加尾部，保持前缀稳定；频繁重排中间内容会让前缀变、缓存失效、更慢更贵。
参考答案 KV Cache：自回归生成时对"已读 token"的 K/V 向量缓存，下一轮复用避免重算前缀，前缀不变→命中→延迟低、成本低。 关系与做法： - 裁剪要"**动旧端、保尾端**"——把最早几轮摘要化放最前面（旧端），新消息永远追加在尾部。这样前面"系统提示+摘要"虽偶尔变，但尾部大量轮次仍可命中缓存。 - 反例：每轮都"智能重排"把重要消息挪前面，结果前缀每轮都变，KV Cache 全废，反而更慢更贵。摘要操作本身也有成本，要和缓存失效重算成本权衡，不是裁剪越勤越好。
### Q7. Agent 中间状态可以存在哪几个地方？各自优劣与适用场景？ - **考察点**：多轮状态管理的存储选择。 - **评分维度**：三种位置（内存/Checkpointer/外部存储）各 2 分；优劣与适用（3 分）。 - **参考方向**：内存（快但重启丢、不共享）；Checkpointer（每步快照可恢复，框架级）；外部存储（持久跨进程可审计，长周期业务必用）。
参考答案 1. **内存变量**：最快，但进程重启全丢、无法多实例共享。适用单次会话内的临时变量/原型。 2. **Checkpointer**：每步落快照，可暂停/恢复/回溯，框架级。适用企业级多轮 Agent。注意只存恢复所需最小状态+裁剪后上下文指针，避免爆存储。 3. **外部存储（DB/Redis）**：持久、跨进程、可审计。适用长周期业务（特药理赔跨多工作日）。 注意区分：Agent 内部中间状态可 Checkpoint；理赔单/审批状态属于业务系统（W5D4），Agent 不拥有。
--- ## L3 深度（Q8–Q11，各 10 分，共 40 分） ### Q8. Checkpointer 的可恢复性原理是什么？为什么说工具副作用必须幂等？结合理赔场景说明。 - **考察点**：状态持久化与恢复的正确性。 - **评分维度**：快照/恢复原理（4 分）；幂等必要性+后果（4 分）；理赔示例（2 分）。 - **参考方向**：每步落快照，崩溃/暂停后用 session_id+步号从断点继续，不重跑；但恢复会重跑后续，若工具（提交审批）无幂等键会重复执行——事故。
参考答案 原理：Checkpointer 在每步（一次 LLM/工具调用后）把"当前状态快照（裁剪后 messages + agent_state + next_action）"写存储。崩溃或主动暂停后，用 session_id+步号 load 快照，从 step_{n+1} 恢复，不必从头重跑（省 token、避免重复副作用）。 幂等必要性：恢复会重跑后续步骤，若工具（如"提交理赔审批"）没有幂等键/去重，会执行两遍——重复提交审批是生产事故。所以工具副作用要带幂等键（如 request_id）。 理赔示例：Agent 调"提交特药理赔审批"后崩溃，恢复重跑时若未带相同 request_id，可能向审批系统提交两次，造成重复赔付。
### Q9. Tool Runtime 的"隔离"具体怎么做？为什么它和"注册时的 annotations"不是一回事？ - **考察点**：隔离实现 + 提示与安全的边界（铺垫 D2 鉴权）。 - **评分维度**：隔离实现手段（线程池/协程/微服务、异常捕获成受控错误，4 分）；annotations 只是提示非安全边界（3 分）；按业务域分组（3 分）。 - **参考方向**：工具在独立执行单元跑，异常被 Runtime 捕获返受控错误，主流程不挂；annotations（read_only/risk）只是给模型/开发者的提示，真鉴权另做；隔离粒度按业务域分组。
参考答案 隔离实现：工具在独立线程池/协程/微服务中执行，单工具超时或抛错由 Runtime 捕获，返回"受控错误"（供 Agent 决定重试或换策略），主 Loop 不崩。隔离粒度按业务域分组（如"保单域""支付域"各一池），别一个工具一池（太碎）也别全共用一池（互相影响）。 annotations vs 隔离：工具注册里的 `annotations`（read_only/risk 等）只是"提示"——告诉模型/开发者这个工具的特性，它不是安全边界，不能当鉴权依据（真鉴权见 W5D2）。隔离解决的是"故障不扩散"，annotations 解决的是"给模型决策参考"，两件事正交。
### Q10. 为什么裁剪不能"越短越好"？设计一个不丢关键信息的裁剪方案。 - **考察点**：裁剪的代价与保真度。 - **评分维度**：点出"丢关键信息=业务事故"+摘要本身也会丢/歪曲（4 分）；保底白名单+摘要保真度评估+分级裁剪（6 分）。 - **参考方向**：把关键拒赔条款摘要没了→错误理赔结论。方案：保底白名单（保单号/决策阶段/关键条款原文不动）、摘要保真度评估、组合策略、裁剪动作留 Trace 可审计。
参考答案 为什么不能越短越好：裁剪/摘要会丢信息，若把"关键拒赔条款"摘要没了，模型会给出错误理赔结论，是业务事故；而且摘要本身由 LLM/规则做，也可能丢失或歪曲信息。 不丢关键的方案： 1. **保底白名单**：保单号、当前决策阶段、关键拒赔条款原文等字段永远不丢、不摘要。 2. **组合策略**：对话历史按轮摘要，工具长结果 top-k 截断，全局 token 预算兜底。 3. **摘要保真度评估**：对摘要做抽检（如用摘要回生成关键字段，看是否一致），监控摘要质量。 4. **裁剪动作留 Trace**：为什么丢这条、为什么留那条要可审计，企业里不能黑盒随机丢。
### Q11. 企业级 Agent 的可观测（Trace）应该记录哪些内容？为什么失败路径最该记全？ - **考察点**：可观测性设计。 - **评分维度**：列出记录项（LLM 输入输出/工具入参结果耗时错误/token 成本/裁剪动作，5 分）；失败路径重要性+采样/隐私（5 分）。 - **参考方向**：每步 LLM 输入输出、工具调用全貌、token 成本、裁剪动作；失败路径（工具异常/超时）最该记全以复盘；采样分级、隐私脱敏。
参考答案 记录内容： - 每步 LLM 输入/输出（复现、评测、调试） - 工具调用入参/结果/耗时/错误（定位慢/错的工具） - token 与成本（核算、预算预警） - 裁剪/摘要动作（审计"为什么丢了某信息"） 为什么失败路径最该记全：线上事故恰恰发生在工具异常、超时、重试耗尽时，若只记成功不记失败，事故无法复盘、无法定位根因。 工程注意：Trace 有开销，生产要采样或分级（关键业务全记、普通对话抽样）；Trace 含患者隐私，存储与访问要脱敏和权限控制。
--- ## L4 场景（Q12–Q13，Q12 9 分 / Q13 8 分，共 17 分） ### Q12. 场景题：你们要做一个"特药理赔 Agent"，用户上传病历和保单后，Agent 要查知识库、算报销、必要时转人工审批。请设计它的企业级 Loop 架构，至少覆盖 Context 裁剪、Tool Runtime、状态持久三层。 - **考察点**：综合落地能力（架构设计）。 - **评分维度**：三层都覆盖且合理（各 2 分）；点出长周期需外部存储+人工审批断点恢复（2 分）；举个裁剪保底白名单例子（1 分）。 - **参考方向**：Context=按轮摘要+工具 top-k+预算，保底白名单含保单号/决策阶段；Runtime=注册查保单/算报销/转人工三工具，隔离限流；状态=Checkpointer 每步快照，长周期落 DB，人工审批处暂停可恢复。
参考答案 架构： - **Context 裁剪**：对话历史按轮摘要（保留"已确认适应症匹配/待确认报销上限"）；知识库检索结果 top-k 截断进上下文；全局 token 预算兜底。保底白名单：保单号、当前决策阶段、命中拒赔条款原文——永不丢。 - **Tool Runtime**：注册三个工具——`query_policy`（查保单+特药目录）、`calc_reimburse`（算报销比例/金额）、`handoff_human`（转人工审批），各自带权限标签。Runtime 做隔离（各工具独立执行，异常返受控错误）、限流（防打爆核心业务库）、Trace。 - **状态持久**：用 Checkpointer 每步落快照；特药理赔跨多工作日（等发票、等审批），关键状态同步到业务 DB（理赔单状态归业务系统，见 W5D4）；在"转人工审批"处暂停，审批结果回来后从断点恢复继续。工具副作用（提交审批）带幂等键防重复。
### Q13. 场景题：你的理赔 Agent 跑着跑着"进程重启了"，用户第二天回来接着办。如果不做任何状态处理会怎样？你会怎么改？ - **考察点**：状态持久化的业务后果与修复。 - **评分维度**：后果（内存态全丢、用户重来、可能重复副作用，4 分）；修复（Checkpointer+外部存储+幂等+断点恢复，4 分）。 - **参考方向**：内存态重启即丢→用户重述、上下文丢失、若此前已调有副作用工具则重复；改法：Checkpointer 每步快照+外部存储长周期状态+工具幂等+从断点恢复。
参考答案 不处理后果： - 内存态全丢，用户第二天回来上下文、已收集字段全无，被迫重述、重跑，体验差且重复烧 token。 - 若重启前已调用过有副作用工具（如"暂存草稿理赔单"）且未持久，恢复时若重跑会重复创建草稿。 - 多实例部署下，第二次请求可能打到另一台机器，状态同样全无。 改法： - 用 Checkpointer 每步落快照（session_id+步号），重启后从断点恢复，不重跑已完成步骤。 - 长周期状态（理赔单当前阶段）同步到外部存储（DB/Redis），跨进程可见。 - 所有副作用工具带幂等键（request_id），恢复重跑不会重复提交。 - 对"等人工审批"这类天然断点，主动暂停并持久，审批回流后 resume。
--- ## 评分汇总表（满分 117） | 题号 | 级别 | 主题 | 满分 | 你的得分 | |----|----|----|----|----| | Q1 | L1 基础 | Agent Loop 闭环 | 8 | | | Q2 | L1 基础 | 原型不能上生产的硬伤 | 8 | | | Q3 | L1 基础 | Tool Runtime 概念 | 8 | | | Q4 | L2 进阶 | 裁剪两类思路 | 9 | | | Q5 | L2 进阶 | 摘要策略实现 | 9 | | | Q6 | L2 进阶 | 裁剪与 KV Cache | 9 | | | Q7 | L2 进阶 | 状态存储位置 | 9 | | | Q8 | L3 深度 | Checkpointer 与幂等 | 10 | | | Q9 | L3 深度 | 隔离与 annotations | 10 | | | Q10 | L3 深度 | 裁剪保真度 | 10 | | | Q11 | L3 深度 | 可观测 Trace | 10 | | | Q12 | L4 场景 | 理赔 Agent 架构设计 | 9 | | | Q13 | L4 场景 | 重启状态恢复 | 8 | | | **合计** | | | **117** | | **达标线**： - 各档：L1 ≥ 20 / L2 ≥ 30 / L3 ≥ 32 / L4 ≥ 14。 - 总分 **≥ 93 分（约 80%）** 为本次面试达标；≥ 105（约 90%）为优秀。 - 任一 L3 题得分低于 6 分，建议回看《FDE-W5D1-Agent-Loop-企业扩展-学习手册.html》对应章节重做。