A2A 架构里最容易被忽略的 3 个工程问题
这两年，“A2A（Agent-to-Agent）架构”几乎成了多智能体系统的默认叙事。
你能在无数分享里看到类似的画面：
一个 Manager Agent 接到任务 → 拆解给多个 Worker Agent → Writer 写文档，Researcher 查资料，Reviewer 校对 → 最后自动汇总输出结果
在 Demo 阶段，这套东西看起来优雅、智能、极具未来感。但只要你真的尝试把 A2A 架构推进到POC之后、上线之前，你会很快发现一个残酷事实：A2A 的最大难点，不在“Agent 会不会思考”，而在“系统能不能兜底”。作为一个在分布式系统、工作流引擎、企业集成里踩过无数坑的工程师，我想明确说一句：A2A 本质上不是 AI 问题，而是一个“高度动态、强不确定性”的分布式系统问题。而下面这3 个工程问题，几乎是所有 A2A 项目里最容易被忽略、但最致命的地方。
一、没有“调用边界”的 A2A，一定会失控
很多 A2A 框架给人的错觉是：Agent 之间可以像人一样自由对话、自由协作。但在工程世界里，自由 ≈ 失控。
1️⃣ 最常见的翻车现场
你可能写过这样的逻辑：
Agent A：任务分配者
Agent B：执行者
Agent C：评审者
流程是：
A 把任务发给 B
B 完成后发给 C
C 不满意，打回给 B
B 再改
C 再评
问题来了：
C 有没有权限直接“无限次”打回？
B 有没有权力拒绝？
谁来限制这个循环？
在 Demo 里，它叫“多轮协作”；在生产环境里，它叫死循环烧钱器。
2️⃣ Agent 调用不是聊天，是 RPC
在 A2A 架构中，你必须有一个非常反直觉的认知：Agent 之间的调用，本质是 RPC，不是聊天。这意味着必须有明确的：
✅ 调用方（Caller）
✅ 被调用方（Callee）
✅ 最大调用次数
✅ 超时机制
✅ 错误返回码
否则你得到的不是智能协作，而是：两个概率模型在互相“礼貌推诿”，直到 Token 用光。
✅ 工程兜底建议
在 A2A 系统中，每一条 Agent → Agent 的调用都必须有硬边界：
最大轮数（max_turns）
最大 Token 预算
明确的“完成 / 失败”返回状态
超过边界，直接由代码中断流程
不要指望 Agent 自己“意识到该停了”。
二、A2A 中最危险的不是“错误”，而是“中间态”
很多人调 A2A 系统时，关注点都在：
最终输出对不对？
Agent 有没有幻觉？
但真正让系统崩溃的，往往是中间状态的不一致。
1️⃣ 一个典型的中间态灾难
想象这样一个流程：
Agent A 创建任务，状态：
CREATEDAgent B 开始执行，状态：
PROCESSINGAgent B 调用外部 API（慢）
Agent A 超时，以为 B 挂了
Agent A重新派发任务
两个 B 同时执行同一个任务
结果：
重复写数据库
重复发通知
重复扣钱
LLM 没犯错，但系统已经事故级别。
2️⃣ LLM 世界 ≠ 幂等世界
传统工程里，我们有一个非常重要的概念：幂等性（Idempotency）。同一个请求，执行一次和执行十次，结果应该一致。但在 A2A 架构里：
Agent B 的“执行”本身是概率性的
每一次执行路径都可能不同
你甚至无法保证它“意识到这是同一个任务”
如果你没有在代码层控制状态机，Agent 是不可能帮你保证一致性的。
✅ 工程兜底建议
A2A 系统里，状态只能由代码维护，不能交给 Agent 理解。你至少需要：
全局唯一
task_id明确的状态机（FSM）
CREATED → PROCESSING → DONE / FAILED严格禁止非法状态跳转
所有 Agent 只返回“结果”，不修改“状态”
一句话总结：Agent 负责“算”，系统负责“控”。
三、A2A 最大的隐性成本：调试与可观测性
很多人第一次做 A2A Demo 时，都会有一种兴奋感：“哇，它们自己在对话！”但当你第一次线上出 Bug，你就会意识到：Agent 对话 ≠ 可调试系统。
1️⃣ “对话日志”不是可观测性
常见做法是：
把 Agent A / B / C 的对话全部存下来
出问题时人工翻日志
这在 POC 阶段还能忍，一旦进入生产：
一次请求 = 上百条对话
每条对话 = 几百 Token
没有结构化语义
没有统一 Trace
你会发现：根本没人能完整复盘一次失败路径。
2️⃣ A2A 需要“分布式追踪”，不是聊天记录
在微服务时代，我们早就知道：
日志 ≠ 观测
必须有 Trace / Span / Metrics
但在 A2A 系统里，很多人又退回了“看文本”的原始阶段。这是非常危险的倒退。
✅ 工程兜底建议
真正可上线的 A2A 系统，必须具备：
✅ 全链路
trace_id✅ 每个 Agent 调用是一个 Span
✅ 明确的输入 / 输出 Schema
✅ Token、延迟、失败率指标
✅ 可重放（Replay）能力
否则你会陷入一种状态：系统“看起来很聪明”，但一旦出事，没人知道它刚才到底在干什么。
结语：A2A 不是“多一点 Agent”，而是“多一层系统复杂度”
很多人以为：A2A = 单 Agent × N 这是一个非常危险的误解。实际上：A2A = 分布式系统 + 概率模型 + 高不确定性
它放大了传统系统里所有的问题：
调用边界
状态一致性
观测与调试
成本失控
如果你没有工程兜底意识，A2A 架构只会让系统：
更难预测
更难控制
更难上线
Agent 的“智能”不应该成为系统不负责任的借口。真正成熟的 A2A 架构，应该是：用最死板、最保守、最确定的工程结构，包裹最不确定的智能能力。这不是保守，这是工程成熟度。