构建多智能体研究系统：来自生产环境的设计模式

当单智能体（single-agent）系统在研究任务中失败时，人们的直觉是增加更多内存、更好的工具或更强大的模型。但在某些点上，问题不在于能力——而在于并发性（concurrency）。深度研究任务需要同时推进多个线程：从不同角度验证论点、跨领域扫描来源、实时交叉引用发现。单智能体按顺序执行这些操作，就像研究人员在做笔记之前先逐本阅读每一本书。回想起来，多智能体（multi-agent）的替代方案似乎显而易见，但在生产环境中正确实现它比架构图所示的要困难得多。

这篇文章讨论了多智能体研究系统是如何实际构建的——行之有效的架构选择、在生产环境中才显现的故障模式，以及在大规模应用中保持其有用性所需的工程纪律。

核心模式：带有并行子智能体的编排器

适用于深度研究任务的架构是一个主编排器（orchestrator），它将任务委托给并行的子智能体（subagents）。当查询到达时，编排器会分析请求，将其分解为独立的子任务，并生成 3–5 个子智能体来并发探索不同方面。随后是一个综合（synthesis）步骤，收集并协调子智能体的输出。一个额外的引用智能体（citation agent）专门负责来源归属，将该关注点与研究逻辑隔离开来。

这种设计在复杂查询上的表现大幅优于单智能体方法——特别是那些受益于广度优先探索的任务。性能提升来自两个方面：并行性（子智能体同时工作而非顺序工作）和专门化（每个子智能体接收一个集中的、有边界的目标，而不是完整的、庞杂的查询）。

编排器的工作不是做研究——而是设计研究策略。当你编写提示词（prompts）时，这种区别至关重要。如果编排器的提示词混入了检索细节，产生的智能体既无法很好地编排，也无法很好地检索。

缺乏纪律会导致什么问题

对于只处理过单智能体循环的工程师来说，多智能体研究系统中的故障模式往往令人惊讶。以下是在生产环境中反复出现的几种模式：

智能体膨胀（Agent sprawl）。 如果没有明确的引导，编排器会为简单的事实查询生成与深度比较分析相同数量的子智能体。生成 50 个智能体来回答一个只需要 1 个智能体的问题不仅昂贵，而且会产生更差的结果，因为综合步骤变成了降噪而非洞察生成。解决方法是在编排器提示词中加入明确的生成指引：事实查询使用单智能体，中等复杂度的任务使用 2–3 个，只有在真正需要并行调查的任务中才使用 10 个以上。

模糊的委托。 “研究主题 X”不是子智能体指令。如果没有清晰、不重叠的目标，子智能体就会重复工作或留下空白。编排器需要为每个子智能体提供特定的范围：寻找什么、返回什么格式、使用什么工具，以及——至关重要的是——其他子智能体已经在处理什么。最后一点可以防止冗余。

搜索策略崩溃。 如果听之任之，智能体会趋向于聚集在主导搜索结果的相同高曝光来源。经过 SEO 优化的内容会挤掉权威的一手资料。从广度开始并逐步缩小范围——而不是立即进入窄范围——会产生更多样化且更可靠的检索结果。

状态性引起的级联错误。 在长时间运行的研究会话中，错误会累积。子智能体误解了早期的中间结果，可能会将整个线程引向错误的方向。实际的缓解措施是设置检查点（checkpointing）：当发生故障时，智能体可以从已知的良好状态恢复，而不是从头开始。这在运维上也很有意义——运行 20–30 分钟的研究任务承受不起冷启动。

同步瓶颈。 等待所有子智能体完成后编排器再继续运行是最简单的协作模型，而且确实有效。但当一个子智能体遇到缓慢的数据源并阻塞其余智能体时，会导致延迟飙升。异步执行模式可以解决这个问题，但也会在部分综合（partial synthesis）和动态委托方面引入自身的协作复杂性。

Token 经济学并非可选项

多智能体系统非常昂贵。一个典型的研究会话所消耗的 token 是普通对话交互的 4 倍，这是一个大致的经验法则；生产数据表明，这个范围很广且呈现偏态分布。三个变量解释了大部分成本差异：token 使用量、工具调用次数和模型选择。这些变量并非独立的——它们相互作用。

实际的方法是分层模型分配。在需要策略推理和综合的编排器上使用能力强大的前沿模型。在执行检索和摘要的子智能体上使用更快、更便宜的模型。如果任务分解清晰，这并不会在质量上妥协——执行有边界检索任务的子智能体不需要与综合输出的编排器相同的推理深度。

