多Agent系统一旦进生产，问题往往不是“某个Agent不够聪明”，而是它们在同一条链路里互相拖住。
原稿里提到的618大促故障，就是典型场景：库存查询Agent认为库存充足，优惠券核销Agent已经扣减券码，结算网关却收到了互相矛盾的指令。后面触发的不是一次普通失败，而是无限重试循环，最后把交易链路拖垮。
这个例子里，Qwen-Max、GLM-4-Plus的响应速度并不是关键。真正卡住系统的是状态不一致、重试没有边界、缺少全局协调。
知乎一份题为《188页PPT！2026年智能体协作架构框架与多...》的材料也提到，多智能体系统不是简单堆Agent数量，而是涉及架构设计、通信协议、任务分配、冲突协调和资源调度的系统工程。落到生产部署，就是一句话：先别让它们互相踩脚。
崩盘通常从三个小口子开始
第一个口子是默认网络可靠。
LLM API、工具调用、数据库、搜索接口，任何一个环节都可能超时。单Agent失败，大不了重跑；多Agent并发时，一个节点卡住，其他节点可能拿着旧状态继续往下走。
第二个口子是每个Agent只看自己的上下文。
库存Agent只知道库存，优惠券Agent只知道券码，客服Agent只知道用户诉求。它们单独看都没错，组合到结算链路里却可能冲突。多Agent里的“幻觉”不一定来自模型胡说，也可能来自上下文分裂。
第三个口子是重试太粗。
失败就立刻重试，看起来积极，实际可能制造重试风暴。库存服务已经慢了，多个Agent还同时补请求，系统只会更慢。容错不是“多试几次”，而是知道什么时候该停、什么时候该降级、什么时候该把状态锁住。
2026智源大会在“终端智能体与OpenClaw”论坛中讨论过一个方向：通过Harness连接模型、工具、环境、记忆、符号结构、安全沙箱和端云系统，让Agent从回答者变成执行系统。执行系统要可靠，容错层就不能靠临时补丁。
LangGraph适合把状态摊开管理
LangGraph的思路更接近显式状态机。Agent是节点，消息和状态沿着图流转。它的好处是：哪一步在改状态，哪一步可能失败，失败后回到哪里，都比较容易看清。
在原稿的618故障复盘里，LangGraph可以借助checkpointers保存中间状态。库存查询Agent失败时，不必整条链路从头再跑，而是回到上一个一致状态点。
下面这段更适合作为配置思路看，而不是直接复制进生产：
from langgraph.prebuilt import create_react_agent
from langchain_core.rate_limiters import InMemoryRateLimiter
agent = create_react_agent(
model,
tools,
checkpointer=InMemorySaver(), # 状态持久化和回滚
retry_on_timeout=True,
max_retries=3,
timeout_seconds=10
)
这里真正重要的不是某个参数名，而是三件事：
- 每个节点要有超时边界；
- 重试次数要有上限，比如原稿里的
max_retries=3； - 中间状态要能保存，失败后能回滚到一致点。
如果没有状态检查点，多Agent协作会退化成一串黑盒调用。它们看起来在协作，实际上没人知道全局状态已经走到哪一步。
AutoGen灵活，但状态要自己兜住
AutoGen更像多Agent对话框架，优势是灵活。多个Agent可以围绕任务讨论、分工、补充信息，搭原型很快。
问题也在这里：对话越自由，状态越容易散。
原稿里的购物车数据竞争，就是这一类风险。多个Agent同时修改同一份数据，如果没有统一状态存储，也没有版本比较，很容易出现“每个Agent都觉得自己是对的”的局面。
在AutoGen里，断路器通常需要接外部库。原稿给了PyBreaker示例：
import pybreaker
breaker = pybreaker.CircuitBreaker(fail_max=3, reset_timeout=60)
@breaker.callable
def call_inventory_service(product_id):
# 调用库存API的逻辑
pass
try:
result = call_inventory_service("PROD_123")
except pybreaker.CircuitBreakerError:
print("服务暂时不可用，请手动处理")
这段代码的核心是“快速失败”。当库存服务连续失败3次，后续请求不再继续打过去，而是直接进入降级或人工处理。比起让所有Agent一起重试，快速失败更像刹车。
AutoGen不是不能上生产，而是不能只靠对话历史当状态。生产环境里，购物车、订单、库存、券码这类关键数据，必须落到中央状态服务或业务数据库里，由业务层处理并发写入。
状态同步别交给Agent自由发挥
多Agent共享状态时，最危险的是“脑裂”：每个Agent手里都有一份看似合理的状态，但版本不同。
LangGraph在同一个StateGraph实例内更容易做状态互斥；跨进程、跨机器之后，还是要外接Redis、etcd这类状态服务。原稿提到的Context包装外部状态，也只能解决“拿状态”的问题，写入冲突仍要业务层处理，比如加乐观锁。
AutoGen的问题更典型：Agent从不同上下文恢复时，可能拿到不同快照。原稿中的三个扣库存Agent各自缓存库存快照，却没有比较版本，最后就会把冲突传给结算链路。
更稳的做法是：
- Agent启动时，从中央状态服务同步全量快照；
- 每次写入带版本号或锁；
- 状态更新后，通过Webhook通知关联Agent刷新；
- 关键链路只允许一个最终写入者，其他Agent提供建议或校验。
这听起来不像“智能体创新”，更像老派分布式系统工程。但多Agent上生产，绕不开这一层。
先定停机规则，再谈进化
2026智源大会的“AI自进化”论坛讨论过Agent如何从交互、失败、探索和反馈中形成记忆、规则、世界模型与学习能力。这个方向很重要，但生产系统的第一道门槛仍然是：失败时不要扩大故障。
ICAIBD 2026也把Agentic AI and Agent Collaboration列为Track 3，说明Agent协作已经是一个单独议题。协作越复杂，越不能只看单个Agent的能力。
多Agent容错可以先从几个低成本动作开始：给每个工具调用设超时；给重试加上限；给关键状态加版本；给外部依赖加断路器；给跨Agent写入设唯一入口。
这些配置不漂亮，但管用。
真正的生产部署，通常不是让Agent多做一步，而是让它在该停的时候停下来。
