一个真实的问题
企业 Agent 从"内部工具"走向"对外协作"时，会遇到一个此前不存在的难题：两个分属不同公司、不同厂商的 Agent，如何互认、派活、跟进进度？这不是一个系统内部几个 Agent 的分工问题，而是跨组织信任与协作边界的设计问题。
这个问题现在有开放规范可循，叫 A2A（Agent2Agent）。它 2025 年 4 月由 Google 发起，同年 6 月捐给 Linux 基金会，2026 年 3 月发布 v1.0.0。本文不逐条罗列协议细节，重点谈它背后的设计原则，以及落地时真正要自己补的部分。
身份先行：AgentCard 与可验证信任
跨组织协作的第一步是身份。A2A 用一份 AgentCard（JSON 文件）承载身份信息，放在服务固定位置，任何人都可取。它包含四类信息：身份、能力与技能、服务地址、鉴权要求。
值得关注的是它的信任设计。从 v0.3 起，名片可带 JWS 密码学签名，让对方验证名片未被篡改、确实来自声称的提供方。这解决的是"你是谁"的证明问题，而不是"你干得怎样"的质量问题——后者协议本身并不承诺。
状态机：任务会"卡住"，不是只有成功失败
A2A 把一次委托叫 Task，其生命周期分三类共 8 种状态：进行中（已提交、进行中）、中断（等补信息、等授权）、结束（已完成、失败、被取消、被拒绝）。
两个中断态值得特别注意。它们意味着任务"没失败，但卡住了"：等补信息是对方发现条件不足，等授权是它调用的下游需要你的许可。补齐之后任务还能继续。这种设计承认了真实协作中"中途需要人介入"的常态，而不是把一切简化成一条直线流水线。
核心边界：协作不等于交底
这套规范最值得管理者理解的一条原则是：双方交换信息完成目标，不需要访问彼此的内部状态、记忆和工具；协作基于"对外声明的能力"和"交换的信息"，不必公开各自的思考过程、计划和工具实现。
这条边界为什么适合跨公司协作？因为交换目标和产物、不交换家底，双方才敢把对方接进自己的流程。你关心的是供应商 Agent"接了没、做到哪步、结果是什么"，而不是它用了哪个模型、调了哪些内部系统。反过来也一样。
但要注意，"不需要"不等于"不允许"。规范不强制、也不预设你要把内部实现摊开，双方仍可交换必要的消息和上下文。
一个必须自己补的缺口：验收
这套协议解决的是"怎么传"，不是"怎么信"。任务状态是执行方自己报的；签名名片证明的是身份，不是履约质量。因此验收这一环必须自己搭建：该测的测、该留日志的留日志、该人工审批的审批。把 Agent 接进关键流程之前，先想清楚谁来签字。
落地判断
规范由 Linux 基金会托管，官方提供多语言 SDK 与三种传输绑定（JSON-RPC、gRPC、HTTP+JSON/REST）。但它仍在迭代（v1.0.0 后又出 v1.0.1），不宜过早全面铺开。务实的路径是先挑一个边界清楚、责任明确的跨公司或跨供应商场景跑通，把名片、鉴权、状态同步、异常处理和验收全部走一遍，再评估是否扩大范围。
