1.2　用协调者-子 Agent 模式编排多 Agent 系统

这一条考什么

考你是否掌握"协调者（coordinator）+ 子 Agent（subagent）"的中心辐射（hub-and-spoke）架构：协调者负责拆解任务、选择并委派子 Agent、汇总结果、处理错误，子 Agent 之间不直接通信。题目常以"多 Agent 研究系统"为背景，要求你判断如何按查询复杂度动态选择子 Agent、如何划分研究范围以减少重复、以及在综合结果有缺口时如何形成迭代改进循环。

核心概念

中心辐射架构

在 hub-and-spoke 模式中，协调者是唯一的"枢纽"：

• 所有子 Agent 只与协调者交换信息，不互相调用。
• 错误由协调者统一接收并决定处理方式（重试、换子 Agent、降级、上报）。
• 信息路由由协调者控制：哪个子 Agent 能看到哪些前序结果，由协调者在委派时显式决定。

这样做的收益是可观测性（所有交互都经过一处，便于日志与追踪）、一致的错误处理（不会出现各子 Agent 各自为政的重试策略）和受控的信息流（避免无关或敏感信息扩散到不需要它的 Agent）。

子 Agent 运行在隔离的上下文中

子 Agent 启动时拿到的是一个全新的上下文窗口：它不会自动继承协调者的对话历史、系统提示里的细节或之前的工具结果。它能知道的只有协调者在委派时写进任务提示里的内容（以及它自己的系统提示和工具）。因此协调者必须把子 Agent 完成任务所需的事实、约束、前序发现明确地传过去（细节见 1.3）。这种隔离同时也是优点：每个子 Agent 的上下文干净、聚焦，不会被其他分支的大量中间内容稀释注意力。

协调者的职责

1. 任务分解：把用户问题拆成若干可独立推进的子问题。
2. 委派：为每个子问题选择合适的子 Agent，并写清目标与质量标准。
3. 结果汇总：收集子 Agent 输出，交给综合（synthesis）子 Agent 或自己整合。
4. 按复杂度选择子 Agent：简单事实题可能只需一次搜索甚至由协调者直接回答；对比型、分析型研究才需要搜索、文档分析、综合、报告生成全部参与。

"总是走完整条流水线"是典型反模式：简单查询白白耗费几十秒和大量 token。同样，"训练一个分类器来预测子 Agent 组合"或"用固定的模式匹配把查询分成三类再映射"都过于僵化或过度工程化——协调者本身就是 LLM，最合适的做法是让它分析每个查询的需求后动态决定调用哪些子 Agent。

分解过窄的风险

如果协调者把一个宽泛主题（例如"AI 对医疗行业的影响"）只拆成"影像诊断"和"药物研发"两个子题，即便每个子 Agent 都完美完成任务，最终报告也会遗漏临床运营、监管、伦理等维度。覆盖不足的根源在分解阶段，而不是子 Agent 的执行质量。应对方式：

• 让协调者在分解时显式列出主题的各个维度，并检查是否覆盖了用户问题的全部范围。
• 为子 Agent 分配互不重叠的范围：按子主题划分，或按信息源类型划分（学术论文 / 新闻 / 官方统计），从而既扩大覆盖又减少重复劳动。

迭代改进循环

线性流水线（搜索 → 分析 → 综合 → 报告）在综合阶段发现缺口时无路可退。更好的做法是把综合结果当作一个评估检查点：

1. 协调者评估综合输出，对照研究问题找出未回答或证据不足的部分。
2. 针对缺口生成有针对性的新查询，重新委派给搜索、文档分析子 Agent。
3. 拿到补充结果后再次调用综合子 Agent。
4. 重复直到覆盖达到预先定义的标准，再进入报告生成。

注意这里由协调者驱动循环，因为它掌握研究计划和委派权；让报告生成 Agent"在报告里注明哪些问题没答上"只是暴露问题而不是解决问题；"一开始就把查询放宽"则会增加噪声却无法保证命中具体缺口。

正确做法与反模式

