Claude 子代理与上下文隔离，一次讲清

Claude 子代理运行在隔离的上下文里：每个子代理都是一次全新会话，不继承协调者的任何对话历史、工具结果或先前发现，只知道协调者写进任务提示词的内容。这种隔离是有意为之。它把冗长的探索过程挡在主上下文之外，让每个专家用一小组与角色匹配的工具工作，并且逼协调者显式交接事实——正是这一点让结果可聚合、可审计。

它同时也是多 agent 系统里最常见的 bug 来源，Claude Certified Architect – Foundations 考试的领域 1（Agentic Architecture & Orchestration，27%）反复回到这个点上。

子代理为什么从空上下文启动？

三个原因，每一个都会出现在考题的解析里。

**上下文预算。**在主会话里读 45 个文件可能吃掉四分之三的上下文窗口，拖累之后的每一步；同样的探索委派给一个隔离的 Explore 子代理，覆盖了 120 个文件，回来的摘要只占 12% 的上下文。主会话把预算留给实现。参见探索了 120 个文件，只用了 12% 上下文，以及领域 5 的子代理委派：让别人来装数据。

**工具选择准确率与最小权限。**子代理也不继承协调者的工具。每个 AgentDefinition 列出自己的 tools；不写这个字段，子代理会继承全部工具，包括它不该有的 Bash 和 Write。一个只有 [Read, Grep, Glob] 的代码审查 agent 在结构上就改不了文件；在 3–5 个工具里选，也远比面对 18 个可靠。参见 Task Tool、allowedTools 和 AgentDefinition 完整配置面和 Foundations 篇的子代理：协调者委派，专家执行。

**显式交接。**因为没有任何东西隐式共享，协调者必须决定每个专家需要什么。这条约束让输出可比较、来源可追溯。它还打消了加 Redis 或共享数据库的念头：基于提示词的上下文传递已经解决了问题，而且没有竞态条件。

考试要戳的误解是”子代理会看到协调者已经找到的东西”。它看不到。经典症状是重复劳动：协调者已经找到五篇关键论文，发出”分析研究发现”，子代理跑去重新搜索。参见子代理什么也看不到：上下文必须显式传递。

hub-and-spoke 编排怎么利用隔离？

hub-and-spoke 里每条消息都经过协调者。子代理之间从不互相调用。协调者拆解请求，只委派给这次请求需要的专家（大约 70% 的客服工单只需要一个），聚合结果，解决冲突，处理部分失败，最后综合。换成 mesh——agent 调 agent——这些职责会分散到从未为此设计的组件上：某个环节失败时，没人负责重试。

协调者提示词应该设定目标和质量标准，而不是死板的步骤清单。学习数据里，目标导向的协调者提示词得 82 分，流程式的得 68 分，主要原因是 45% 的查询在任务中途换策略会更好（“搜到两篇论文和一份政府报告”不该因为第 1 步写的是”论文”就被丢掉）。把自适应的策略和固定的输出格式分开，审计方仍然拿到可预期的报告。参见 Hub-and-Spoke：所有路径都经过协调者和目标 + 标准胜过按步骤来：82 vs 68 质量分。

机制层面，委派就是 Task 工具，三个必填输入（description：3–5 个词的日志标签；prompt：带上下文的完整任务；subagent_type：某个 AgentDefinition 的键）和四个响应字段（result、usage、total_cost_usd、duration_ms）。协调者自己的允许工具里必须有 Task，否则委派直接失败；还得明确告诉它使用 result 字段，不然它可能凭自己一无所知的猜测作答。参见 Task Tool：三个输入，四个响应字段，一个常见 bug。

一次结构化交接应该包含什么？

精选、结构化、针对具体任务的上下文，而不是完整历史。某生产系统原本给三个子代理每个都发 25,000 token，实际上搜索 agent 大约只需要 500（查询加范围），分析 agent 大约 3,000（论文加标准），综合 agent 大约 8,000（全部发现）。反过来，完整性也直接决定质量：拿到完整客户和订单上下文的账单子代理得 92 分，只拿到一个名字的账户子代理得 65 分。

