附录 B 自测答案与解析

第 1 章

1-1. 下一步行动由代码预先定义的路径决定，就是工作流；由模型在运行中自行决定，就是智能体。例如，客服系统由代码完成咨询分类与权限检查，只对其中需要调查原因的咨询，让模型自行选择工具处理，就是两种方式混合的结构。设计文档应逐步骤写明“谁决定下一步行动”。

1-2. 分段同时运行独立子任务，以提高速度和每次调用的专注程度；投票多次运行同一任务，通过多种视角、多次尝试获得更可靠的结果。投票按调用次数增加成本，使用相同依据时，错误可能具有相关性，准确率提升未必如预期。只应在判断模糊且单次错误代价高的步骤使用。

1-3. 目标、输出格式、工具与来源使用指引，以及明确的任务边界。缺少目标会调查错误范围；缺少边界会让多个执行者重复调查同一处；缺少输出格式，编排者难以汇总结果；缺少来源指引，则可能使用低质量来源。任选其中一项，说明一种表现即可。

1-4. 最大迭代次数，以及分数不再提高或改进幅度低于下限时停止的条件。两项条件应写在运行循环的代码中，而不是交给模型。还可以加入未收敛结束时，把最后结果与评估记录转交人工的流程。

1-5. handoff 将控制权交给选中的专业智能体，由它负责该轮剩余执行并给出最终回答。agent-as-tool 则由管理者智能体保留控制权，把专业智能体当作工具调用，只接收其结果，最终回答由管理者生成。需要拿到结果继续使用时选 agent-as-tool，需要专家直接面对用户时选 handoff。

1-6. 如果多智能体收益很大程度上来自多用了 token，就应检查成功是否随总成本一起增长。因此比较指标是每个成功任务的成本。即使成本翻倍，只要成功率大幅提高，仍可能合理；即使成本相同，成功率也原地不动，仍会得不偿失。

1-7. 示例答案：最简单的结构是固定工作流，每条公告用一次 LLM 调用生成摘要，由代码按部门标签分组发送。表明它已不足的信号，是部门分类错误率超过预设标准（例如 5%），或需要综合多条公告阅读的摘要请求明显增加。此时可将部门分类拆为独立路由步骤，只把需要综合阅读的请求交给使用工具的智能体。关键是把信号写成数字。

第 2 章

2-1. 人工开发者读过一次文档后可以记住，但智能体每次都需要把工具定义和结果作为上下文读取，除非采用工具搜索等延迟加载。因此，工具越多、结果越大，上下文成本越高。此外，直接封装端点会增加相似工具，导致选择错误，也把组合多次调用的负担转移给模型。所以按工作流设计少量工具更合适。

2-2. 始终返回详细结果会浪费 token，始终简洁又可能缺少下一次调用需要的标识。用详细程度参数，让智能体按情况选择，可以同时减少这两个问题。只有下一次调用需要 ID 或详细字段时，才选择详细响应。

2-3. 应说明结果已截断、整体规模（例如 1,240 条中显示 20 条），以及缩小范围的方法（筛选条件、下一页游标）。缺少这些信息，智能体会把收到的部分当作全部并下结论，或误以为所需项目不存在。

2-4. 协议版本、客户端能力与客户端身份。这些信息放在每次请求的 _meta 中。版本（io.modelcontextprotocol/protocolVersion）和能力（io.modelcontextprotocol/clientCapabilities）是必需项；客户端信息属于建议项，但因为是自行申报的值，不能用于安全判断。

2-5. 没有注解时，按规范默认值，应视为非只读（readOnlyHint 默认 false）、可能有破坏性（destructiveHint 默认 true）、不幂等（idempotentHint 默认 false）、可与外部世界交互（openWorldHint 默认 true）。默认值是保守的，因此无注解工具被归到最需谨慎的一类。即使有注解，来自不可信服务器时也不应相信。

