单个 Agent 再强，也只是一个人在战斗。真正的生产力倍增，来自多个专职 Agent 的协同——而 AgentRun 让这件事变得像调一个 API 一样简单。
多 Agent 并不是新概念，难点也不在于把任务拆给几个 Agent。真正卡住生产落地的，是拆完之后怎么让它们稳定地互相发现、互相调用、互相信任，并且在团队、环境、权限和链路追踪上可管理。
AgentRun 的定位正是把这部分工程复杂度收敛到平台：用 A2A 开放协议打破智能体孤岛，用工作空间提供生产级管理，让开发者把精力放回 Agent 能力本身。
单个 Agent 再强大，面对跨领域的复杂任务，终究会遇到能力边界。一个「点咖啡」的 Agent 不应该知道怎么「安排配送」，一个「写代码」的 Agent 不应该知道怎么「审批流程」。更合理的方式，是让不同 Agent 各司其职，再通过协作机制互相发现、互相调用。
问题在于，自建一套多 Agent 系统并不只是“多写几个 Agent”。你还需要自己解决一整套平台工程问题：
每一项单独看都是一个工程项目，加起来可能比写 Agent 本身的代码还多。AgentRun 要解决的不是“发明多 Agent”，而是让多 Agent 从实验室协作变成可上线、可管理、可审计的生产系统。
多 Agent 协作最怕被平台私有协议锁死：每接一个 Agent，就要重新适配一套能力描述、鉴权方式和调用协议。Agent 一多，系统很快变成烟囱。
A2A（Agent-to-Agent）是 Google 主导的开放协议，不绑定任何平台。这意味着你自建的 Agent、第三方的 Agent、不同云厂商的 Agent，只要遵循 A2A，就能基于同一套标准互相发现和通信。
它的价值，在于为 Agent 之间的互联提供了一套开放、统一的基础约定：
所以，AgentRun 选择 A2A，不是把 A2A 包装成自己的私有能力，而是基于开放协议承接生态互通，再在协议之上补齐企业落地所需的管理面。
A2A 协议通过 AgentCard 让每个智能体对外自描述能力与接入方式。AgentCard 是一份标准 JSON 文档，描述了：
按照 A2A 标准，AgentCard 默认托管在 /.well-known/agent-card.json路径下。客户端只需知道 Agent 的 Base URL，就能拿到这份自描述文档，进而决定如何与它通信。
有了 AgentCard，还缺一个关键问题的答案：我怎么知道有哪些 Agent 可以调用？
A2A 协议本身不强制定义中心化注册表，实际项目中通常需要一个「发现层」来管理 Agent 的注册和查询。发现层接受查询请求，返回可用 Agent 的 AgentCard URL，调用方再逐一拉取 AgentCard 完成能力感知。
这也是 AgentRun 发挥价值的地方：协议定义“怎么描述、怎么连接”，平台负责“怎么注册、怎么发现、怎么隔离、怎么治理”。
AgentRun 在 A2A 协议基础上，提供了一套生产级的多 Agent 管理体系，核心围绕三个概念：
工作空间是 AgentRun 中组织 Agent 的基本单位，类似于一个「项目空间」或「命名空间」。不同业务域、不同团队的 Agent 可以分属不同工作空间，互相隔离，权限独立管理。
一个 Agent Runtime 归属于一个工作空间后，工作空间就成为它对外可被发现的范围边界。
一个工作空间内可以配置多个发现端点，典型用法是按部署环境区分：
工作空间: my-ai-platform
├── 发现端点 default → 面向内部调试，包含所有 Agent
└── 发现端点 production → 面向生产流量，只含稳定版 Agent
每个发现端点维护一张映射表，记录「哪个 Agent」对应「哪个访问地址」。同一个 Agent 在不同端点中可以配置不同地址，例如开发地址和生产自定义域名。
AgentRun 支持两类 Agent 共存于同一工作空间：
| 类型 | 部署方式 | 注册方式 | 状态流转 |
|---|---|---|---|
| 平台托管 Agent | AgentRun 负责部署到 FC | 通过创建注册 | CREATING → READY |
| 外部 Agent | 自行部署在任意位置 | 手动注册到指定空间 | 直接 READY |
两类 Agent 在发现端点中的表现完全一致——调用方拿到的都是标准 ，无需关心 Agent 实际部署在哪里。
服务发现本身就是敏感信息：暴露工作空间内有哪些 Agent、它们在哪里，可能为攻击者提供侦察入口。AgentRun 在发现端点上内置了凭证验证体系，支持 API Key、HTTP Basic Auth 等方式。
凭证配置与工作空间解耦。更换凭证时，只需在平台重新绑定，无需修改任何 Agent 的代码。
本文以「希希咖啡厅」多 Agent 系统作为演示对象。目标不是展开 SDK 细节，而是让你看到一套多 Agent 如何被纳入 AgentRun 的工作空间，并通过统一发现端点暴露为 A2A 可调用资源。
在 AgentRun 控制台的 Agent 模版页面一键部署「希希咖啡厅」，平台会自动创建两个专职 Agent：
新建一个 Workspace，作为这组 Agent 的组织、隔离和发现边界。后续所有服务发现都以工作空间为范围。
将平台托管 Agent 或外部 A2A 兼容 Agent 纳入工作空间。注册完成后，调用方看到的都是统一的 a2aAgentCardUrl，不需要关心 Agent 实际部署在 AgentRun、客户自建服务还是第三方平台。
在工作空间的「服务发现」中添加端点，配置 Agent 映射和访问凭证。你可以按环境拆分端点，例如 default 用于调试，production 只暴露稳定版 Agent。
配置完成后，请求工作空间的 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'
响应中的 a2aAgentCardUrl 就是 A2A 客户端连接对应 Agent 的入口。到这里，链路已经跑通：注册 Agent → 配置发现端点 → 获取 AgentCard URL → 发起 A2A 通信。
完整协议字段和 SDK 调用方式可以直接参考官方资料：
走通 A2A 发现链路后，多 Agent 系统具备了“怎么发现、怎么通信”的基础。但真正进入业务场景，还会继续遇到一个问题：很多用户知道有哪些 Agent，却不知道该怎么搭建协作关系、怎么选择调用顺序、怎么把复杂任务拆给合适的 Agent。
这就是 AgentRun超级 Agent要解决的问题。它不是放在 A2A 之前的孤立功能，而是在 A2A 发现和工作空间管理之上的调度入口：
用户：“帮我点一杯拿铁，送到公司”
│
▼
┌─────────────────────┐
│ 超级 Agent (主) │ ← 理解意图，拆解为子任务
│ Orchestrator │
└──────┬──────┬───────┘
│ │
▼ ▼
┌──────────┐ ┌──────────┐
│coffee_ │ │delivery_ │ ← 各自执行专属任务
│agent │ │agent │
└──────────┘ └──────────┘
│ │
▼ ▼
创建订单 安排配送
相比业界常见的“框架式多 Agent Demo”，AgentRun 更关注生产落地中的管理面：
AgentRun 让多 Agent 协作像调一个 API 一样简单——用 A2A 这个开放标准打破智能体孤岛，用工作空间实现生产级管理，并用超级 Agent 把协作真正组织起来。
如果你已经有自建 Agent、第三方 Agent 或不同云上的 Agent，只要它们遵循 A2A，就可以被纳入同一套发现和通信体系；如果你还没有调度体系，AgentRun 也提供了从注册发现、权限隔离到服务端编排的生产级路径。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。