Skip to main content

A2A 的企业级实施

智能体到智能体（A2A）协议在设计时将企业需求作为核心。A2A 不是发明新的专有安全和运营标准，而是旨在与现有企业基础设施和广泛采用的最佳实践无缝集成。这种方法允许组织利用其在安全性、监控、治理和身份管理方面的现有投资和专业知识。

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

传输层安全（TLS）​

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

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

身份验证​

A2A 将身份验证委托给标准的 Web 机制。它主要依赖于 HTTP 标头和已建立的标准，如 OAuth2 和 OpenID Connect。身份验证要求由 A2A 服务器在其智能体卡片中公布。

  • 有效载荷中无身份信息：A2A 协议有效载荷（例如 JSON-RPC 消息）不直接携带用户或客户端身份信息。身份在传输/HTTP 层建立。
  • 智能体卡片声明：A2A 服务器的智能体卡片在其 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 服务器负责授权请求。授权逻辑特定于智能体的实现、它处理的数据和适用的企业策略。

  • 细粒度控制：授权应该基于经过身份验证的身份应用，该身份可以代表最终用户、客户端应用程序或两者。
  • 基于技能的授权：可以根据智能体卡片中公布的每个技能来控制访问。例如，特定的 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 启用的智能体的发现，提供文档（例如智能体卡片），并简化客户端开发者的入门流程。

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