在上一期「Agent 小知识 | A2A 和 MCP 怎么一起用」中，发布协调 Agent 通过 A2A，把 payment-service 的依赖兼容性分析交给了一个专业 Agent。按第十四期「Agent 小知识｜A2A 是什么：Agent 之间怎么通信」中的称呼，发起委派的是请求方，接收委派的是服务方。在这个案例里，两者分别是协调方和专业方。

沿用这个虚拟案例，payment-service 又要做一次升级分析。这次有好几个 Agent 都能做依赖兼容性分析，协调方手里也已经有了锁文件。它该从哪里找到这些候选，又凭什么把工作交给其中一位？

这就用到了 Agent Registry（Agent 注册中心）。它把多个 Agent 的能力信息组织成一个可查询的目录。协调方可以从所需的能力出发，先找出可能承接任务的对象，再决定具体调用哪一个。

一图概览 | 怎样找到合适的专业 Agent

图注：协调方从目录查到候选，按锁文件格式选定专业方，再经 A2A 提交分析请求。

查找候选

之前我们讲过能力卡。它描述某个 Agent 提供的技能，并列出可用来与该 Agent 协作的接口。已知目标域名时，如果对方在 /.well-known/agent-card.json 提供能力卡，可以从这个地址取卡。如果协作对象事先已确定，也可以直接配置能力卡内容或取卡地址。

这一次，协调方以「依赖兼容性分析」为条件，向内部目录发起查询。目录按这个技能分类检索，在协调方有权查看的记录里命中 A 和 B，返回两张能力卡。此时协调方得到的是一份候选名单。接下来，协调方会根据卡片里的技能描述选择目标，再根据接口声明发起调用。

在这条链路上，目录查询地址用来找候选，能力卡里的调用地址用来向选中的 Agent 提交任务。如果目录返回的是卡片引用，比如一个取卡地址，协调方就多走一步，先取得能力卡，再读出卡里的调用地址。A2A 规范定义了能力卡和协作接口，目录查询的接口和条件由采用的实现决定。

一次查询能找到谁，取决于目录收录了哪些条目、查询条件能命中哪些条目，以及哪些结果对当前调用方可见。因此，查到空结果时，可以先核对技能分类和自己的可见范围。这个结果只反映当前目录的这一次查询。

维护目录

回到查询之前，两个专业 Agent 的维护团队各自提交了能力卡，目录为每张卡建立条目，把两者都归到「依赖兼容性分析」这个技能分类下。拿 A 的记录展开看，协调方会在不同环节用到这些信息。

这张表只列出本例用到的信息。目录条目帮助应用找到卡，能力卡帮助应用了解并连接某个 Agent。 即使卡片存放在别处，目录也可以保存可检索的技能分类或摘要，并关联取卡地址。多个团队陆续提供专业 Agent 时，维护团队登记新卡，目录更新索引，协调方用原来的能力条件就能查到新近可见的候选。

目录也可以按调用方的身份设置可见范围。比如，A 的能力卡只向发布团队展示。其他团队即使用同样的「依赖兼容性分析」条件查询，也查不到 A 的能力卡。发布团队能查到 A，真正提交任务时，A 的服务接口仍会校验调用权限。

假设 A 后来升级，换了调用地址。A 的维护团队提交新卡，目录更新对应条目。能力卡上的 version 表示 A 自身的版本，接口上的 protocolVersion 表示该接口支持的 A2A 版本。比如，A 可以从 1.3.0 升到 1.4.0，同时继续使用 A2A 1.0。目录也可以在查询结果里附上条目的更新时间。协调方发现条目比手里的记录更新时，可以重新取卡，核对技能描述和调用地址。

如果 A 停用，本例由维护团队通知目录撤下条目。下架后，新的目录查询就不会再返回 A。已经拿到旧卡的调用方，仍需要核对手中的入口是否有效。提交、更新和下架的具体流程由这套目录约定。

选定并委派

回到 payment-service 这次升级。两张卡都写着能做依赖兼容性分析，但协调方还要看它们声明能处理哪种输入。这次拿到的是 npm 的 package-lock.json。

目录按同一技能分类返回了两张卡。协调方逐一核对卡片里的技能描述，确认 A 支持本次的锁文件格式，于是选中 A。如果目录有候选，但它们的技能描述都没有覆盖本次输入，协调方就反馈没有合适的匹配项，暂缓提交分析材料。换成另一项任务时，同样可以把所需的输出形式和候选声明的输出能力放在一起核对。

选中 A 之后，还要选用它的接口。能力卡可能列出多个接口，协调方依照卡片顺序找到双方都支持的第一项，再使用该项的调用地址。选择接口时，协调方需要核对传输方式和 A2A 协议版本。

任务路由里的选目标和送请求是两个动作，可以由不同组件负责。本例两步都由协调方完成。刚才，目录收到的是「依赖兼容性分析」这一能力条件。现在，升级目标和锁文件随 A2A 请求直接发给 A。

格式匹配、服务可用和有权调用也各看不同的依据。格式匹配看技能描述。服务能否响应，要看运行信息或调用反馈。调用权限则由 A 的服务接口按自己的规则校验。如果发现 A 的接口当前不可达，协调方需要核对入口和服务状态。如果收到 A 返回的权限拒绝，就需要核对调用身份和授权范围。这两种情况都已有匹配目标，卡在发起协作这一步。

这次，协调方的请求通过了权限校验，A 接受委派并建立了分析任务。到这里，就接上了第十四期的 A2A 任务跟踪。A 接下分析后怎样通过 MCP 查询版本约束、读取兼容文档，则是第十五期讲的那一段。

结语

接入多个专业 Agent 时，可以用三个问题检查这条链路。谁维护候选的能力信息？协调方按什么条件查出候选？它又凭什么把这次任务交给其中一位？

找到能接活的 Agent 之后，还要决定交给它多少信息。下一期聊聊，Agent 之间该共享多少上下文，又该怎样保护隐私。