作者：丛霄，悠逸
单个 Agent 再强，也只是一个人在战斗。真正的生产力倍增，来自多个专职 Agent 的协同——而 AgentRun 让这件事变得像调一个 API 一样简单。多 Agent 并不是新概念，难点也不在于把任务拆给几个 Agent。真正卡住生产落地的，是拆完之后怎么让它们稳定地互相发现、互相调用、互相信任，并且在团队、环境、权限和链路追踪上可管理。 AgentRun 的定位正是把这部分工程复杂度收敛到平台： 用 A2A 开放协议打破智能体孤岛，用工作空间提供生产级管理，让开发者把精力放回 Agent 能力本身。
## 一、从单 Agent 到多 Agent：为什么协作难落地
单个 Agent 再强大，面对跨领域的复杂任务，终究会遇到能力边界。一个「点咖啡」的 Agent 不应该知道怎么「安排配送」，一个「写代码」的 Agent 不应该知道怎么「审批流程」。更合理的方式，是让不同 Agent 各司其职，再通过协作机制互相发现、互相调用。 问题在于，自建一套多 Agent 系统并不只是“多写几个 Agent”。你还需要自己解决一整套平台工程问题：
- 注册中心：哪些 Agent 在线？属于哪个环境？当前地址是什么？
- 服务发现：调用方如何找到合适的 Agent？如何读取它的能力描述？
- 跨 Agent 鉴权：谁可以发现谁、调用谁？凭证如何轮转？
- 调度编排：复杂任务如何拆解、分发、重试、聚合结果？
- 环境隔离：开发、测试、生产的 Agent 如何避免互相串用？
- 链路追踪：一次用户请求跨多个 Agent 后，如何定位慢调用和失败点？
二、为什么选择 A2A：用开放协议定义“怎么发现、怎么通信”
多 Agent 协作最怕被平台私有协议锁死：每接一个 Agent，就要重新适配一套能力描述、鉴权方式和调用协议。Agent 一多，系统很快变成烟囱。 A2A（Agent-to-Agent）是 Google 主导的开放协议，不绑定任何平台。这意味着你自建的 Agent、第三方的 Agent、不同云厂商的 Agent，只要遵循 A2A，就能基于同一套标准互相发现和通信。 它的价值，在于为 Agent 之间的互联提供了一套开放、统一的基础约定：- 自描述：通过 AgentCard 描述 Agent 是谁、能做什么、怎么访问；
- 可发现：调用方可以基于标准入口获取 AgentCard，而不是依赖人工配置；
- 可互通：不同团队、不同平台、不同运行环境的 Agent，只要遵循协议，就能被统一接入；
- 可演进：协议层定义连接方式，平台层可以继续补齐注册、权限、治理、观测等生产能力。
三、A2A 发现机制原理
AgentCard：智能体的自我介绍
A2A 协议通过 AgentCard 让每个智能体对外自描述能力与接入方式。AgentCard 是一份标准 JSON 文档，描述了：- 是谁：Agent 的名称、描述、版本、提供方；
- 能做什么：技能列表（Skills），每个技能有 ID、名称、描述和示例问法；
- 怎么访问：服务地址（URL）、支持的传输协议（如 JSON-RPC / gRPC）；
- 有什么限制：认证方式、是否支持流式响应等。
<font style="color:rgb(51, 51, 51);background-color:rgba(27, 31, 35, 0.05);">/.well-known/agent-card.json</font>
路径下。客户端只需知道 Agent 的 Base URL，就能拿到这份自描述文档，进而决定如何与它通信。
服务发现：谁在这个网络里？
有了 AgentCard，还缺一个关键问题的答案： 我怎么知道有哪些 Agent 可以调用？A2A 协议本身不强制定义中心化注册表，实际项目中通常需要一个「发现层」来管理 Agent 的注册和查询。发现层接受查询请求，返回可用 Agent 的 AgentCard URL，调用方再逐一拉取 AgentCard 完成能力感知。 这也是 AgentRun 发挥价值的地方：协议定义“怎么描述、怎么连接”，平台负责“怎么注册、怎么发现、怎么隔离、怎么治理”。
四、AgentRun 的多 Agent 管理：注册、发现与隔离
AgentRun 在 A2A 协议基础上，提供了一套生产级的多 Agent 管理体系，核心围绕三个概念：工作空间（Workspace）：逻辑隔离的 Agent 集合
工作空间是 AgentRun 中组织 Agent 的基本单位，类似于一个「项目空间」或「命名空间」。不同业务域、不同团队的 Agent 可以分属不同工作空间，互相隔离，权限独立管理。 一个 Agent Runtime 归属于一个工作空间后，工作空间就成为它对外可被发现的范围边界。发现端点（Discovery Endpoint）：按环境隔离的发现入口
一个工作空间内可以配置多个发现端点，典型用法是按部署环境区分：工作空间: my-ai-platform
├── 发现端点 default → 面向内部调试，包含所有 Agent
└── 发现端点 production → 面向生产流量，只含稳定版 Agent
平台托管 vs 外部 Agent：统一的发现体验
AgentRun 支持两类 Agent 共存于同一工作空间：| 类型 | 部署方式 | 注册方式 | 状态流转 |
|---|---|---|---|
| 平台托管 Agent | AgentRun 负责部署到 FC | 通过创建注册 | CREATING → READY |
| 外部 Agent | 自行部署在任意位置 | 手动注册到指定空间 | 直接 READY |
<font style="color:rgb(51, 51, 51);background-color:rgba(27, 31, 35, 0.05);">a2aAgentCardUrl</font>
，无需关心 Agent 实际部署在哪里。
凭证安全保护：谁可以发现这些 Agent？
服务发现本身就是敏感信息：暴露工作空间内有哪些 Agent、它们在哪里，可能为攻击者提供侦察入口。AgentRun 在发现端点上内置了凭证验证体系，支持 API Key、HTTP Basic Auth 等方式。 凭证配置与工作空间解耦。更换凭证时，只需在平台重新绑定，无需修改任何 Agent 的代码。五、实战体验：用“希希咖啡厅”跑通发现链路
本文以「希希咖啡厅」多 Agent 系统作为演示对象。目标不是展开 SDK 细节，而是让你看到一套多 Agent 如何被纳入 AgentRun 的工作空间，并通过统一发现端点暴露为 A2A 可调用资源。1. 部署模板，准备两个专职 Agent
在 AgentRun 控制台的 Agent 模版 页面一键部署「希希咖啡厅」，平台会自动创建两个专职 Agent：<font style="color:rgb(51, 51, 51);background-color:rgba(27, 31, 35, 0.05);">coffee_agent</font>：负责点单、查看菜单、查询订单；<font style="color:rgb(51, 51, 51);background-color:rgba(27, 31, 35, 0.05);">delivery_agent</font>：负责安排配送和查询配送状态。
2. 创建工作空间，确定管理边界
新建一个 Workspace，作为这组 Agent 的组织、隔离和发现边界。后续所有服务发现都以工作空间为范围。
### 3. 注册 Agent，统一托管与外部接入
将平台托管 Agent 或外部 A2A 兼容 Agent 纳入工作空间。注册完成后，调用方看到的都是统一的
<font style="color:rgb(51, 51, 51);background-color:rgba(27, 31, 35, 0.05);">a2aAgentCardUrl</font>
，不需要关心 Agent 实际部署在 AgentRun、客户自建服务还是第三方平台。
4. 配置发现端点，暴露可控的发现入口
在工作空间的「服务发现」中添加端点，配置 Agent 映射和访问凭证。你可以按环境拆分端点，例如<font style="color:rgb(51, 51, 51);background-color:rgba(27, 31, 35, 0.05);">default</font>
用于调试，
<font style="color:rgb(51, 51, 51);background-color:rgba(27, 31, 35, 0.05);">production</font>
只暴露稳定版 Agent。
5. 调用发现端点，拿到 AgentCard 入口
配置完成后，请求工作空间的 discovery API：curl -s \
-H 'X-API-Key: <your-api-key>' \
'https://<uid>.agentrun-data.cn-hangzhou.aliyuncs.com/workspaces/<workspace-name>/discovery/agents?discoveryEndpointName=default'
<font style="color:rgb(51, 51, 51);background-color:rgba(27, 31, 35, 0.05);">a2aAgentCardUrl</font>
就是 A2A 客户端连接对应 Agent 的入口。到这里，链路已经跑通：
注册 Agent → 配置发现端点 → 获取 AgentCard URL → 发起 A2A 通信
。
完整协议字段和 SDK 调用方式可以直接参考官方资料：
- A2A 官方规范：https://a2a-protocol.org/latest/specification/
- a2a-go SDK 示例：https://github.com/a2aproject/a2a-go
六、从发现到调度：超级 Agent 与生产级多 Agent 方案
走通 A2A 发现链路后，多 Agent 系统具备了“怎么发现、怎么通信”的基础。但真正进入业务场景，还会继续遇到一个问题： 很多用户知道有哪些 Agent，却不知道该怎么搭建协作关系、怎么选择调用顺序、怎么把复杂任务拆给合适的 Agent。这就是 AgentRun 超级 Agent 要解决的问题。它不是放在 A2A 之前的孤立功能，而是在 A2A 发现和工作空间管理之上的调度入口：
- A2A 定义 Agent 如何自描述、如何被发现、如何通信；
- 工作空间定义 Agent 如何被组织、隔离、授权、治理；
- 超级 Agent 进一步承担 Orchestrator 角色，把用户意图拆成子任务，并动态调用合适的专职 Agent。
用户：“帮我点一杯拿铁，送到公司”
│
▼
┌─────────────────────┐
│ 超级 Agent (主) │ ← 理解意图，拆解为子任务
│ Orchestrator │
└──────┬──────┬───────┘
│ │
▼ ▼
┌──────────┐ ┌──────────┐
│coffee_ │ │delivery_ │ ← 各自执行专属任务
│agent │ │agent │
└──────────┘ └──────────┘
│ │
▼ ▼
创建订单 安排配送
- 开放互通：基于 A2A 接入平台托管 Agent 和外部 Agent，避免被私有协议锁死；
- 统一治理：通过工作空间、发现端点和凭证体系管理 Agent 的可见范围与访问边界；
- 服务端编排：超级 Agent 在服务端完成调度，调用方只需要面向一个入口发起请求；
- 生产可观测：跨 Agent 调用链路可追踪、可审计，便于定位复杂协作中的失败点；
- 渐进演进：先用 A2A 和工作空间管起来，再用超级 Agent 把协作调度做起来。
七、小结
AgentRun 让多 Agent 协作像调一个 API 一样简单——用 A2A 这个开放标准打破智能体孤岛，用工作空间实现生产级管理，并用超级 Agent 把协作真正组织起来。 如果你已经有自建 Agent、第三方 Agent 或不同云上的 Agent，只要它们遵循 A2A，就可以被纳入同一套发现和通信体系；如果你还没有调度体系，AgentRun 也提供了从注册发现、权限隔离到服务端编排的生产级路径。附录：相关链接
- AgentRun 控制台：https://functionai.console.aliyun.com/
- A2A Protocol Specification：https://a2a-protocol.org/latest/specification/
- a2a-go SDK：https://github.com/a2aproject/a2a-go
- AgentRun Python SDK：https://github.com/Serverless-Devs/agentrun-sdk-python
- 产品文档：阿里云函数计算 AgentRun
- AgentRun 客户群群号： 134570017218，如有技术问题或合作意向，欢迎联系我们。
