Demo 里你看的是：Planner 拆任务，Coder 写代码，Reviewer 提意见，Tester 跑用例，一气呵成，像一支微型研发团队。但真把这东西放到生产里跑两周，你会发现——两个 Agent 一起干活，不一定效率翻倍，更可能故障翻倍。这不是危言耸听，是 2025–2026 年这一波 Multi-Agent 框架（CrewAI、AutoGen/AG2、LangGraph）在生产里反复撞墙后，大家逐渐达成的共识。
一、先讲三个真实"捣乱"现场
现场 1：CrewAI 的代码审查流水线，三个 Agent 各干各的
一个审代码质量、一个扫安全漏洞、一个写测试。理论上流水线协作，结果：审代码的 Agent 改了一段逻辑，安全扫描的 Agent 根本不知道代码变了，拿着旧版本扫出一堆"不存在的漏洞"；写测试的 Agent 更绝，测的是原始版本的接口。三个 Agent 之间没有"有人审核、有人拍板"的制度，就像一个公司没 QA，工程师写完直接上线——出事只是时间问题。
现场 2：共享状态静默覆写
Network-AI 作者复现过一个经典时序 bug：
0ms：Agent A 读共享上下文（version: 1）
5ms：Agent B 读共享上下文（version: 1）
10ms：Agent A 写新上下文（version: 2）
15ms：Agent B 基于 v1 写回 → Agent A 的工作被静默覆盖
不报错、不告警，最后交付的东西就是错的。这个问题在 LangChain + CrewAI + AutoGen 混用的时候尤其容易出现，因为每个框架对自己的 state 管得还行，跨框架共享 state 就 silently break。
现场 3：AutoGen GroupChat 吵到天荒地老
两个 Agent 对一个结论有分歧，第三个进来和稀泥，然后 group chat 循环往复，直到你设的 max_rounds截断，吐一个半成品答案给你。non-terminating conversation 是 AutoGen 生产环境最高频的 failure mode，修法是加 aggressive termination condition——说白了就是"家长介入"。
二、两个 Agent 一起干，会出哪几类乱子
把上面这些和业界总结的其他案例归个类：
| 类型 | 表现 | 例子 |
|---|---|---|
| 指令竞态 | 大脑并发下发互斥操作，无资源仲裁 | 一个 Agent 删 /tmp/fileA，另一个同时读它 |
| 状态幻觉 | Agent B 改完状态没同步，大脑/其他 Agent 仍基于旧快照决策 | 上传 S3 完成了，大脑又触发一次上传 |
| 自治越界 | Agent 内置重试/降级逻辑，绕过全局策略 | 超时后重试 Agent 擅自把 POST 订单降级成异步队列，绕开 SLA 兜底 |
| 无限辩论 | 对话型框架里 Agent 互不相让，循环到 max_rounds | AutoGen GroupChat 经典病 |
| 上下文溢出 + 推断漂移 | Manager Agent 压缩子 Agent 输出时失真，把 DELETE 参数推断错 | CrewAI hierarchical 模式踩坑 |
| 目标冲突 | 各 Agent KPI 不一致，决策互斥 | 产品 Agent 要 3 个弹窗拉新，研发 Agent 要 ≤1 个保加载速度 |
💡 注意一个共性：这些问题单 Agent 架构反而不容易出。单 Agent 是你跟一个"人"对话，所有状态在自己上下文里，不用协调。多 Agent 的复杂度不是线性增长，是协作税（coordination tax） ——CrewAI 相对单 Agent 有 3~5× 的 Token 膨胀，这就是税的体现。
三、根因：LLM 天生不是"多体选手"
往下一层挖，为什么两个 Agent 就容易乱：
- LLM 无原生状态管理——输出是文本流，维护不了
task_id → status映射，也谈不上事务上下文。 - Agent 的状态默认本地缓存，不参与分布式共识，跨 Agent 共享就靠"甩 JSON"，甩丢了、甩旧了都没人知道。
- 框架层缺执行治理。CrewAI 和 AutoGen 都不自带 execution governance——AutoGen 里一个 Agent 说服另一个执行破坏性 API，就真执行了；CrewAI 的 Manager 上下文溢出了，推断错 DELETE 参数也照样发。
- 多 Agent amplification：从 1 个 Agent 扩到 10 个，攻击面和"推断出错导致误操作"的概率不是 ×10，是放大得更狠，因为错误会传播。
四、现在业界怎么治：从通信到仲裁到协调层
1. 通信范式先选对
- Blackboard（黑板） ：共享 workspace，各 Agent 读写同一块，适合任务耦合紧的场景，但要配 ownership + 版本追踪
- Message Passing：Agent 之间发消息，解耦好，AGV 集群、事件驱动常用
- Shared Memory：偏底层，适合同进程内多 Agent
腾讯云那篇给的选型逻辑比较清楚：Pipeline 式串行用 Blackboard 或 Shared Memory 就够了；需要 Agent 之间来回商量的，得上 Message Passing + 仲裁。
2. 冲突消解的几种"仲裁官"
- Supervisor / Manager 模式（LangGraph 主推）：一个监督 Agent 管任务分配 + 冲突检测 + 三阶段仲裁（检测 → 影响评估 → 调解）
- 投票：多个 Agent 对结论投票，多数胜，可加权（证据质量高的权重高）
- 优先级：预设优先级链，比如"用户指令 > 定时任务 > 后台维护"
- 协商/调解：Agent 之间多轮 propose-counterpropose，适合目标冲突型场景
3. 共享状态要上"协调层"，不能裸写
Network-AI 那个思路值得记一下：所有跨 Agent 的 state mutation 走 propose → validate → commit原子 cycle，而不是直接 sharedState.set()。这层坐你现有框架（LangChain/CrewAI/AutoGen 都行）和共享状态之间，14 个框架都能接，还顺手把 token budget、permission gating、audit trail 做了。
4. 工程侧的小技巧（单点也好用）
- 时间窗隔离：定时任务错峰，别同时踩共享文件
- 资源锁 + 原子写入：写共享文件前检查锁，临时文件 → rename，避免 partial write
- Tool schema 用 Pydantic 校验：CrewAI 和 AutoGen 在 schema 松的时候都会乱调 tool，Validate every tool I/O 是硬性纪律
- max_iter / max_rpm 必设：不然预算会被两个 Agent 吵到天亮烧光
- 可观测性外挂：Langfuse / Helicone / Arize 从 day one 就接，没 trace 调试多 Agent 是折磨
5. 框架选型本身的"防捣乱"考量
- CrewAI：角色 + 任务 + 流程，确定性高，企业友好，但 hierarchical 模式上下文溢出要警惕，task description 必须 tight + 写明
expected_output - AutoGen/AG2：conversation 范式，灵活，适合"结论要从讨论里冒出来"的场景，但必须 aggressive termination，否则 loop
- LangGraph：state machine + retry + human-in-the-loop，生产完成率 62% 是目前三者里最高的
- 通用铁律：Agent 集群和生产 API 之间必须有一层 deterministic proxy / control plane，不能让 Agent 直接怼数据库。Exogram 那篇文章的原话："Agents orchestrate intent. Infrastructure governs execution."
五、所以两个 Agent 一起干活会不会互相捣乱？
会，而且比你想的容易。 但只要做对几件事，能压住：
- 通信范式选对（流水线用 Blackboard / Pipeline，商量型用 Message Passing + Supervisor）
- 共享状态别裸写，上 propose-validate-commit 或 Coordination Layer
- Tool I/O 用 Pydantic 卡死，max_iter / max_rpm 必设
- 对话型框架加 aggressive termination，层级型框架盯住 Manager 上下文长度
- 外挂可观测 + 外挂 execution proxy，别让 Agent 直接碰生产资源
⚠️ 一个常被忽略的判断：你这个场景到底需不需要多 Agent？单 Agent + 好工具链 + 长上下文，很多事能搞定。一旦拆成多 Agent，协作税就开始收了——Token、延迟、debug 成本、冲突概率，每样都涨。拆的理由应该是"专业化分工收益 > 协作税"，而不是"听起来酷"。
