Skip to content

A2A 的企业级实现

Agent2Agent (A2A) 协议的设计核心是企业级需求。A2A 并没有为安全和运维 invent 新的专有标准，而是旨在与现有企业基础设施和广泛采用的最佳实践无缝集成。这种方法允许组织利用其在安全、监控、治理和身份管理方面的现有投资和专业知识。

A2A 的一个关键原则是智能体通常是不透明的，因为它们不共享内部内存、工具或直接资源访问权限。这种不透明性自然与标准的客户端 - 服务器安全范式保持一致，将远程智能体视为基于标准 HTTP 的企业应用程序。

传输层安全 (TLS)

确保传输中数据的机密性和完整性对于任何企业应用程序都是基础性的。

  • HTTPS 强制要求：生产环境中的所有 A2A 通信必须通过 HTTPS 进行。
  • 现代 TLS 标准：实现应使用现代 TLS 版本。建议使用 TLS 1.2 或更高版本。应使用强大、行业标准的密码套件来保护数据免受窃听和篡改。
  • 服务器身份验证：A2A 客户端应通过在 TLS 握手期间验证 A2A 服务器的 TLS 证书与受信任的证书颁发机构来验证 A2A 服务器的身份。这可以防止中间人攻击。

身份验证

A2A 将身份验证委托给标准的 Web 机制。它主要依赖于 HTTP 头部和 OAuth2、OpenID Connect 等既定标准。身份验证要求由 A2A 服务器在其 Agent Card 中公布。

  • 载荷中无身份信息：A2A 协议载荷（如 JSON-RPC 消息）不直接携带用户或客户端身份信息。身份在传输/HTTP 层建立。
  • Agent Card 声明：A2A 服务器的 Agent Card 在其 security 字段中描述其支持的身份验证方案，并与 OpenAPI 规范中定义的身份验证方案保持一致。
  • 带外凭证获取：A2A 客户端通过 A2A 协议本身之外的过程获取必要的凭证，如 OAuth 2.0 令牌或 API 密钥。示例包括 OAuth 流程或安全密钥分发。
  • HTTP 头部传输：凭证必须根据所选身份验证方案的要求在标准 HTTP 头部中传输。示例包括 Authorization: Bearer <TOKEN> 或 API-Key: <KEY_VALUE>。
  • 服务器端验证：A2A 服务器必须使用 HTTP 头部中提供的凭证对每个传入请求进行身份验证。
    • 如果身份验证失败或缺少凭证，服务器应该响应标准 HTTP 状态码：
      • 401 Unauthorized：如果凭证缺失或无效。此响应应该包含 WWW-Authenticate 头部，以告知客户端支持的身份验证方法。
      • 403 Forbidden：如果凭证有效，但经过身份验证的客户端没有执行请求操作的权限。
  • 任务内身份验证（次要凭证）：如果智能体在任务期间需要额外的凭证来访问不同的系统或服务（例如，代表用户使用特定工具），A2A 服务器会向客户端指示需要更多信息。然后客户端负责通过 A2A 协议本身之外的过程（例如 OAuth 流程）获取这些次要凭证，并将其提供给 A2A 服务器以继续任务。

授权

客户端通过身份验证后，A2A 服务器负责授权请求。授权逻辑特定于智能体的实现、其处理的数据以及适用的企业策略。

  • 细粒度控制：应基于经过身份验证的身份应用授权，该身份可以代表最终用户、客户端应用程序或两者。
  • 基于技能的授权：可以根据 Agent Card 中公布的技能进行访问控制。例如，特定的 OAuth 范围应该授予经过身份验证的客户端调用某些技能但不能调用其他技能的访问权限。
  • 数据和操作级授权：与后端系统、数据库或工具交互的智能体必须在通过这些底层资源执行敏感操作或访问敏感数据之前实施适当的授权。智能体充当看门人。
  • 最小权限原则：智能体必须仅授予客户端或用户通过 A2A 接口执行其预期操作所需的必要权限。

数据隐私和机密性

保护智能体之间交换的敏感数据至关重要，需要严格遵守隐私法规和最佳实践。

  • 敏感性意识：实现者必须敏锐意识到 A2A 交互中消息和工件部分交换数据的敏感性。
  • 合规性：确保遵守相关的数据隐私法规，如 GDPR、CCPA 和 HIPAA，基于涉及的领域和数据。
  • 数据最小化：避免在 A2A 交换中包含或请求不必要的敏感信息。
  • 安全处理：根据企业数据安全策略和监管要求，使用强制的 TLS 保护传输中的数据，并在智能体持久化时保护静态数据。

追踪、可观察性和监控

A2A 对 HTTP 的依赖允许与标准企业追踪、日志记录和监控工具直接集成，为智能体间工作流提供关键的可见性。

  • 分布式追踪：A2A 客户端和服务器应该参与分布式追踪系统。例如，使用 OpenTelemetry 通过标准 HTTP 头部（如 W3C Trace Context 头部）传播追踪上下文，包括追踪 ID 和跨度 ID。这为调试和性能分析提供了端到端的可见性。
  • 全面日志记录：在客户端和服务器上记录详细信息，包括 taskId、sessionId、关联 ID 和追踪上下文，用于故障排除和审计。
  • 指标：A2A 服务器应公开关键运营指标，如请求率、错误率、任务处理延迟和资源利用率，以实现性能监控、告警和容量规划。
  • 审计：审计重要事件，如任务创建、关键状态更改和智能体操作，特别是涉及敏感数据或高影响操作时。

API 管理和治理

对于暴露在外部、跨组织边界甚至在大型企业内部的 A2A 服务器，强烈建议与 API 管理解决方案集成，因为这提供了：

  • 集中策略执行：一致应用安全策略，如身份验证和授权、速率限制和配额。
  • 流量管理：负载均衡、路由和中介。
  • 分析和报告：深入了解智能体使用情况、性能和趋势。
  • 开发者门户：促进 A2A 启用的智能体的发现，提供 Agent Card 等文档，并简化客户端开发者的入职流程。

通过遵循这些企业级实践，A2A 实现可以在复杂的企业环境中安全、可靠和可管理地部署。这培养了信任并实现了可扩展的智能体间协作。