多智能体对话框架：从流水线到会话智能体的范式转移

Google DeepMind 在 2025 年末发布的一项研究分析了 5 种架构和 3 个大语言模型（LLM）家族中的 180 种多智能体配置。在讨论部分被掩盖的一个发现是：与单智能体基准相比，非结构化多智能体网络将错误放大了高达 17.2 倍。不是修复错误——而是放大错误。智能体们自信地在彼此的幻觉基础上进行构建，创造出回声壁效应，使每个独立模型的失败模式显著恶化。

这是多智能体对话框架核心的悖论。赋予它们强大力量的特性——智能体进行协商、批判、委派和修订——如果缺乏周密设计，也正是让它们变得危险的原因。理解基于对话的编排（orchestration）与传统流水线链式调用（pipeline chaining）之间的区别，是正确使用这两者的第一步。

流水线 vs. 对话：真正的架构差异

LLM 编排的主流心理模型仍然是流水线：输入流向 A 阶段，输出喂给 B 阶段，结果从 C 阶段产出。LangChain 通过其“链”（chain）抽象概念普及了这一模式。它易于理解、易于调试，但对于一大类问题来说，它是完全错误的。

流水线假设解决问题的路径是预先知道的。当你编写流水线时，你正在将解决方案的假设编码到图拓扑（graph topology）本身中。这对于结构化、可预测的任务（如文档摘要、分类、数据提取）效果很好，在这些任务中转换是固定的，唯一的变量是内容。

基于对话的框架基于不同的前提：对于复杂任务，正确的步骤序列本身就必须在执行过程中被发现。你不知道需要三轮改进还是七轮。你不知道初始代码能否顺利运行，还是需要调试循环。交互拓扑不应该是预定义的；它应该从对话中涌现。

架构上的后果是显著的。在对话框架中，每个智能体都是可对话的（conversable，可以启动或响应任何其他智能体）、可定制的（customizable，拥有自己的模型、工具、系统提示词和回复逻辑），并可组合成更高层的协调结构。智能体不只是转换数据——它们在协商结果。

典型的双智能体模式使这一点变得具体：一个负责推理并生成解决方案（通常是代码）的 AssistantAgent，配对一个执行代码并返回结果的 UserProxyAgent。当代码失败时，代理返回错误。助手进行修订。循环继续，直到输出通过验证或触发终止条件。对话就是控制流。不需要编写显式的重试逻辑，也不需要添加错误处理——往复的对话隐含地处理了这一切。

四种对话拓扑结构

并非所有的对话框架都使用相同的通信结构。你选择的拓扑结构决定了你的可靠性上限、成本状况以及可调试性。

**双智能体聊天（Two-agent chat）**是最可靠的模式。一个思考者，一个执行者。交互图是固定的；唯一的不确定性在于轮数。这是对话框架表现最出色的地方——迭代编程、数学推理、数据分析。如果你的任务符合这种形式，请从这里开始。

**群组聊天（Group chat）**是事情变得既有趣又同样危险的地方。多个专门的智能体通过广播频道进行通信。协调器接收所有消息，决定下一个谁发言，并向群组广播。你可以将发言者选择配置为轮询（round-robin，可预测、廉价）、随机（random，不确定性）或基于 LLM（LLM-based，动态、昂贵、强大）。一个研究团队可能包含规划智能体、搜索智能体、代码智能体和批判智能体。规划者进行委派；其他人执行并汇报；批判者在最终确认前进行审查。

动态发言者选择的强大功能伴随着真实的成本：群组聊天中的每一次 auto（自动）选择都会触发额外的 LLM 调用。对于一个包含 20 轮对话的 10 智能体群组，除了任务工作本身，还有 20 次隐藏的编排调用。请务必为此做好预算。

**嵌套对话（Nested conversations）**实现了分层分解。外部智能体发起一个内部的双智能体子对话，等待结果，然后继续。这就是复杂系统解决真正复杂任务的方式：经理智能体将问题分解为子问题，将每个子问题分配给内部的智能体对，并汇总结果。外部对话看到的是整洁的输入和输出；复杂的解题过程发生在内部。

