多 Agent 系统架构：生产环境的陷阱与现实

dev.to · AI#Agent#架构#生产调试

Editor brief · 编辑速览

深度复盘一个 11 天跑了 $47000 云账单的多 Agent 事故，剖析「基础设施指标正常但应用层出错」的隐蔽故障模式，提供何时用/何时不用多 Agent 的决策框架。

文章思维导图

Knowledge map

拖拽缩放

Full translation

完整中文译文

一个 Agent 陷入无限重试循环，不会体现在你的错误率里。十一天后，它会体现在你的 AWS 账单上。

一个团队运行了一套多 Agent 系统，整整十一天。延迟正常。错误率 0.0%。所有仪表盘都是绿的。云计算账单：$47,000。这些 Agent 其实一直陷在无限重试循环里——因为"错误"不会出现在 Grafana 里。

这个事件代表了一类多 Agent 架构独有的失败模式：按所有基础设施指标，Agent 都在正常运转，但在应用层产生的行为却是错误的、循环的、或冗余的。

大多数团队过早地引入了多 Agent。当以下情况成立时，保留单个 Agent：

多 Agent 在以下场景才值得引入：并行子任务、不同的工具访问需求、或失败隔离需求。

Orchestrator-Worker（约 70% 的生产部署）：中央规划器分解任务、分发给专业 Worker、合成结果。单点故障但可观测性最佳。

Sequential Pipeline：固定的线性链条。确定性、易调试，但延迟会叠加。

Dynamic Handoff（Swarm）：没有中央协调器——Agent 在运行时自行决定谁来处理。灵活但容易陷入无限交接循环。

Hierarchical：Orchestrator 管理子 Orchestrator。用于大规模分解，当单个 Orchestrator 无法持有完整规划状态时。

区分两者的唯一能力：持久化中间结果，使工作流可以暂停、恢复、以及在单个 Agent 失败时重试，而不必从头开始。在每个任务级状态转换处设置检查点，存入持久化存储（Postgres、Temporal）。

MCP 用于 Agent 到工具的通信。A2A 用于 Agent 到 Agent 的通信。除了协议之外：每次交接需要一个带类型的、经过验证的 Pydantic 模型。验证在边界层运行——而不是等到三个 Agent 下游才因坏数据引发难以追踪的错误。

标准指标检测 Agent 是否在运行。多 Agent 系统需要能检测 Agent 是否在取得进展的指标：

$47K 警报：标记 sum(attempt_count) > 2 * len(tasks) 的任何工作流。

这是我对多 Agent 生产架构深度研究的摘要。完整文章包含所有模式的实现示例：

完整文章包含：