2025 年 12 月，豆包手机助手尝试通过识别屏幕和模拟点击操作微信、银行等应用，随后与部分应用的风控发生冲突。到了 2026 年 6 月，微信开始通过与手机厂商合作，向外部助手开放发送消息和发起音视频通话等少数能力。

这两个案例都在做跨应用操作，但底层方式并不相同。前者使用手机系统提供的操作权限，模拟用户点击界面；后者由应用主动提供可以调用的能力。理解这一区别，才能解释 A2A 为什么会出现。

屏幕操作和协议调用使用不同的权限

图形界面自动化依赖视觉识别、无障碍能力或系统级操作权限。Agent 看到按钮后执行点击，目标应用不需要提前提供接口。这种方式覆盖面广，但也有三个明显限制。

第一个限制是界面不稳定。按钮位置、弹窗和页面结构发生变化，都可能让原来的操作路径失效。

第二个限制是缺少明确的能力声明。Agent 只能从屏幕推测当前可以做什么，很难在执行前确认目标应用支持哪些动作、需要哪些参数。

第三个限制是权限来源不同。用户可以允许 Agent 操作手机系统，但目标应用仍会按照自己的风控规则判断这些操作。涉及登录、支付和身份验证时，模拟点击很容易被识别为异常行为。

A2A 协议走的是另一条路径。远端 Agent 主动声明自己提供哪些能力、如何连接以及需要什么认证，调用方再按照协议提交任务。目标应用不需要暴露内部模型、记忆和工具，只需要提供一个符合协议的服务端点。

A2A v1.0 把协作拆成可追踪对象

谷歌在 2025 年 4 月发布智能体间协作协议，随后将项目捐给 Linux 基金会。当前的 A2A v1.0 没有规定 Agent 内部必须使用什么模型，而是定义两个 Agent 在网络边界上怎样发现能力、提交任务和返回结果。

智能体名片（Agent Card）是能力发现入口。它是一份 JSON 元数据，包含 Agent 的身份、服务地址、协议版本、支持的技能、输入输出类型和认证要求。调用方可以先读名片，再决定这个 Agent 是否适合处理当前任务。

建立连接后，简单请求可以直接返回消息（Message）。需要持续执行或多轮交互的工作会创建任务（Task），服务端通过任务状态说明当前进度。

TASK_STATE_SUBMITTED
        ↓
TASK_STATE_WORKING
        ↓
TASK_STATE_INPUT_REQUIRED / TASK_STATE_AUTH_REQUIRED
        ↓
TASK_STATE_COMPLETED / TASK_STATE_FAILED
TASK_STATE_CANCELED / TASK_STATE_REJECTED

等待用户补充参数时，任务可以进入需要输入状态；需要重新认证时，可以进入需要授权状态；执行结束后，则进入完成、失败、取消或拒绝等终态。任务一旦进入终态就不会重新启动，后续修改会创建新任务，并通过上下文标识与原任务关联。这种设计让每次输入、状态变化和结果都有独立记录。

任务生成的文档、图片或结构化数据会作为交付物（Artifact）返回。执行时间较长时，调用方可以通过服务器发送事件接收流式更新，也可以通过推送通知在连接断开后继续获得状态变化。

A2A v1.0 还加入了智能体名片签名、开放授权（OAuth）、版本协商和多租户支持。协议处理的不只是消息格式，也包括身份验证、长任务跟踪和结果交付。

协议能标准化协作，但不能替平台决定授权

A2A 可以说明如何发现能力、提交任务和返回结果，却不会自动决定一个平台应该开放哪些动作。

智能体名片中的认证要求只负责声明接入条件，真正的授权范围仍由服务端控制。发送一条消息、读取联系人、访问企业文档和发起支付，需要的风险等级完全不同。平台仍然要决定哪些动作可以自动执行，哪些动作必须让用户再次确认，以及发生异常后怎样撤销和追溯。

目前国内公开的跨应用案例仍以平台之间单独合作为主，还没有形成可以自由发现能力的统一 Agent 网络。即使合作双方都使用了 A2A 这个名称，也不能据此确认它们完整实现了 Linux 基金会维护的公开协议。

标准协议也不会立即覆盖所有应用。已经开放接口的能力可以逐步转向 A2A，没有接口的长尾应用仍然需要依靠屏幕识别和模拟点击。未来一段时间，两种方式会同时存在。

判断跨应用协作是否真正进入标准化阶段，可以观察三个技术信号，平台是否公开可发现的智能体名片，是否接受带有明确生命周期的标准任务，以及是否返回可以追踪的交付物。在这些机制普及之前，国内 A2A 仍然主要是逐家适配，而不是一张开放的 Agent 协作网络。