子 Agent 与编排模式

一句话定义

编排（orchestrator-worker）是用一个主 Agent 负责理解、分解与整合，把子任务分派给独立运行的子 Agent、只收回结论不收回过程的结构——它的最大价值不是"并行"，而是上下文隔离：脏活（海量工具输出）留在子 Agent 的窗口里烂，主 Agent 的窗口保持干净。

为什么重要

Anthropic 2025 年公开其多 Agent 研究系统的复盘时给出了一条反直觉结论：他们尝试让多个对等 Agent 民主协作，效果远不如中心化编排——"多 Agent 系统中 token 消耗涨 15 倍，但研究型任务的性能提升同样显著"，而性能提升的主要来源正是 orchestrator-worker 的分解与隔离，不是"Agent 之间的对话"。同时这是 Claude Code 的架构基石（kp-028：主循环 + 按需拉起 subagent），也是长任务不腐烂的关键手段（kp-022 的隔离操作）。

前置知识

kp-013（规划分解）、kp-017（手写循环——子 Agent 就是"循环套循环"）、kp-003（上下文预算）。

核心概念

结构：树而非网

主 Agent（orchestrator）
 ├── 子 Agent A（查文献）──→ 返回：3 条带引用的结论（2KB）
 ├── 子 Agent B（跑数据分析）──→ 返回：指标表 + 一段解读
 └── 子 Agent C（竞品扫描）──→ 返回：结构化对比清单
主 Agent 整合 → 最终报告

与 kp-020"多 Agent 协作"的区别：编排是树形的主从结构，控制权集中在 orchestrator；协作（对等谈判、辩论）是网状结构。2025 年的工程共识明显偏向树形。

子 Agent 的三要素

独立上下文：子 Agent 有自己的消息历史与工具集，与主 Agent 不共享——这是隔离的全部意义
任务简报：主 Agent 下发的 prompt 要自包含（子 Agent 看不到主对话）：目标、约束、期望返回格式
返回契约：只回传"结论 + 关键证据"，不是过程流水——回传内容的设计就是接口设计（kp-010 思想的复用）

触发模式：静态与动态

静态子 Agent（Claude Code subagents 模式）：预先定义好的专家（code-reviewer、db-expert），带专属系统提示与工具集，主 Agent 按名调用——像公司的专业岗位
动态子 Agent（research 模式）：orchestrator 根据任务现场生成子任务 prompt，临时拉起——像临时项目组

原理与机制

为什么隔离如此有效？回到上下文腐烂（kp-003）：一次网页抓取产生 30K token 的脏数据，在单 Agent 里永远留在窗口中稀释注意力；在子 Agent 里，这 30K 随子 Agent 结束而消失，主窗口只留 2KB 结论。信息被"蒸馏"了。

并行的收益同样是机制性的：三个子任务无依赖时并行执行，总延迟 ≈ 最慢的一个（kp-013 的依赖图直接决定可并行度）。Anthropic 复盘给出的数字：并行编排使研究任务的延迟大约减半，token 消耗升一个数量级——多 Agent 是用 token 买质量与速度，这是要写进预算的决策（kp-027）。

失败传播是反向机制：子 Agent 失败时，主 Agent 收到的是失败报告（可重派/换法），错误不会污染主上下文——这是树形优于网形的深层原因：网状结构里一个节点的幻觉会顺着对话扩散给所有节点。

直观类比

主编排者 = 合伙人，子 Agent = 他带的顾问：合伙人自己不翻 500 页原始卷宗（脏数据），而是给每位顾问一份清晰的任务书（自包含简报），顾问各自翻完写一页纪要（返回契约）。合伙人的桌面（主上下文）永远只有纪要——所以他随时能抓住全局。反例（网状协作）是"委员会"：十个人围桌互相说话，谁的话都在污染所有人的记忆，最后谁也不对结论负责。

实例与案例

在 kp-017 的最小 Agent 上加一个子 Agent（伪代码展示机制）：

pythondef spawn_subagent(brief: str, tools: list) -> str:
    """独立上下文跑一个完整循环，只返回最终文本"""
    messages = [{"role": "user", "content": brief}]      # 自包含简报
    for _ in range(15):
        resp = llm(messages, tools=tools)
        if resp.stop_reason != "tool_use":
            return resp.text                              # ★ 只回传结论
        messages += [resp.content, run_tools(resp)]       # 脏数据留在这里
    return "（子任务超时未完成）"

# 主 Agent 的工具箱里注册：
# {"name": "spawn_researcher", "description": "派一个研究子Agent查指定主题，
#   返回带引用的结论摘要（≤500字）", "input_schema": {brief: string}}

主 Agent 从此有了" delegation "能力；注意它对主上下文只是一个普通工具调用（kp-009 协议复用）。

常见误区

误区一：为并行而并行。有依赖的子任务强行并行 → 结果互相矛盾，返工成本更高。先做依赖分析（kp-013）。
误区二：简报写一句话。"帮我查一下竞品"这种简报会让子 Agent 返回无用信息——简报要带：目标、范围边界、输出格式、字数上限。
误区三：子 Agent 返回全量过程。隔离的价值被回传打穿；返回契约要限"结论+证据"。
误区四：嵌套过深。子生孙、孙生曾孙，误差层层放大、预算层层失控——实用深度是 2 层（主 + 子）。
误区五：把编排当复杂度炫耀。能单 Agent 干完的任务（尤其上下文不膨胀的）拆成多 Agent 是纯浪费（Anthropic 复盘原文：token ×15 不是免费午餐）。

自测题

编排结构最大的工程价值是什么？机制上如何实现？
好的任务简报包含哪四要素？
为什么 2025 年共识是树形而非网状协作？

（参考答案：1. 上下文隔离而非并行本身；子 Agent 的脏输出随其结束消失，主窗口只收蒸馏后的结论；2. 目标、范围边界、输出格式、长度上限；3. 网状中幻觉沿对话扩散且无人对结论负责，树形错误不污染主上下文、失败可定点重派。）

与其他知识点的关系

对等协作（网状）→ kp-020；分解策略 → kp-013
上下文隔离在长任务的系统应用 → kp-022；Claude Code 实战 → kp-028
token 预算 → kp-027