**双循环编排（Dual-loop orchestration）**是最先进的模式，用于生产级多智能体研究系统。编排器维护两个账本：任务账本（Task Ledger，包含事实、假设、战略计划）和进度账本（Progress Ledger，包含接下来谁做什么、系统是否卡住）。外循环处理战略规划；内循环处理执行监控。如果内循环检测到停滞，它会反馈给外循环进行重新规划。在标准的智能体基准测试中，该架构已达到与最先进的单智能体基准相当的性能——考虑到多智能体协调要做到正确是多么困难，这是一个非常有意义的结果。

对话框架在生产环境中的胜出场景

医药行业提供了最清晰的生产验证。基于 Agent 的文档流水线将以往需要专家投入 40–50 人/周的任务压缩到了几分钟内。这些任务——关联临床试验数据、生成文档、运行迭代质量检查——正是那种定义模糊、步骤繁多、需要修改循环的工作，而对话框架在处理这类工作时比流水线（pipelines）具有天然优势。

更广泛地说，对话框架在以下四个场景中胜出：

迭代深度未知的任务：你不知道代码需要多少轮调试，也不知道第一条研究路径是否行得通。在流水线中构建这种不确定性需要显式的重试逻辑和回退分支；而对话框架可以隐式地处理它。

需要异构专业知识的任务：不同的子任务受益于不同的模型。让昂贵的推理模型处理战略规划和编排；将摘要任务交给更便宜的模型；使用专门的模型生成代码。对话框架让在同一个工作流中为不同的 Agent 分配不同的模型变得非常自然。

批判是核心支撑的任务：批判者模式（一个 Agent 生成，另一个 Agent 评审）产生的结果明显优于单 Agent 生成。多 Agent 系统研究的关键见解是：Agent 之间的分歧是一项特性，而不是 Bug。一个带有寻找缺陷显式指令的批判者 Agent，会发现自审生成器所遗漏的缺陷。

快速原型开发工作流：对话式 API 的实验速度确实比基于图形的编排更快。你可以用几十行代码搭建一个功能性的多 Agent 工作流。代价是生产稳定性；收益是验证该方法是否值得进一步构建的速度。

让你付出代价的七种失败模式

17.2 倍的错误放大效应这一发现，是对特定失败模式的警告：Agent 在彼此自信的胡说八道（nonsense）之上构建更多自信的胡说八道。但这并不是对话框架在生产中失败的唯一方式。

缺失终止条件是最常见的失败。Agent 在没有显式停止的情况下无限循环。务必同时设置最大轮数限制 以及 语义终止条件（例如，Agent 输出特定的 Token，如 TASK_COMPLETE）。只依赖其中之一是不够的——你需要两者兼备。

无限语义循环更难检测。对话在轮数上终止了，但 Agent 在最后 30 轮中一直循环相同的想法，没有任何进展。可以通过对最近的消息内容进行哈希处理并检测重复来解决此问题。如果最后三次助手的回复在语义上完全一致，则强制终止并将卡顿情况反馈给用户。

上下文窗口溢出是一个缓慢且耗费资金的问题。群聊历史不断累积。一个消耗了 2000 万 Token 并在第三小时失败的工作流，通过使用内存指针（memory pointers）进行了重构——同样任务仅需 1,234 个 Token。选择性上下文（相关的内存指针，而非全部历史）不是可选的优化，而是任何运行超过几分钟的工作流的生产要求。

不受控的代码执行是一个安全漏洞。对话框架通常包含内置的代码执行功能，这既强大又同样危险。在生产环境中，执行必须在沙盒环境（容器化、网络受限、具有显式工具白名单和执行超时）中进行。默认设置对于本地开发没问题，但对于生产环境是不可接受的。

群聊中的级联故障发生在一个 Agent 的幻觉在群体中未受质疑地传播时。解决方法是结构性的：加入具有挑战假设指令的显式批判者角色，并在结果被接受之前在群聊流程中构建验证步骤。