• 正确：协调者逐个分析查询需求，动态挑选需要的子 Agent。反模式：无论问题简单与否都跑完整条四段流水线。
• 正确：按子主题或信息源类型为子 Agent 划分不重叠的范围。反模式：给多个搜索子 Agent 发几乎相同的任务，导致结果大量重复。
• 正确：协调者评估综合结果的缺口，定向再委派，再综合。反模式：综合后直接生成报告，由报告"声明局限"。
• 正确：所有子 Agent 的通信、错误都经由协调者路由。反模式：让子 Agent 互相直接调用或共享一个可随意读写的全局状态，导致难以追踪与调试。
• 正确：协调者已有足够上下文时直接回答简单的跟进问题。反模式：每次都启动子 Agent 并传入大量已积累的内容。

常见陷阱

• "训练一个查询复杂度分类器并定期再训练"——看似专业，但过度工程化，且无法像 LLM 协调者那样逐题推理需求。
• "为事实类问题建快速通道，其余全部走完整流水线"——只是把一刀切变成两刀切，复杂度中间档仍然浪费。
• "增加初始查询广度以降低遗漏概率"——无法定位具体缺口，正确答案通常是协调者评估缺口后定向再委派。
• "让报告生成 Agent 列出未回答的问题"——只是告知用户局限，并未补齐覆盖。
• "让子 Agent 直接互相请求输出 / 通过回调互相调用"——破坏中心辐射架构的可观测性和错误处理一致性。

实操练习

目标：用 Claude Agent SDK（Python）搭一个最小的协调者 + 两个子 Agent，体验动态选择与范围划分。

1. 安装：pip install claude-agent-sdk（需要本机已安装 Claude Code CLI 并配置好 API key）。
2. 保存下面脚本为 coordinator.py。
3. 分别用一个简单事实题和一个对比型研究题运行，观察协调者调用了几个子 Agent。

import asyncio
from claude_agent_sdk import (
    query, ClaudeAgentOptions, AgentDefinition,
    AssistantMessage, ToolUseBlock, ResultMessage,
)

agents = {
    "academic-researcher": AgentDefinition(
        description="检索学术论文与综述类来源。只负责学术文献，不处理新闻。",
        prompt="你是学术研究员。返回要点列表，每条附来源标题与 URL。",
        tools=["WebSearch", "WebFetch"],
    ),
    "news-researcher": AgentDefinition(
        description="检索近两年的新闻与行业报道。只负责新闻类来源。",
        prompt="你是行业新闻研究员。返回要点列表，每条附来源标题、日期与 URL。",
        tools=["WebSearch", "WebFetch"],
    ),
}

SYSTEM = (
    "你是研究协调者。先判断问题复杂度：简单事实题可直接回答或只调用一个子 Agent；"
    "对比/分析型问题按信息源类型分工，避免子 Agent 范围重叠。"
    "汇总后检查是否有未覆盖的子问题，如有则针对缺口再次委派。"
)

async def main(question: str):
    options = ClaudeAgentOptions(
        system_prompt=SYSTEM,
        agents=agents,
        allowed_tools=["Task", "WebSearch", "WebFetch"],  # 新版 SDK 中该工具名为 "Agent"
        max_turns=30,
    )
    async for msg in query(prompt=question, options=options):
        if isinstance(msg, AssistantMessage):
            for block in msg.content:
                if isinstance(block, ToolUseBlock):
                    print("工具调用:", block.name, str(block.input)[:120])
        elif isinstance(msg, ResultMessage):
            print("最终结果:", msg.result)

asyncio.run(main("比较 2024-2025 年固态电池在学术界与产业界的进展"))

检查结果：对比型问题应同时调用两个子 Agent（且各自任务范围不同）；把问题换成"巴黎气候协定哪一年签署？"时，协调者应只做最少的调用或直接回答。再观察汇总后协调者是否会针对缺口发起第二轮委派。

自测清单

• 中心辐射架构在可观测性、错误处理、信息流三方面各带来什么好处？
• 子 Agent 能否看到协调者之前的对话历史？这对委派提示的写法意味着什么？
• 为什么"总是走完整流水线"和"训练分类器路由"都不是最佳答案？
• 分解过窄会导致什么问题？如何划分范围才能既扩大覆盖又减少重复？
• 描述一次完整的"评估缺口 → 定向再委派 → 再综合"迭代循环。