第 9 章：多代理协作与研究系统

多代理系统的核心不是“更多模型”，而是“更好的分工”。Anthropic 的研究系统采用主代理 + 子代理结构：主代理负责理解问题、拆解任务、整合结果，子代理并行检索与分析，再把压缩后的信息返还。这样做的直接好处是并行探索与上下文隔离，主代理不必承载所有细节。[64]

工程文章把这种结构与研究任务的特性联系起来：研究问题往往路径不确定、需要在多个方向同时探索，单一代理容易陷入线性搜索。子代理的并行探索像“多条独立线索”，最终由主代理合并成可执行答案。[64]

多代理带来的提升并非免费。文章指出，多代理系统在 token 消耗上明显更高，工具调用次数也更多。它适合价值足够高、复杂度足够大的任务，而不是每个问题都值得启用的默认模式。[64]

让多代理有效的关键在于“如何分配任务”。工程实践里，主代理需要给子代理明确目标、预期输出格式与工具范围；任务复杂度需要对应合理的并行规模；搜索策略往往先宽后窄，避免子代理在一开始就陷入过窄方向。[64]

多代理的评估方式也不同于单代理。路径可能不同，但只要结果与过程合理，就应被视为成功。因此工程团队更关注“最终状态是否正确”而不是“路径是否一致”，并结合自动评估与人工回看发现系统性偏差。[64]

从 SDK 视角看，多代理的实现形式是 subagents：主代理启动子代理，并从子代理的结果里抽取真正需要的信息，避免上下文被细节淹没。这个机制本质上是把上下文管理和任务管理合并到一起，提升探索能力又不破坏主上下文的稳定性。[25][64]

多代理系统体现了官方研究里“先用简单模式、再逐步扩展”的态度：当单代理足够时就不要拆分；当任务复杂到单代理无法保持清晰路径时，多代理才是合理选择。[42][64]