
专栏《人工智能Agent从部署到生产》第19篇:#17 教你榨干 GPU 吞吐,#18 教你用 FP8 砍掉一半显存——硬件到天花板了,下一步呢?答案是:拆成多个 Agent 协同干活。本文从 NATS 消息总线出发,覆盖五大 Agent 编排模式、三种通信协议(MCP/A2A/NATS)的选型矩阵,以及一个 200 行 Python 代码从头搭建的多 Agent 系统的完整实操。TL;DR单 Agent 的天花板在 2026 年已经被反复验证:上下文窗口饱和、工具选择准确率随数量下降、单点故障无隔离。多 Agent 不是"多个模型堆叠",而是通信带宽、拓扑选择和协议选型三者共同决定的问题。本文覆盖:五大编排模式:Supervisor(2026 生产默认)、Fan-Out(并行分发)、Pipeline(串行管道)、Debate(多视角辩论,~2.5× 成本)、Event-Driven(事件驱动)。每种模式的故障面完全不同——Fan-Out 是部分失败聚合问题,Pipeline 是级联污染问题,Debate 是裁决模型偏见问题。消息基建对比:NATS(微秒级延迟、内置 JetStream 持久化) vs Kafka(高吞吐、严格顺序) vs RabbitMQ(AMQP 生态成熟)。在三 Agent 协作场景下,NATS 的P99 延迟是 Kafka 的 1/4、RabbitMQ 的 1/8。通信协议选型