核心观点：单个Agent能力再强，也终究是孤军奋战。真正实现生产力倍增的关键，在于多个专业Agent的高效协作——而AgentRun能将这一过程简化到如同调用一个API那般便捷。
多Agent并非全新概念，真正的难点也不在于把任务拆解给几个Agent。生产环境落地的瓶颈在于：拆分之后，如何确保它们能稳定地相互发现、顺畅调用、彼此信任，并在团队协作、环境隔离、权限管控及链路追踪方面实现可管理性。
AgentRun的设计目标正是将这些工程复杂性收敛到平台层面：通过A2A开放协议打破智能体孤岛，借助工作空间提供生产级管理，让开发者可以专注于Agent自身能力的打磨与提升。
从单Agent到多Agent：协作落地的真实挑战
试想：一个负责“点咖啡”的Agent，却要管理配送路线；一个负责“写代码”的Agent，还得操心审批流程。这显然不符合职责分离原则。更务实的做法是让不同Agent各司其职，并通过一套稳定的协作机制，使它们能够相互发现、相互调用。
问题在于，自建多Agent系统并不只是“多写几个Agent”那么简单。你必须自行解决一整套平台工程问题：
- 注册中心： 哪些Agent在线？属于哪个环境？当前地址是什么？
- 服务发现： 调用方如何找到合适的Agent？如何读取它的能力描述？
- 跨Agent鉴权： 谁可以发现谁、调用谁？凭证如何轮转？
- 调度编排： 复杂任务如何拆解、分发、重试、聚合结果？
- 环境隔离： 开发、测试、生产环境的Agent如何避免相互混用？
- 链路追踪： 一次用户请求跨越多个Agent后，如何定位慢调用和失败点？
每一项单独看都是一个工程项目，加起来甚至可能比编写Agent本身的代码还要多。AgentRun要解决的并非“发明多Agent”，而是让多Agent从实验室协作真正变成可上线、可管理、可审计的生产系统。
为什么选择A2A：用开放协议定义“怎么发现、怎么通信”
多Agent协作最怕被平台的私有协议锁死：每接入一个Agent，就要重新适配一套能力描述、鉴权方式和调用协议。Agent一多，系统很快变成烟囱。
A2A（Agent-to-Agent）是Google主导的开放协议，不绑定任何特定平台。这意味着你自建的Agent、第三方的Agent、不同云厂商的Agent，只要遵循A2A协议，就能基于同一套标准相互发现和通信。
它的价值在于为Agent之间的互联提供了一套开放、统一的基础约定：
- 自描述： 通过AgentCard描述Agent是谁、能做什么、如何访问；
- 可发现： 调用方可以基于标准入口获取AgentCard，而不是依赖人工配置；
- 可互通： 不同团队、不同平台、不同运行环境的Agent，只要遵循协议，就能被统一接入；
- 可演进： 协议层定义连接方式，平台层可以继续补齐注册、权限、治理、观测等生产能力。
因此，AgentRun选择A2A，并非将A2A包装成私有能力，而是基于开放协议承接生态互通，再在协议之上补齐企业落地所需的管理面。
A2A发现机制原理
AgentCard：智能体的自我介绍
A2A协议通过AgentCard让每个智能体对外自描述能力与接入方式。AgentCard是一份标准JSON文档，描述了：
- 是谁： Agent的名称、描述、版本、提供方；
- 能做什么： 技能列表（Skills），每个技能包含ID、名称、描述及示例问法；
- 怎么访问： 服务地址（URL）、支持的传输协议（如JSON-RPC / gRPC）；
- 有什么限制： 认证方式、是否支持流式响应等。
按照A2A标准，AgentCard默认托管在 /.well-known/agent-card.json 路径下。客户端只需知道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）：按环境隔离的发现入口
一个工作空间内可以配置多个发现端点，典型用法是按部署环境区分：
每个发现端点维护一张映射表，记录“哪个Agent”对应“哪个访问地址”。同一个Agent在不同端点中可以配置不同地址，例如开发地址和生产自定义域名。
平台托管 vs 外部Agent：统一的发现体验
AgentRun支持两类Agent共存于同一工作空间：
两类Agent在发现端点中的表现完全一致——调用方拿到的都是标准 a2aAgentCardUrl，无需关心Agent实际部署在哪里。
凭证安全保护：谁可以发现这些Agent？
服务发现本身就是敏感信息：暴露工作空间内有哪些Agent、它们在哪里，可能为攻击者提供侦察入口。AgentRun在发现端点上内置了凭证验证体系，支持API Key、HTTP Basic Auth等方式。
凭证配置与工作空间解耦。更换凭证时，只需在平台重新绑定，无需修改任何Agent的代码。
实战体验：用“希希咖啡厅”跑通发现链路
接下来用“希希咖啡厅”多Agent系统作为演示对象。目标不是展开SDK细节，而是让你看到一套多Agent如何被纳入AgentRun的工作空间，并通过统一发现端点暴露为A2A可调用资源。
1. 部署模板，准备两个专职Agent
在AgentRun控制台的Agent模版页面一键部署“希希咖啡厅”，平台会自动创建两个专职Agent：
coffee_agent：负责点单、查看菜单、查询订单；delivery_agent：负责安排配送和查询配送状态。
2. 创建工作空间，确定管理边界
新建一个Workspace，作为这组Agent的组织、隔离和发现边界。后续所有服务发现都以工作空间为范围。
3. 注册Agent，统一托管与外部接入
将平台托管Agent或外部A2A兼容Agent纳入工作空间。注册完成后，调用方看到的都是统一的 a2aAgentCardUrl，不需要关心Agent实际部署在AgentRun、客户自建服务还是第三方平台。
4. 配置发现端点，暴露可控的发现入口
在工作空间的“服务发现”中添加端点，配置Agent映射和访问凭证。你可以按环境拆分端点，例如default用于调试，production只暴露稳定版Agent。
5. 调用发现端点，拿到AgentCard入口
配置完成后，请求工作空间的discovery API：
响应中的 a2aAgentCardUrl 就是A2A客户端连接对应Agent的入口。到这里，链路已经跑通：注册Agent → 配置发现端点 → 获取AgentCard URL → 发起A2A通信。
完整协议字段和SDK调用方式可以直接参考官方规范：A2A官方规范、a2a-go SDK。
从发现到调度：超级Agent与生产级多Agent方案
走通A2A发现链路后，多Agent系统具备了“怎么发现、怎么通信”的基础。但真正进入业务场景，还会继续遇到一个问题：很多用户知道有哪些Agent，却不知道如何搭建协作关系、如何选择调用顺序、如何把复杂任务拆给合适的Agent。
这就是AgentRun超级Agent要解决的问题。它不是放在A2A之前的孤立功能，而是在A2A发现和工作空间管理之上的调度入口：
- A2A定义Agent如何自描述、如何被发现、如何通信；
- 工作空间定义Agent如何被组织、隔离、授权、治理；
- 超级Agent进一步承担Orchestrator角色，把用户意图拆成子任务，并动态调用合适的专职Agent。
相比业界常见的“框架式多Agent Demo”，AgentRun更关注生产落地中的管理面：
- 开放互通： 基于A2A接入平台托管Agent和外部Agent，避免被私有协议锁死；
- 统一治理： 通过工作空间、发现端点和凭证体系管理Agent的可见范围与访问边界；
- 服务端编排： 超级Agent在服务端完成调度，调用方只需要面向一个入口发起请求；
- 生产可观测： 跨Agent调用链路可追踪、可审计，便于定位复杂协作中的失败点；
- 渐进演进： 先用A2A和工作空间管起来，再用超级Agent把协作调度做起来。
换句话说，AgentRun不是只提供一个多Agent编程框架，而是提供一套从开放协议、注册发现、权限隔离到调度编排的生产级方案。后续篇章中，我们会继续展开超级Agent如何完成任务拆解、子Agent选择和服务端编排。
小结
AgentRun让多Agent协作变得像调用一个API一样简单——用A2A这一开放标准打破智能体孤岛，用工作空间实现生产级管理，并用超级Agent将协作真正组织起来。
如果你已经有自建Agent、第三方Agent或不同云上的Agent，只要它们遵循A2A协议，就可以被纳入同一套发现和通信体系；如果你还没有调度体系，AgentRun也提供了从注册发现、权限隔离到服务端编排的生产级路径。
