Marico's space
最近折腾多智能体系统，踩了几个坑，这篇把问题说清楚。
从单智能体LLM（大语言模型）方案切换到多智能体系统（Multi-Agent Systems，MAS），这事大多数时候是被逼出来的，不是你主动选择的。企业需求一膨胀，做过单智能体的都知道那套"瑞士军刀"式架构有多难受——工具调疲劳、幻觉率飙升、长流程状态根本管不住。
但话说回来，上多智能体架构也不是银弹。它引入的是一整套分布式系统的新问题：编排怎么搞、状态怎么存、"天下没有免费午餐"的Token开销怎么扛。对于Senior工程师和AI架构师来说，选哪种编排模式，直接决定了你做出来的是高性能系统还是延迟爆炸、成本失控的坑货。
Handoff模式的核心是去中心化编排。每个智能体都被当成一个独立的微服务，有自己的领域逻辑。当某个智能体收到的请求超出它的"边界上下文"时，它会用HandoffTool显式地把会话转交给对等节点。
Handoff的逻辑
这不是简单的重定向。标准化的Handoff需要同时传递当前会话状态和意图上下文。转交的智能体不是甩锅了事，它要给下一个智能体提供一份"工作总结"，避免重复推理。
概念伪代码
这个模式为什么有效：它降低了单个LLM的"工具噪音"。把智能体限制在5到10个专属领域的工具内，模型选择工具的准确率会显著提升。这套玩法跟微服务架构一个道理，各个智能体独立演进、独立扩容，互不干扰。
Coordinator模式（也叫"大脑"或"管理器"模式）用一个专门的高推理能力智能体来维护全局状态和执行图。这个智能体本身不干具体活，它负责把高层目标拆成子任务，然后分派给"工人"智能体去执行。
执行图
在这个模式下，Coordinator维护一张依赖关系结构图。它知道Agent B必须等Agent A返回特定数据格式之后才能启动。
全局状态管理：Coordinator是会话进度的唯一真相来源。
冲突解决：如果两个工人智能体给出了冲突的数据，Coordinator负责协调输出。
动态规划：如果某个工人挂了，Coordinator可以实时重新路由或调整执行计划。
虽然控制力更强，但这套方案有两个致命问题：一个巨大的中心化单点故障风险，以及每次交互都要经过"大脑"带来的严重延迟。
工程学就是trade-offs的学问，多智能体系统也不例外。从单智能体迁移到编排系统，性能税是实打实的。
1. Token用量（10倍到15倍增长）
单智能体方案里，上下文窗口只包含用户查询加一点历史记录。多智能体环境下，每次Handoff或者Coordinator调用子智能体，都需要重新注入上下文。标准化的Handoff往往要传递完整对话历史加上前面智能体的思考过程。跟单体架构比，Token消耗直接跳10到15倍。
2. 延迟与TTFT（首Token响应时间）
顺序推理是性能杀手。如果一个Coordinator需要：
推理制定计划（第一轮）
调用Agent A（第二轮）
处理Agent A的结果（第三轮）
调用Agent B（第四轮）
用户就得等着做多次往返。首Token响应时间（TTFT）跟链路中的智能体"跳数"呈线性增长。
要构建不会把自己压垮的生产级系统，遵循这三条架构原则：
1. 并行"扇出"执行
只要可能就打散顺序链路。如果Coordinator识别出三个相互独立的子任务（比如查天气、查航班、查日历），同时分发出去。最后用"聚合"轮次合并结果。这套玩法跟MapReduce模式异曲同工，是把延迟控制在可接受范围内的唯一出路。
2. 极端工具专业化
智能体失败最常见的原因是工具疲劳。LLM选择正确工具的准确率在工具集超过15个之后会断崖式下跌。
神奇数字：子智能体最多控制在5到10个工具。
如果某个智能体需要更多工具，这就是信号——它应该被拆成两个独立实体，用Handoff模式连接。
3. 状态外置化存储
别依赖LLM的上下文窗口来持久化全局状态。用Redis或阿里云表格存储这样的高性能外部数据库。
为什么？如果某次智能体调用失败或者连接断开了，你可以从最后一次成功的Handoff点恢复编排。
上下文压缩：Handoff之前，用一个更小更快的模型（比如GPT-4o-mini或者通义千问-7B）把对话历史压缩成"状态包"，降低主智能体的Token负载。
AI工程的未来正在从"提示词工程"转向"系统编排"。我们正在从把LLM当创意写作工具，慢慢转变成把它们当作大型分布式系统里的非确定性计算内核。
不管你选Handoff模式追求解耦的灵活性，还是选Coordinator模式追求中心化的精确性，目标都一样：管理好准确率、延迟和成本之间的内在取舍。把工具做专、把执行并行化、把状态外置，你就能构建出不是花拳绣腿的演示、而是真正可靠可扩展的后端基础设施。