有两样东西团队常常忘记传：子代理必须遵守的领域规则（安全策略、编码规范），以及协调者要用来聚合的输出格式。结构化 JSON 保留归因，散文摧毁归因。一条”多项研究显示快速增长”的发现没法核实；写成带 URL、日期、摘录的 claim-source 对象就能核实。某个案例里，下游 agent 收到叙述式摘要后给出了 35% 的错误文件路径；改成 {"file": ..., "line": ..., "issue": ...} 之后问题消失。两个来源冲突时，保留双方并标注出处，不要平均成一个谁都没报过的数字。参见结构化数据保留归因，纯文本摧毁归因；同一思路在人工升级场景下的版本，见缺少客户期望让满意度暴跌 23 分。

子代理什么时候该并行跑？

只要彼此独立就并行。协调者在一次响应里发出多个 Task 调用，它们就并发执行；总耗时变成最慢的那个 agent，而不是各项之和。三个 30 秒的 agent 只花 30 秒而不是 90 秒，token 成本完全一样。

独立的并行，有依赖的串行。OCR、NLP、校验不能并排跑，但文档 A 和文档 B 可以。混合的依赖图分阶段处理：把没被阻塞的全部跑掉，收集结果，再跑刚被解锁的。某个并行分支失败时，保留成功的结果，用结构化上下文记录失败，然后要么单独重试那个分支，要么带着明确的缺口标注继续——绝不能悄无声息地略过。参见并行执行：墙钟时间减少 80%，零额外成本。

Resume、fork，还是开新会话？

隔离是默认状态，但把后续工作和先前工作关联起来有三种方式。

需求	机制	原因
同一任务的线性跟进（“现在给出修复建议”）	用子代理的 session_id resume	保留已积累的上下文；比重新注入少约 85% 的提示词 token
从同一基线比较多个备选方案	每个备选 fork 一个会话	避免锚定偏差：fork 评估与专家一致率 89%，顺序评估 62%
不相关的新任务	新会话	先前上下文只是噪音和预算浪费

fork 的成本（约 1.8 倍）只在真正分岔的探索上才划算；有个团队每个任务 fork 十二次，其中只有三次是分岔，另外九次是澄清，本该用 resume。fork 之间不要共享发现，综合要交给一个没参与任何分支的协调者。拿到的每个 session_id 都缓存起来，它们只是廉价的字符串，但没有它就没法 resume。在 Claude Code 里，Skill 上的 context: fork 隔离的是对话，不是文件系统：fork 写下的文件会保留，它冗长的推理过程不会。参见 Resume 节省 85% Token，支持多次后续跟进、Fork 消除锚定偏差：89% vs 62% 准确率和 Fork 隔离记忆，不隔离文件系统。

一个完整的例子

一个客服协调者收到：“订单 8812 被重复扣款了，我要把多扣的那笔退回我的卡。“它自己的上下文里已经有验证过的客户 ID、两条扣款记录，以及”超过 500 美元的退款需要审批”这条策略。

弱的协调者把”看看这个客户的退款问题”丢给账单子代理。子代理从零开始，重新查客户，可能漏掉第二笔扣款，返回一段散文。质量下降，token 翻倍。

好的协调者给账单子代理的任务提示词里包含：客户 ID（已验证，不要重复验证）、带 ID 和金额的两条扣款记录、退款策略分级、客户明确表达的期望（退到卡上，不要商店积分），以及必填的输出 schema（{duplicate_charge_id, refund_amount, needs_approval, customer_message}）。只有请求需要时它才并行跑一次物流状态检查；这里不需要。如果退款超过 500 美元，process_refund 上的 PreToolUse hook 会拒绝并转向升级流程，不管哪个 agent 推理出了什么。子代理返回后，协调者读取 result，保留 session_id 以备客户追问，然后起草回复。

第二个版本的每一处改进都来自认真对待隔离：把已知的传过去，把能做的限制住，把返回的结构化。

下一步

按顺序读领域 1 学习指南的任务 1.2 和 1.3，然后做领域 1 练习题，留意那些错误选项默认存在共享状态的情景。免费的 60 题模拟考按官方 27% 的权重出领域 1 的题，编排类题目会占很大比例。125 美元报名费、120 分钟形式等当前考试信息，报名前请到 Anthropic / Pearson VUE 官方页面核对。