Agent 发现机制

A2A Protocol 通过 AgentCard 标准化了在发现过程中共享的数据格式。然而，发现这些 AgentCard 的具体方式是多种多样的，这也是一个开放讨论的话题。

以下是目前设想的几种主要发现机制：

开放发现 (Open Discovery)

我们推荐企业在其服务的域名下托管 AgentCard，并遵循一个"众所周知"的路径约定：

https://<DOMAIN>/.well-known/agent.json

客户端可以通过 DNS 解析找到或已知的域名，然后向该路径发送简单的 HTTP GET 请求即可获取 AgentCard。

这种方式使得 Web 爬虫和应用程序能够轻松发现已知或已配置域名的 Agent，有效地将发现过程简化为"找到域名"。

示例请求

curl https://example.com/.well-known/agent.json

示例响应

{
  "name": "ExampleAgent",
  "description": "这是一个示例Agent",
  "url": "https://example.com/agent",
  "provider": {
    "organization": "Example Org",
    "url": "https://example.com"
  },
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": false
  }
}

策展发现 (Curated Discovery / 基于注册表)

可以预见，企业级应用程序会通过目录接口提供经过策展的 Agent 注册表。这将支持更多企业场景，例如由管理员维护的公司特定或团队特定的 Agent 注册表。

社区正在考虑是否将注册表支持添加到协议标准中。欢迎提供您的意见和想法。

私有发现 (Private Discovery / 基于 API)

毫无疑问，会出现私有的"Agent 商店"或专有 Agent，其 AgentCard 通过自定义 API 进行交换。

目前，私有发现 API 不被视为 A2A Protocol 本身需要解决的问题。如果您认为将其标准化有价值，也欢迎提出意见。

AgentCard 安全性

AgentCard 可能包含敏感信息。实现者可以选择使用访问控制来保护其 AgentCard，要求进行身份验证和授权。

例如，在一个组织内部，即使是遵循 .well-known 路径的开放发现，也可以通过 mTLS 进行保护，并限制只有特定的客户端才能访问。注册表和私有发现 API 应当 要求身份验证，并根据不同的身份返回不同的内容。

重要提示: 实现者可能会在 AgentCard 中包含凭证信息（如 API 密钥）。强烈建议 永远不要 在未经身份验证的情况下暴露这些信息。