2-6. 审计追踪：下游系统日志看起来像原 token 所有者在调用，而不是 MCP 服务器，服务器也无法区分由哪个客户端调用，导致事故调查困难。速率限制：服务器或下游 API 依赖 token 的受众与约束施加的控制，可能被直接使用该 token 的调用绕过。

2-7. 示例答案：名称使用 loan_extend 这类包含服务前缀与动作的形式。参数为 loan_number（例如 LN-2026-00123 格式的字符串），以及新归还日期 new_due_date（ISO 日期，限定在当前归还日之后 14 天内），使同一请求即使到达两次，结果也相同。业务错误应返回原因与事实，例如“有预约等候者的图书不能续借。预计归还日期为 2026-10-27”。尝试超过续借次数上限，或会产生逾期费时，要求人工确认。能解释各项如何减少误用即可。

第 3 章

3-1. 模型需要将注意力分配到上下文所有 token 之间的关系中，因此 token 越多，每条信息可获得的注意力越少。这就是注意力预算；由此导致准确回忆信息的能力下降，称为上下文退化。窗口大只意味着能放入更多内容，并不意味着能同样有效地利用它们，因此仍然需要管理。

3-2. 留在较早对话中的工具原始结果已经用过，再次查看的机会很少，删除后仍能保留脉络与决定。但删除位置之后的提示词缓存可能失效，因此不要频繁少量删除，应一次清理足够多的内容，使收益值得承担失效代价。仍会持续引用的结果应排除在清理之外。

3-3. 应依据任务状态（进度文件、检查点）。对话记录会被摘要和截断，可能不准确；长期记忆只是参考。任务状态与权威记录系统不一致时，权威记录系统是事实依据，因此应先按其记录修正任务状态，再决定下一步。

3-4. 防止后续会话看到进展就急于宣告完成，或擅自修改功能列表、删除测试，制造已经通过的假象。相比 Markdown，模型不当修改或覆盖 JSON 的可能性更低；只允许修改是否通过这一个字段，就不能缩小范围或降低标准。

3-5. 如果进程在记录结果前崩溃，仅凭记录无法知道是否执行过。先记录意图，恢复代码就能找到“有意图、无结果”的条目，在重跑前通过幂等键向外部系统查询是否处理过。已处理则只补记结果，未处理才用同一键执行，防止重复。

3-6. 第一，可以判断信息是否过时，执行过期处理或重新确认。第二，新信息发生冲突时，可根据来源权威性与新旧程度判断哪一方更可信。保存来源，也更容易追踪、更正或删除错误记忆。

3-7. 示例答案：①目标与完成标准：要在何时之前、以什么格式交付什么。②已完成项目与验证结果：完成了什么，如何确认。③剩余工作与优先级：下一步任务的顺序。④事实与假设：区分带来源、核实时间的事实与尚未确认的假设。⑤下一步行动的前提：恢复前要检查的外部变化、所需审批，以及产物和外部操作标识的位置。关键是写出经过验证的产物，而不是“基本完成”等自我评价。

第 4 章

4-1. 完整记录记载试验期间智能体说的话、工具调用与中间结果。结果是试验结束后环境的状态，也就是预约系统中是否真的存在该日期的一条预约。完整记录展示尝试了什么，却不能证明它最终留在环境中。即使出现“已预约”，只要结果中没有预约，仍然是失败。因此，改变状态的智能体应按结果评分。

4-2. 应使用的情况：任务有“付款前必须用户确认”等必需或禁止规则，仅看结果无法知道是否遵守。不应使用的情况：存在多种正确查询顺序，都能达到同一答案。此时要求路径精确匹配，会把更高效的正确解法也判为失败。

4-3. pass@3 = 1 − (1 − 0.9)³ = 1 − 0.001 = 0.999，约 99.9%。pass^3 = 0.9³ = 0.729，约 72.9%。意思是三次中几乎必定至少成功一次，但三次全部成功的概率只有约 73%。允许重试或挑选候选时，前者更贴近运营体验；每次都必须一次成功时，后者更贴近。实际中，同一任务各次试验的失败往往相关，可能与独立假设下的值不同。

