AI Agent 开发实战：多智能体协同的 5 个关键工程决策
某金融科技团队的 5 智能体风控系统上线首周出了两次生产事故。本文基于 2025-2026 年真实交付经验，拆解多智能体协同的 5 个关键工程决策：通信协议选型、记忆系统设计、人机回路粒度、任务编排与监控回滚。
中国企业级 AI 智能体市场 2026 年预计达到 449 亿元规模（央视财经数据），但大量团队正卡在从"单点试点"到"多体生产级协同"的这道坎上。本文拆解这一年我们在交付过程中反复遇到的 5 个工程决策点，每个都附具体的踩坑记录和技术取舍理由。
一、通信协议选型：MCP vs A2A vs 自建消息总线
这是多智能体架构的第一个分岔口。2026 年场上主要有三套方案：
| 方案 | 定位 | 成熟度（2026） | 适用场景 |
|---|---|---|---|
| MCP（Anthropic） | 模型↔工具标准化调用 | 高，9700 万次安装 | 需要统一访问数据库、API、文件系统时 |
| A2A（Google） | 智能体间协作通信 | 中，2025 年 4 月发布 | 多节点任务委托与结果汇总 |
| 自建消息总线 | 完全自定义的节点间通信 | 取决于团队 | 对延迟/安全有极端要求的场景 |
需要先澄清一个普遍误解：MCP 和 A2A 不在同一层竞争。MCP 解决的是"模型怎么调用工具"——相当于 AI 世界的 USB-C 接口（至顶网，2026）。A2A 解决的是"智能体之间怎么协作"——每个节点发布自己的数字名片声明能力、端点、版本，其他节点通过注册中心发现并委托任务（Google Cloud Next '25）。
我们在一家零售供应链客户的交付中对比过：一开始用纯 MCP + 自定义 JSON 格式做节点间通信，两个模块还勉强能跑，加到 5 个后消息路由逻辑膨胀到 800 行，任何一个模块的能力变更都要改路由表。后来引入 A2A 的发现机制，路由代码缩减到 120 行。但 A2A 目前对长任务（执行超过 30 分钟）的断点续传支持仍不完善——这个场景下我们临时回退到自建 Kafka 做补偿。
决策建议：3 个以内节点、任务链路相对固定的场景，MCP + 轻量消息队列够用。超过 3 个节点且需要动态发现和任务委托的，A2A 是更可维护的选择。延迟敏感（<50ms）或需要事务性保证的场景，自建方案无法绕过。
二、记忆系统设计：短期上下文 vs 长期向量库的工程取舍
多智能体系统的记忆问题比单点复杂一个数量级。单一模块只需记住"聊到哪了"，多模块还要记住"上游上次给的结果是什么""第 3 步失败后回滚了哪些状态"。
我们在一个 12 周的智能客服项目中实测了三套方案：
| 方案 | 上下文窗口占用 | 跨节点检索延迟 | 12 周任务成功率 |
|---|---|---|---|
| 纯短期（128K token 全量塞入） | 高，3 轮对话后即超限 | 0ms（内存读取） | 62% |
| 纯长期向量库（Milvus，top-5 检索） | 低，仅注入检索结果 | ~180ms | 71% |
| 混合方案（32K 滑动窗口 + 向量库补充） | 中 | ~45ms | 89% |
纯短期方案的问题不是容量——128K 足够放下几十轮对话——而是模型在长上下文中对关键信息的注意力衰减。我们观察到：当上下文超过 60K token 时，系统开始"忘记"其他模块在 10 轮之前传递的关键参数。纯向量方案解决了遗忘，但检索延迟在实时决策场景里不可接受。混合方案用滑动窗口保证近期的快速访问，用向量检索补充远期记忆，12 周成功率从 62% 提升到 89%。
决策建议：不要试图用一个方案覆盖所有记忆需求。短期窗口设为 32K 足够覆盖 1-2 轮完整的多节点交互链路。长期记忆用向量库做语义检索，但务必对检索结果做去重和时效性打分——我们遇到过向量库把 3 周前的过期状态当成"最佳匹配"返回的情况。
三、人机回路粒度：什么必须人批，什么可以自主
这是最容易被技术团队低估的非技术决策。多节点系统中，一个模块的自主决策会触发下游的连锁动作——一个错误判断会被逐级放大。
我们总结了一套四级标准：
- L0 — 完全自主：只读查询、数据格式转换、日志分析。事后审计即可。适合日均 1000+ 次的低风险操作。
- L1 — 软确认：内容推送内部频道、触发非关键通知。系统执行后发送摘要到 Slack/钉钉，24 小时内无人反对则自动生效。
- L2 — 硬确认：修改数据库记录、调用付费 API、发送客户邮件。必须有明确的人工审批（点击"确认"或 API 回调），超时自动拒绝而非自动通过。
- L3 — 禁止自主：涉及资金划转、合同签署、生产环境部署。只出建议方案，不执行任何写操作。
一个反例：某客户一开始把"自动回复客户工单"设为 L0。上线第二周，一个模块误解了客户的技术问题，连续发送了 3 封错误方向的回复——客户直接打了投诉电话。事后我们把客户沟通类操作全部升级到 L2，并加了一条规则：如果两个节点对同一问题的判断置信度差值超过 30%，自动升级为人工处理。
决策建议：不要按操作类型一刀切。同一个"发送消息"动作，发给内部测试群的可以 L0，发给外部客户的必须 L2。人机回路的粒度应该按"操作对象 + 影响半径"两个维度交叉评估。
四、任务编排：ReAct vs CodeAct vs 预定义 DAG 的真实对比
多智能体协同绕不开的核心问题是"谁来决定下一步做什么"。如果你还在选框架阶段，可以先看我们之前整理的《AI Agent 开发框架 2026 选型指南》，那里逐一拆解了 11 个主流框架。选定框架之后，2026 年三种主流编排范式的实际表现差异巨大：
| 范式 | 机制 | 灵活性 | 可靠性 | 典型失败模式 |
|---|---|---|---|---|
| ReAct | 思考→行动→观察循环 | 极高 | 中（易循环卡死） | 在"思考-执行-观察"中无限重复，一小时吃掉 200K token 没产出 |
| CodeAct | 直接生成可执行代码 | 高 | 中（代码错误难恢复） | 生成的 Python 脚本引用了不存在的模块，整条链路静默失败 |
| 预定义 DAG | 人工预设任务节点和依赖关系 | 低 | 极高 | 无法处理 DAG 设计时未预见的异常路径 |
我们的实际策略是按业务场景分层混用：核心业务流程（如订单处理、合规审核）用预定义 DAG 保证确定性；探索性任务（如数据异常分析、竞品情报收集）用 ReAct；需要编程能力的任务（如自动修 Bug、生成 SQL）用 CodeAct，但在沙箱中执行并限制单次最大 Token 消耗为 5000。在一个 5 节点的电商运营系统中，这套分层策略让整体任务成功率从纯 ReAct 的 67% 提升到 93%，同时保持了足够的灵活性。
决策建议：不要选边站。确定性高的链路用 DAG 锁死，不确定性高的节点用 ReAct/CodeAct 做局部探索。关键是给每个执行单元设置硬性超时和 Token 预算——我们设置的是单次任务最多 5000 Token、最长 120 秒——超了就降级到人工或 fallback，防止一个模块的循环把整个系统耗死。
五、监控与回滚：怎么定位"谁犯了错"
这是多节点系统在生产环境最大的运维噩梦。单一模块出问题，看日志就行。5 个模块互相调用，一个错误可能在上游做出错误决策 → 中游基于错误输入执行 → 下游拿到中间结果后继续放大——等你发现时，根因已经无法追溯。
我们沉淀了一套"全链路追踪 + 决策快照"方案：
- 分布式 Trace ID：每次用户请求生成一个全局 trace_id，贯穿所有模块的所有调用。用 OpenTelemetry 协议标准化上报，任何一个模块的输入/输出/决策理由都以 trace 为单位关联。
- 决策快照：每个模块在执行关键操作前，保存"决策上下文快照"——包括当时输入参数、检索到的记忆片段、LLM 输出的原始 reasoning。出问题时回放快照就能复现。
- 异常传播边界：强制要求每个模块的输出接口包含
confidence字段（0-1）。下游收到上游输出后，如果 confidence 低于 0.7，必须做二次验证或降级处理，而不是盲信。 - 三级回滚：L1 重试当前模块（同输入、同模型，最多 2 次）；L2 降级执行（跳过该模块，用默认值填充）；L3 全链路人工介入（通知值班工程师，附带完整 trace 链接）。
一个真实案例：某客户的 5 模块风控系统在凌晨 3 点出现误判，节点 C 认为某笔交易是欺诈（confidence=0.45），但节点 D 没有检查该字段直接执行了拦截。第二天客户投诉才被发现。加上门槛检查后，这类误判从月均 7 次降到 0 次——低置信度操作被自动升级为人工复核。
常见问题
问：从单智能体迁移到多智能体，最大的隐性成本是什么？
不是技术成本，是治理成本。单点只需一人确认输出质量，多点需要团队对每个模块的"职责边界"和"失败模式"形成共识。我们见过一个客户 3 个月做完技术迁移，但花了 5 个月才把模块间的交互规则写到运维手册里。建议在架构设计阶段就同步启动治理文档的编写。
问：MCP 和 A2A 必须二选一吗？
不需要。它们是互补关系——MCP 管模型与工具的通信，A2A 管模块间的通信。实际架构中两者共存：模块 A 通过 A2A 把任务委托给模块 B，B 在处理过程中通过 MCP 调用数据库和 API。正确的问法是"我需要哪一层"，而不是"我选哪个"。
问：小团队（5 人以内）值得上多智能体架构吗？
取决于任务复杂度，不取决于团队规模。如果业务只需要单一类型的自动化（如文本分类、邮件自动回复），单点足够。一旦出现"一个任务需要多种专业能力协同"的场景——比如既要分析数据又要写报告又要发通知——多体架构的收益就开始超过维护成本。我们的经验阈值是：当单个模块的 prompt 长度超过 3000 字且仍无法稳定覆盖所有分支场景时，拆分多体的时机就到了。
问：多智能体系统的 Token 成本怎么控制？
三个关键动作：一是给每个模块设置硬性预算（单次任务 3000-5000 Token 为合理区间）；二是让协调节点负责去重——多模块经常对同一段文档做重复分析，协调节点应该缓存并共享结果；三是选择性地使用小模型——不是每个模块都需要 GPT-4 或 Claude Opus，很多路由、格式转换类的用 GPT-4o-mini 或 Claude Haiku 就能胜任，成本可以降到 1/10。
结语
多智能体协同不是把几个单模块拼在一起加个消息队列就能跑通的。通信协议、记忆策略、人机回路、任务编排、监控回滚——这五个决策点，任何一个选错，都会在上线后的第一个月以生产事故的形式给你反馈。这也解释了为什么很多团队的 PoC 跑得很顺利，一到生产环境就崩——PoC 跑通只是完成了 30%，真正的考验在工程化落地上。
蓝曜炬辉在 2025-2026 年交付的多智能体系统中，平均项目周期 8-14 周，覆盖金融风控、零售供应链、智能客服三条业务线。如果你正在规划多智能体架构或遇到从试点到生产的瓶颈，可以联系我们获取完整的架构评审清单，或者查看已交付的多智能体协同案例。