这是最重要的领域。占考试的 27%，比任何其他单一主题都高。它出现在三个主要场景中：客户支持解决方案智能体、多智能体研究系统和开发者生产力工具。
01 智能体循环
智能体循环是任何基于 Claude 的智能体的基本执行周期。工作流程如下：
- 通过 Messages API 向 Claude 发送请求
- 检查响应中的
stop_reason字段 - 如果
stop_reason是"tool_use"：执行请求的工具，将工具结果追加到对话历史，将更新后的对话发送回 Claude - 如果
stop_reason是"end_turn"：智能体已完成，展示最终响应
工具结果必须追加到对话历史中，这样模型才能在下一次迭代中对新信息进行推理。
你必须拒绝的三种反模式
考试测试三种错误的循环终止方式：
| 反模式 | 为什么是错的 |
|---|---|
| 解析自然语言来判断循环终止（如检查助手是否说了"我完成了"） | 自然语言具有歧义性和不可靠性。stop_reason 字段就是为此而存在的。 |
| 使用任意迭代上限作为主要停止机制（如"循环 10 次后停止"） | 要么截断有用的工作，要么运行不必要的迭代。模型通过 stop_reason 发出完成信号。 |
检查助手文本内容作为完成指标（如 response.content[0].type == "text"） | 模型可以在返回 tool_use 块的同时返回文本。文本的存在不等于完成。 |
模型驱动 vs 预配置
考试倾向于 模型驱动的决策 — Claude 根据上下文推理应调用哪个工具 — 而非预配置的决策树或工具序列。但对于关键业务逻辑，使用 程序化强制执行（在第 04 节介绍）。
练习场景
一个开发者的智能体有时会过早终止。他们的代码检查 if response.content[0].type == "text" 来判断是否完成。Bug： Claude 可以在返回 tool_use 块的同时返回文本。修复： 改为检查 stop_reason == "end_turn"。
02 多智能体编排
架构是中心辐射式的：
┌──────────┐
│ 协调器 │
└────┬──────┘
┌─────────┼─────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 子智能体 │ │ 子智能体 │ │ 子智能体 │
│ （网络搜索）│ │ （文档分析）│ │ （综合报告）│
└──────────┘ └──────────┘ └──────────┘
所有通信都通过协调器。 子智能体之间永远不直接通信。
关键隔离原则
这是多智能体系统中最常被误解的概念：
- 子智能体 不会 自动继承协调器的对话历史
- 子智能体 不会 在调用之间共享记忆
- 子智能体需要的每条信息都必须 显式地包含在其提示中
协调器职责
协调器负责：
- 任务分解 — 分析查询需求，动态选择要调用的子智能体
- 范围划分 — 分配不同的子主题或数据源类型以减少重复
- 迭代优化 — 评估综合输出中的缺口，用针对性查询重新委派
- 错误处理 — 所有通信通过协调器路由，确保可观察性
狭窄分解失败
考试测试你是否能将故障追溯到根本原因。示例：协调器将"AI 对创意产业的影响"分解为仅涉及视觉艺术的子主题，遗漏了音乐、写作和电影。根本原因是协调器的分解，而不是任何下游智能体。
练习场景
一个多智能体研究系统生成了一份关于"可再生能源技术"的报告，只涵盖了太阳能和风能，遗漏了地热能、潮汐能、生物质能和核聚变。正确答案指出 协调器的任务分解 是根本原因 — 不是网络搜索智能体，不是综合智能体，不是文档分析智能体。
03 子智能体调用与上下文传递
Task 工具
Task 工具是生成子智能体的机制。协调器的 allowedTools 必须包含 "Task"，否则无法生成子智能体。每个子智能体都有一个 AgentDefinition，包含描述、系统提示和工具限制。
上下文传递规则
- 将前序智能体的 完整发现 直接包含在子智能体的提示中
- 使用 结构化数据格式，将内容与元数据（来源 URL、文档名称、页码）分开，以保留归因
- 设计协调器提示时指定 研究目标和质量标准，而非逐步的程序化指令
并行生成
在协调器的单次响应中发出多个 Task 工具调用，以并行生成子智能体。这比跨多个回合的顺序调用更快。考试测试延迟感知。
fork_session
从共享分析基线创建独立分支。用于探索不同方法（如从同一代码库分析中比较两种测试策略）。每个分叉在分支点后独立运行。
练习场景
综合智能体生成的报告中有些声明没有来源归因。网络搜索和文档分析子智能体工作正常。根本原因： 上下文传递未包含结构化元数据。修复： 要求子智能体输出结构化的声明-来源映射。
04 工作流强制执行与交接
强制执行层次
| 级别 | 机制 | 可靠性 | 适用场景 |
|---|---|---|---|
| 提示引导 | 系统提示中的指令 | 大多数时候有效，失败率非零 | 低风险：格式、样式 |
| 程序化强制 | 钩子或前置条件门控 | 百分百有效 | 高风险：财务、安全、合规 |
考试的决策规则： 当后果涉及财务、安全或合规时，使用程序化强制执行。考试会在高风险场景中将提示引导方案作为选项。拒绝它们。
多关注点请求处理
- 将包含多个问题的请求分解为不同的项目
- 使用共享上下文并行调查每个问题
- 综合为统一的解决方案
结构化交接协议
在升级给人工客服时，编制：客户 ID、对话摘要、根因分析、退款金额（如适用）、建议操作。人工客服没有对话记录的访问权限。 交接摘要必须是自包含的。
练习场景
生产数据显示，8% 的情况下，客户支持智能体在未验证账户所有权的情况下处理退款。四个选项：
- A）程序化前置条件门控
- B）增强系统提示
- C）少样本示例
- D）路由分类器
答案：A。 前置条件门控在验证确认之前物理阻止退款工具。B、C、D 都是概率性的 — 能减少但无法消除失败。
05 Agent SDK 钩子
PostToolUse 钩子
在工具执行后、模型处理结果前拦截工具结果。
用例： 规范化来自不同 MCP 工具的异构数据格式。Unix 时间戳转为 ISO 8601。数字状态码转为人类可读的字符串。无论数据来源如何，模型都收到干净、一致的数据。
工具调用拦截钩子
在工具执行前拦截传出的工具调用。
用例：
- 阻止超过 $500 的退款并重定向到人工升级工作流
- 强制执行合规规则（某些操作需要经理审批）
决策框架
| 机制 | 保证 | 适用于 |
|---|---|---|
| 钩子 | 确定性（100%） | 绝不能失败的业务规则 |
| 提示 | 概率性（约 95%） | 偏好和软性规则 |
经验法则： 如果单次失败就会让企业亏钱或面临法律风险，使用钩子。
06 任务分解策略
固定顺序管道（提示链）
将工作分解为预定的顺序步骤：
分析每个文件 → 运行跨文件集成检查 → 生成报告
- 最适合： 可预测的结构化任务（代码审查、文档处理）
- 优势： 一致且可靠
- 局限： 无法适应意外发现
动态自适应分解
根据每一步的发现生成子任务：
映射结构 → 识别高影响区域 → 创建优先计划 → 随依赖关系出现而调整
- 最适合： 开放式调查任务
- 优势： 适应问题本身
- 局限： 可预测性较低
注意力稀释问题
在单次处理中分析过多文件会导致深度不一致。某些文件得到详细反馈，其他文件中明显的 Bug 被遗漏。相同的模式在一个文件中被标记为问题，在另一个文件中却被通过。
修复： 拆分为逐文件的本地分析 加上 单独的跨文件集成检查。本地分析一致地捕获局部问题。集成检查捕获跨文件的数据流问题。
07 会话状态与恢复
三种选择
| 方法 | 适用场景 |
|---|---|
--resume <session-name> | 先前上下文基本有效，文件未发生重大变化 |
fork_session | 需要从共享分析点探索不同方向 |
| 带摘要注入的全新开始 | 工具结果已过时、文件已更改或上下文已退化 |
过时上下文问题
在代码修改后恢复会话时，告知智能体 具体的文件变更 以进行有针对性的重新分析。不要要求从头重新探索。带注入摘要的全新开始比恢复带有过时工具结果的会话更可靠。
08 学习资源
- Agent SDK 概述 — 智能体循环机制和子智能体模式
- 使用 Claude Agent SDK 构建智能体 — 钩子、编排、会话
- Agent SDK Python 仓库 + 示例 — 钩子、自定义工具、
fork_session的实操代码
09 动手构建
构建一个多工具智能体：
- 3-4 个 MCP 工具，配合正确的
stop_reason处理 - 一个 PostToolUse 钩子，规范化数据格式
- 一个工具调用拦截钩子，阻止违反策略的操作
- 一个协调器，包含两个子智能体（网络搜索 + 文档分析）
- 带结构化元数据的正确上下文传递
- 一个程序化前置条件门控
这个单一练习覆盖了领域 1 的大部分内容。