每个人都首先尝试过的模式，但大多数都错了
到 2024 年底，每个企业人工智能架构平台都有相同的幻灯片：顶部有一个主管代理，下面有一些专门的子代理，箭头在各个方向上纵横交错。到 2025 年中期，这些团队正在悄悄地将这些系统重写为具有明确定义的工具目录的单代理管道。并不是因为多代理作为一种架构是错误的，而是因为大多数团队在需要复杂性之前就交付了该模式，并为此付出了未曾预算的延迟、成本、调试时间和操作脆弱性。
到 2026 年，情况已经变得清晰起来。多代理编排对于特定的问题形状来说是一种真正有用的模式。对于大多数企业用例来说，这也是错误的答案，在这些用例中，具有强大评估工具的单个工具良好的代理在每个重要轴上都击败了主管和工作人员设置 - 延迟、成本、可观察性、可调试性和可靠性。决定给定问题属于哪个阵营是大多数团队仍然会犯错误的架构决策。
接下来的框架将介绍单个代理就足够了、多代理带来复杂性的四个问题、三种经过生产验证的拓扑、多代理系统特有的故障模式、成熟部署所需的评估规则、从单代理到多代理的严格升级路径，以及优雅地老化的架构决策与围绕当前时尚僵化的架构决策。
当单个代理就足够时
2026 年企业人工智能部署的默认架构选择应该是单一代理，具有精心策划的工具目录、强大的系统提示、类型化输出合同和维护良好的评估套件。该架构处理大量的实际企业工作——客户支持、销售协助、内部知识搜索、文档审查、数据提取、结构化输出生成——与多代理同等架构相比，复杂性大大降低，运营成本也更低。
原因是结构性的：现代基础模型擅长工具的使用。一个有能力的模型可以在单个上下文中可靠地编排 10-30 个工具，处理多步骤计划，从工具故障中恢复，并在长时间对话中保持一致的状态。将这些功能分散到多个代理之间的开销（每个代理的提示样板、代理间通信协议、切换时的重复上下文、增加的端到端延迟、成倍增加的 LLM 调用成本）是一笔真正的税收，而且对于大多数工作负载来说，税收超过了架构收益。
成本经济学使情况变得更加尖锐。单代理请求通常会在用户操作后进行 3-10 个 LLM 调用。同一用户操作背后的多代理请求通常会达到 30-80 个。即使每次呼叫质量相同，多代理系统每次请求的成本也要高出 5-10 倍，p95 和 p99 延迟也明显更差。可防御的默认设置是单一代理，直到特定的压力证明分裂是合理的。
当多智能体变得复杂时
在四种问题形式中，多智能体确实是正确的架构，而不是一种流行的架构。共同的特点是，复杂性溢价会以具体的、可衡量的工作负载收益来回报。
- 真正的并行工作。如果一项任务分解为可以同时运行的独立子任务（跨五个不同的知识源进行研究、生成设计的四种变体、根据三个单独的规则集进行验证、同时查询三个数据库），那么并行代理可提供顺序单个代理无法比拟的挂钟加速。延迟优势是架构的合理性。
- 异质的技能概况。当不同的子任务真正受益于不同的模型时——用于路由和意图分类的廉价快速模型、用于复杂推理的前沿模型、用于代码生成的专门代码模型、用于图像理解的专门视觉模型——多代理架构让每个步骤都在正确的成本质量点上运行。成本经济学是架构的合理性。
- 特权能力的隔离。如果一个子任务需要提升权限（写入生产、发送外部电子邮件、转移资金、访问 PII）而其他子任务不需要，则将它们分成具有不同权限范围的不同代理，这不仅是复杂性成本，也是安全和审计的胜利。纵深防御论证是架构上的合理性。
- 组织或跨团队的工作流程。当“代理 A”由一个团队拥有而“代理 B”由另一个团队拥有时，每个团队都有自己的生命周期、评估套件、所有权和发布节奏，协议级分离使它们能够独立发展，而无需协调重写。组织规模的扩展是架构的合理性。
生产中生存的三种拓扑
在我们 2024 年至 2026 年进行的多代理部署中，三种拓扑在与生产的接触中幸存下来。其他拓扑存在于研究论文中，很少能在不存在操作脆弱性的情况下干净地落地到企业环境中。
- 主管/工人。单个协调器代理决定调用哪个专门的工作人员、聚合结果并呈现最终响应。最适合具有可预测路由的异构技能工作负载。 Supervisor 处理跨工作状态；工人是无国籍的专家。操作上最容易维护的多代理模式。
- 管道/交接。代理按顺序传递控制权，每个代理都会转换状态并移交给下一个代理。最适合具有明确阶段（分类→研究→解决→响应→关闭，或提取→验证→丰富→存储）和不需要回溯的稳定阶段定义的工作流程。移交模式是承重契约。
- 并行/选民。多个智能体独立处理同一任务；法官或选民选出获胜者。最适合方法多样性提高稳健性的高风险决策 - 具有多个分析角度的法律审查、具有不同分类器的对抗性分类、具有不同规则的安全评估。成本高；为错误成本明显高于运行多个代理的成本的决策保留。
设计时要针对的失效模式
多代理系统会出现单代理系统不会出现的故障。五种重复出现的故障模式非常常见，因此从第一天起就针对它们进行设计可以节省大部分操作难题：
- 上下文蔓延。每个代理都需要相关的上下文，并且切换要么复制它（令牌和延迟昂贵），要么压缩它（有损和有偏差）。预先设计移交模式，将其视为版本化合约，使用对抗性有效负载进行测试，并测量每个代理的上下文利用率，以便架构团队可以看到上下文在哪里被浪费。
- 级联错误。早期智能体的小错误会成为后来智能体自信的前提，并且错误会在整个管道中复合。建立每步信心评分、主管级别的“我是否仍在正轨上”检查，以及当下游信心崩溃时回滚到较早状态的选项。
- 环路检测。两个代理互相服从，一个主管重新分配相同的任务，或者一个计划代理重新访问相同的选项，这些都会快速消耗代币并且不会产生任何结果。硬步数上限、对连续工具调用的多样性检查以及显式循环检测启发法是基线而不是可选的。
- 成本不透明。多代理请求可以在单个用户操作后进行 30-80 个 LLM 调用。每个请求的成本跟踪，以及所有代理的令牌计数汇总，从第一天开始就属于可观察性的，而不是在账单到达后才添加。每任务成本分布（不是平均）是正确的运营指标。
- 权限泄露。多代理系统通过代理边界处理敏感数据和提升的权限。当权限模型是隐式的（“工作人员只做主管委托的事情”）时，系统只需一次快速注入就可以避免特权升级。显式的每个代理权限范围和审核日志记录是结构性修复。
评估更加困难且强制性
单代理系统需要评估一件事：最终响应。多智能体系统有很多需要评估的东西：规划分解、路由决策、每个工作人员的输出、聚合、最终响应以及轨迹本身。将多智能体评估视为“与单智能体评估相同”的团队会导致系统脆弱，然后在回归发生时无法对其进行诊断。
多代理部署的实用评估框架：
- 最终输出评估。关于用户可见质量的标题指标。
- 规划质量评估。协调者是否为这项任务选择了合理的分解？它是否路由到了正确的专家？它是否避免了不必要的步骤？
- 每个工人的评估。每个工人都根据自己的回归集，按照其专业范围内的标准进行独立评估。
- 轨迹指标。采取的步骤、使用的工具、尝试的重试、实现的并行性（对于并行拓扑）、终止正确性。
- 成本和延迟分布。每个任务的成本差异是代理行为不健康的最廉价的信号； p95 和 p99 延迟揭示了在多代理工作流程中主导用户体验的尾部。
- 跨代理一致性。主管对任务状态的理解是否与工人的一致？当代理意见不一致时，该架构就会出现单输出评估无法检测到的协调问题。
从单一到多重的严格升级路径
一个有用的架构规则：从单一开始，测量架构上的压力，然后拆分。如果单代理实现遇到了真正的障碍——可以并行的调用的顺序延迟、真正需要权限隔离的功能、一半步骤可以在更便宜的模型上运行的工作负载——这些都是证明拆分为多代理的压力。如果推动多代理的原因是“感觉更复杂”或“竞争对手正在这样做”，那么升级几乎总是为时过早。
经久耐用的建筑是可以倒塌的。将每个代理的工具目录编写为连贯的功能模块，编排层可以将其用作单代理工具集或不同的专用代理。这种单一的架构规则——工具作为耐用资产，代理拓扑作为可替换的脚手架——是跨两到三个模型代优雅发展的架构与围绕当前时尚僵化并在时尚转变时迁移成本变得昂贵的架构之间的区别。
架构平台忽略的操作注意事项
将生产就绪的多代理部署与研究原型区分开来的六个操作维度，大多数架构甲板都没有讨论：
- 每个代理步骤的可观察性。每个代理操作都会生成一个可跟踪事件，其中包含输入上下文、工具调用、输出和推理。当发生复杂的生产故障时，跟踪使得系统可以调试。
- 状态管理。代理间状态所在的位置（在共享存储中、在移交消息中、在主管上下文中）是影响所有其他操作属性的架构决策。使其明确。
- 根据请求进行成本预算。每个用户操作的硬成本上限可防止失控循环产生意外账单。上限应该失败关闭（终止请求），而不是默默地截断输出。
- 重试并优雅降级。当工人失败时，会发生什么？使用不同的模型重试？回到确定性路径？向用户展示故障？每个选项都是可行的工程选择；不决定则不然。
- 受监管工作流程的审计跟踪。对于涉及监管数据的部署，每个代理的操作日志是监管证据。架构和保留策略属于架构，而不是事后的想法。
- 模型交换规则。代理拓扑应在任何单个代理中的模型升级后仍然存在。如果更换主管或任何单个工作人员需要重新设计拓扑，则该架构与当前模型生成的耦合过于紧密。
常见问题
AI 架构师在确定多代理部署范围时提出的常见问题：
- 我如何知道我的用例是否适合使用多代理？询问四种压力（并行工作、异构技能配置、特权隔离、组织分离）是否适用。如果两个或多个应用程序，多代理可能值得复杂性。如果都不适用，那么具有良好工具的单一代理是正确的默认设置。
- 我应该默认使用哪种拓扑？大多数企业异构技能工作负载的主管/工作人员。稳定阶段工作流程的管道/移交，其中阶段不需要相互重新访问。在多样性很重要的情况下，平行/投票者做出真正高风险的决策。
- 多代理系统的成本如何？每个请求成本 = 每个用户操作的所有代理的 LLM 调用总和，加上工具调用成本（检索、API 调用、代码执行）。多代理请求的成本通常是单代理请求的 5-10 倍，而且成本集中在长轨迹的尾部。每个请求的成本上限是运营基线。
- 如何处理代理间通信？键入消息模式。每次移交的 JSON 模式或等效合同，在源代码控制中进行版本控制，在每次传输时进行验证。自由形式的自然语言切换是生产中大多数多智能体可靠性问题的根源。
- 在生产中从单代理转向多代理的典型时间表是怎样的？如果现有系统设备完善且多代理压力明确，则需要 4-8 周；如果现有系统没有评估套件或可观察性，则需要 3-6 个月。评估和可观测性工作是速率限制因素，而不是模型工程。