缓存对于研究系统非常重要，因为许多子智能体调用共享重叠的上下文：系统提示词（system prompt）、原始查询、中间摘要。在这些内容的静态部分使用提示词缓存（Prompt caching），可以大幅降低重复或类似查询的成本。

多智能体研究系统的经济合理性取决于任务价值，而非架构的优雅。对于找到关键来源能节省大量时间或避免代价高昂错误的查询，token 支出是合理的。对于常规查询则不然。构建这种路由逻辑——决定使用单智能体还是多智能体——本身就是系统设计的一部分，团队往往会跳过这一步，然后疑惑为什么成本无法控制。

评估是真正提升质量的杠杆

由于多智能体系统具有非确定性，评估比单一推理调用更难。同一个查询在不同运行中可能会产生不同的子智能体拆解、工具序列和综合结果。传统的单元测试方法在这里无法很好地泛化。

有效的方法是：从一小组具有代表性的查询集开始，大约 20 个查询，覆盖你的系统实际会遇到的任务复杂度分布。LLM-as-judge 评估——通过单一提示词对事实准确性、引用精确度、完整性、来源质量和工具效率进行 0-1 打分——与人类判断高度相关，并能扩展到迭代所需的规模。

人类评估对于捕捉自动化评分遗漏的失效模式仍然不可替代：例如对易于找到但质量较低来源的选择偏差、领域覆盖中的系统性缺口，以及在评分细则上得分很高但会让用户感到挫败的边缘案例。自动化评估和人工审查是互补的，而非替代关系。

最重要的运营重点是：尽早开始评估。针对早期架构决策运行 20 个查询的评估套件，可以在问题固化到系统之前将其暴露出来。那些等到有了全面的基准测试后再进行评估的团队，往往会因为可预防的回归问题而白白浪费数周时间。

大规模上下文：200 轮对话问题

管理 200 多轮对话的研究型智能体面临着一个结构性问题：上下文窗口无法承载整个会话，而且即使技术上能装下，长上下文中的注意力也会衰减。解决方案需要将记忆视为一个明确的系统关注点，而不是上下文窗口的隐式副作用。

有效的模式是：智能体定期将计划、中间摘要和关键发现存储在外部存储中。当产生子智能体时，它们会从存储记忆的相关子集中初始化一个全新的上下文，而不是使用完整的对话历史。这使每个智能体的上下文窗口保持聚焦，并防止因携带数百轮无关历史而导致的稀释。

智能体之间的交接——即一个智能体的工作成果变成另一个智能体的输入——是信息丢失风险最高的地方。明确的交接协议，包括必须传递的信息、格式以及所标示的确定程度，可以防止智能体在误解前提的情况下依然自信执行的隐性失败。

生产运维：部署与调试

部署多智能体系统需要重新审视几项标准实践。同时切换所有流量的滚动部署会中断正在运行的研究会话——其中一些会话可能已经运行了 20-30 分钟。另一种方法是在版本之间进行渐进式的流量迁移，让旧版本存活足够长的时间，以便在注销之前完成正在运行的会话。

调试非确定性智能体需要链路追踪（tracing），以捕获决策结构而不暴露对话内容。有用的信号是交互图：生成了哪些智能体、顺序如何、使用了什么样的工具调用序列，以及协作在哪里崩溃。标准的应用程序监控工具默认不会显示这些。

生产环境中最关键的监控问题不是“这个请求失败了吗？”，而是“这个智能体是否在做出正确的决策？”。这需要对任务输出进行采样，并根据评分细则进行评估，而不仅仅是跟踪错误率和延迟分位数。

何时不应使用多智能体

多智能体研究系统适用于需要真正的广度优先探索的任务：具有多个独立维度的问题、需要跨来源对主张进行交叉验证的任务，以及受益于并行假设验证的研究。对于单一答案的事实查询、文档摘要或任何答案空间狭窄的任务，单个经过良好提示的智能体会更快、更便宜且更可靠。

将多智能体架构作为默认选择——而不是将其作为解决特定类别问题的工具——往往会产生难以调试、运行成本高昂且比简单替代方案更慢的系统。这需要一种自律：明确这种复杂性是否物有所值。

以下情况证明了这种复杂性是值得的：并行寻找关键信息能显著节省时间的任务、交叉引用可以防止代价昂贵的错误的任务，以及用户真正会利用研究深度而非止步于第一个及格答案的任务。如果你无法清晰说明并行化为何对你的特定用例有帮助，那么你可能并不需要它。