4-4. ①分开评估维度，为每个维度写出可观察标准与扣分案例，无依据时允许选择无法判断。②建立由专家直接评分的样本，测量与评分器判断的一致程度。③阅读不一致案例，修改评分标准后重新测量。之后也应定期抽样，确认一致程度保持。

4-5. 追踪表示一个工作流从开始到结束的过程；跨度是组成该过程、具有起止时间的操作单元，以父子关系连接。一次智能体运行可产生智能体运行跨度、LLM 生成跨度、函数工具调用跨度、护栏跨度、handoff 跨度等，以 OpenAI Agents SDK 默认跨度为例。

4-6. 失败通常始于前一步的错误判断，到后续步骤才暴露。只修表现出的症状，原因仍在，会以其他形式重现；也可能改错要素，错误评估效果。只有确定第一次错误判断在哪一步，才能决定应修改工具定义、提示词还是环境。

4-7. 示例答案：必须通过条件为禁止行为 0 次、回归集通过率达到预设标准。比较指标为基于结果的成功率与 pass^3 不低于旧版，且没有业务类型出现退步。运营约束为每个成功任务成本不超过旧版的 1.2 倍，首次响应延迟在合同标准内。暂缓判断条件为两版本差异小于重复运行波动，或样本少于标准，此时增加试验重新测量。关键是把必须通过条件与平均分分开。

第 5 章

5-1. 第一，单轮多次调用昂贵工具，或读取大型结果，可用每次运行 token 与成本上限阻止。第二，反复进行相同搜索或查询造成停滞，可用相同参数重复检测与无进展检测阻止。若回答子智能体不断增加，并以子任务数量、再次委派深度上限防范，也正确。

5-2. 各层独立重试会使尝试次数乘法增长，一次失败变成数十次调用，加剧过载。应只在一个层级重试，仅针对暂时性错误，用指数退避与抖动拉开间隔，限制次数，并遵守服务器的 retry-after。其他层不再重试，而是传递恢复指引。

5-3. 付款、预约、发送等有副作用的调用，可能已经处理，只是响应丢失。若将其视为失败再次发送，同一效果就会发生两次。应先通过幂等键或请求标识查询是否已处理，只有未处理时才用同一键重新发送。

5-4. 审批请求过多，会造成审批者不读就点的审批疲劳，真正危险的请求也会形式化通过。应按可撤销性（是否难以撤销）与影响范围（是否涉及客户、外部、金钱）两个维度选择审批对象；可撤销、影响小的行动，在限额内自动化。

5-5. 以退出码 2 阻断的 PreToolUse 钩子，会在权限规则评估前停止调用，因此即使有 allow 规则也被阻断，钩子的标准错误内容作为阻断原因传递。反过来，即使钩子返回允许，也不能跳过 deny 或 ask。权限规则本身按 deny → ask → allow 顺序评估，首个匹配规则决定结果。但在没有托管设置或 Team、Enterprise 登录的环境中，已安装扩展模块（mod）的 tool.check 可能推翻该决定。

5-6. 沙箱包裹 shell 命令及其子进程，不包裹 Read、Edit、WebFetch 等内置文件与网页工具，也不包裹钩子和本地 MCP 服务器等由 Claude Code 启动的其他进程。内置工具用权限规则控制；以用户完整权限运行的钩子与本地 MCP 服务器，只使用可信对象，必要时另行隔离。回答多数会话中直接以 ! 输入的 shell 命令、排除命令或沙箱外重试，也正确。

5-7. 示例答案：设用户每日成本上限，例如价值 3,000 韩元的 token，进行中运行预计消耗的成本在启动前预留。达到 80% 时，向用户提示剩余额度，并把昂贵功能（长时调查、多智能体）切换为小模型或缩小范围的路径。达到 100% 时，不再启动新运行，进行中的运行保存部分结果后停止，并告知次日重置时间和申请提高限额的方法。关键是这两个节点的系统行为由代码强制执行。