Google 最近扔出一篇技术博客，演示怎么把 Python 和 Go 两个完全不同语言栈的智能体拼成一条流水线：Python 端调 Gemini 解析合同条款，Go 端用纯确定性逻辑跑合规校验，两边靠 A2A 协议（Agent2Agent）对话。整套方案的核心思路一句话就能讲完——别再把所有活儿塞进一个超长 system prompt 里了，把它拆成若干专业化的微智能体，让它们互相调用。A2A 协议的角色很像代理世界里的 HTTP：Agent Card 负责声明"我能干什么"，JSON-RPC 2.0 负责实际通信，Task 状态机负责追踪每个任务从提交到完成的生命周期。Google 自家的 ADK 则提供了一个叫 RemoteA2aAgent 的抽象层，能把任何符合 A2A 规范的远程服务包装成本地子智能体来用。
把单体提示词拆成微智能体的好处，博客里点得很透：上下文窗口是有限的，什么都往里塞迟早会遇到注意力稀释的问题；单体架构一旦某个环节出错，调试时根本不知道锅在哪儿，故障爆炸半径覆盖整条链路；更别提端到端测试几乎无从下手——你只能测整头怪兽，没法单独验某个爪子。拆开之后，每个微智能体职责清晰、接口明确，可以独立写单测、独立部署、独立替换。Python 负责需要语义理解的非结构化解析，Go 负责规则明确、不容许幻觉的合规校验，两边各司其职，组合出来的系统既灵活又可控。完整源码已经挂在 GitHub 上，复制就能跑。
不过话说回来，这套方案绑得相当死。A2A 协议本身是开放规范没错，但 ADK 的 RemoteA2aAgent 抽象、Agent Card 的发现机制、以及整条链路上 Gemini 的深度嵌入，都在暗示一件事：Google 想把多智能体协作做成下一个全家桶入口。你要是已经在 Google Cloud 生态里，导入即用，体感丝滑；但要是想把这套架构平移到 AWS、Azure 或者自建 K8s 上，光是 Agent Card 注册中心、Task 状态持久化、跨网络的服务发现这三件事就得自己造半轮子。生态绑定从来不是免费的午餐——它在你省事的时候让你爽到飞起，也在想走的时候让你寸步难行。多智能体协作的"HTTP 时刻"确实在靠近，但谁能定义标准、谁能收割红利，这盘棋还没下完。