动态发言者选择成本会隐形成本地累加。为了灵活性而切换到 auto 发言者选择的团队，通常直到第一个计费周期才会意识到编排调用的开销。请将你的编排调用量与任务调用量分开审计。

缺乏可观测性是让所有其他失败模式都更难诊断的失败模式。对话框架不提供内置追踪。你只能通过成本仪表盘了解无限循环，通过用户报告了解级联故障，通过 API 错误了解上下文溢出。从第一次提交代码起就接入 OpenTelemetry。按 Agent 角色进行成本归属分析和按对话步骤进行延迟剖析是最有价值的两个信号。

人机协作（Human-in-the-Loop）：三种模式，一个正确选择

对话框架提供三种人类输入模式：从不（never，全自动）、终止（terminate，仅在触发停止条件时咨询人类）和始终（always，每轮都询问人类）。生产环境的正确默认选择几乎总是 terminate。

always 模式听起来更安全，但会产生摩擦，破坏异步工作流。never 模式虽然高效，但在失败路径上缺乏监管。terminate 模式允许 Agent 团队自主运行，直到到达决策点——需要验证的结果、需要消除的歧义、需要批准的风险——然后在正确的时间提出正确的问题。

应用程序循环模式是惯用的生产架构：Agent 团队运行到终止点，应用程序向用户展示结果，用户提供反馈，团队以该反馈作为上下文重新运行。这自然地映射到异步的、基于会话的部署——例如一个后台作业提取早报摘要供批准，或者一个研究工作流在夜间完成并提交一份综合报告。

终止条件与人类输入模式之间的交互是不直观的，值得专门测试：如果人类输入模式是 always，触发的终止条件不会立即停止对话。在该轮中仍然会询问人类。请在你的操作手册（runbooks）中记录这一点。

选择合适的框架

基于对话的多智能体框架并不适用于所有问题。行业格局已经足够成熟，出现了明显的差异化：

对话框架最适合那些探索性的、迭代深度未知且需要智能体之间进行真实协商的任务。它们最薄弱的一点是持久化状态存储 —— 对话状态存在于内存中，如果进程终止，对话就会丢失。对于需要断点续传的长时运行工作流，你需要一种状态机图（state machine graph）方法，其中检查点（checkpointing）是一等公民的基础设施原语。

基于角色的流水线框架最适合角色定义明确且执行结构可预测的任务 —— 内容流水线、结构化数据提取、报告生成。较低的学习曲线是以牺牲灵活性为代价的。

基于图的状态机最适合需要确定性、可审计执行以及显式分支逻辑的工作流。它们构建起来更难，但在合规敏感的场景中更容易进行推理分析。

实际建议：在原型设计和真正的探索性工作流中使用对话框架。当你确定了结构后，请显式地对其进行编码。无论你选择哪种框架，17.2 倍的这一发现都应该作为一个持久的提醒：更多的智能体并不自动等同于更好的效果 —— 价值来自于结构、批判和明确的角色分工，而不是来自增加智能体数量。

卓越的实践范式

带有专业智能体的双循环架构（dual-loop architecture）是目前处理复杂的开放式任务的金标准。编排器负责战略规划，并维护一份关于已尝试路径和当前计划的持久记录。专业智能体 —— 一个负责网络搜索，一个负责文件操作，一个负责代码执行 —— 在战术层面运行。编排器监控进度，并在战术循环停滞时重新制定计划。

这种架构之所以具有极具竞争力的基准测试表现，正是因为它模仿了专家团队的工作方式：将战略监督与战术执行分离，并在进度停滞时进行显式的重新规划。对话框架使这种分离变得自然。对话本身就是协调机制。

在生产环境中从对话框架中获得最大价值的团队都内化了一个原则：对话即程序。它具有与任何其他程序相同的失败模式 —— 死循环、未处理的异常、资源耗尽 —— 并且需要同样的工程纪律。对话式隐喻是一个用户体验层，而不是跳过工程化实践的理由。