切换深色模式
六家大厂的 Agent 身份方案：比较与认证系统设计
整理日期：2026-10-05。这里的“智能体方案”承接前文，专指 Agent 身份认证与接入架构，不做模型性能、编排框架或价格排名。本轮覆盖 Google、Microsoft、AWS、阿里云、火山引擎和腾讯云；不是整个互联网厂商的穷举。六篇均配有 imagegen 生成的独立框架图，并展开请求时序、身份契约、缓存、撤销和失败处理。
统一前提：本系统证明谁在调用、代表谁、凭什么可信；项目决定允许做什么。 各篇都区分官方事实、本系统设计和未实测的上线条件。
1. 分篇导航
| 厂商文档 | 重点 | 适合解决的问题 |
|---|---|---|
| 托管工作负载、外部 OIDC、本地登录与应用证明的区别 | 理解运行身份和来源证明边界 | |
| Microsoft | Blueprint、Agent identity、OBO、主体与 actor | 企业目录及用户委托链 |
| AWS | Runtime 入站、WAT、出站凭证、会话绑定 | 托管 Agent 的入站与出站分段 |
| 阿里云 | RAM、OIDC、工作负载与凭证保险箱 | 同时校验运行方和用户 |
| 火山引擎 | 工作负载池、信任锚、身份传递 | 外部沙箱与工作负载信任建立 |
| 腾讯云 | API/MCP 网关认证、JWT 或远程验证 | 在现有身份系统前后部署认证入口 |
每篇附有官方原始资料链接。Google 篇保留 2026-10-04 的核对日期，新增五篇于 2026-10-05 核对。研究不等于已开通服务，文档中未实测的项目不得作为生产保证。
2. 关键差异
以下为基于各分篇证据的工程分析，不能将不同产品对象视为兼容协议。
| 问题 | Microsoft | AWS | 阿里云 | 火山引擎 | 腾讯云本轮资料 | |
|---|---|---|---|---|---|---|
| 核心切入点 | 托管运行身份 | 企业 Agent 目录 | Runtime 与凭证服务 | 工作负载与凭证管理 | 身份池与信任锚 | 认证网关 |
| 用户与 Agent | 分开建立关联 | subject 与 actor 可区分 | 用户与工作负载绑定 | 用户与工作负载绑定 | 用户上下文与工作负载 | 由身份源及适配器表达 |
| 本地软件来源 | 需适用平台证明 | 登录不证明二进制 | 登录不证明二进制 | 登录不证明二进制 | 登录不证明二进制 | 登录不证明二进制 |
| 凭证的主要陷阱 | 外部 bearer 不继承内部证书绑定 | Agent user 不等于人类 | WAT 只用于第一方服务 | WAT 不透明，不能通用验签 | 需确认接收方验证契约 | 验签还须核实 audience |
| 本系统需补齐 | 本地 Broker/映射 | 公共客户端入口/映射 | 项目身份出口 | 项目身份出口 | 外部接收方契约 | 沙箱身份与可信转发 |
证据：Google 官方机制及边界、Microsoft 资料、AWS 资料、阿里云资料、火山资料、腾讯资料。
3. 建议采用的统一框架
下面是本系统设计，不声称任一厂商原生提供全部模块：
图由 imagegen 生成。厂商能力按各自协议接入，不表示六家提供兼容的统一身份 API。六篇各有独立框架图，原始 PNG 和生成提示词保存在项目的 docs/public/images/agent-identity/。
一次正常的用户登录，不应同时隐含“官方客户端”“可信沙箱”“当前用户已批准所有操作”三个额外结论。每个事实必须有独立证据。
4. 最小身份契约与数据模型
以下为本系统设计。建议登记表分别保存外部主体映射、Agent、实例密钥、用户关联会话和信任配置版本。绑定记录要带创建方式、有效期和撤销状态，不能只保存一个永久的 agent.user_id。
项目凭证中的示例业务字段如下。实际 JWT 还必须带 iss、sub、aud、iat、exp 等协议字段并由可信签发方签名；这段 JSON 本身不是凭证。
json
{
"subject_kind": "user",
"user_id": "u_123",
"actor_id": "agent_456",
"instance_id": null,
"provider": "enterprise-oidc",
"software_origin": "unverified",
"authentication_methods": ["oidc"],
"session_id": "session_789"
}instance_id=null 表示没有独立实例证据。自主任务的 subject_kind 应是工作负载，user_id 为空。不同厂商的用户账户、应用对象和工作负载不能仅按同名字段直接合并。
对尚未建立的软件来源证明，不从客户端登记名推导。需要持钥绑定时，在支持的协议中绑定公钥并验证每次证明；普通 bearer 路径明确保留 bearer 属性。
5. 认证系统与项目的职责
| 工作 | 负责方 |
|---|---|
| 验证用户、运行方、实例证据及其关联 | 认证系统 |
| 凭证签发、刷新、受众限制和会话撤销 | 认证系统 |
| 验证本项目收到的凭证 | 项目中间件，可复用公共库 |
| 是否允许第三方 Agent、访问哪些资源 | 项目 |
| 退款限额、工具权限、审批和数据范围 | 项目 |
| 厂商身份服务的管理和调用权限 | 平台运维按最小权限配置 |
“只做认证”不意味着签发方没有任何准入和管理规则；它意味着不集中管理业务项目的资源策略。
6. 落地步骤与验收范围
- 先落地通用用户登录、项目凭证和严格验签，完成本地公司/第三方 Agent 接入。
- 加入一种实际使用的沙箱平台，验证工作负载身份与用户上下文分离。
- 建立撤销、密钥轮换和审计链路；项目验证错误受众、伪造身份头及跨用户调用。
- 项目确有需求时，再接厂商的出站凭证服务、委托协议或应用证明。
各厂商篇给出 6 项真实环境验收，共 30 项；Google 保留原有 14 项。它们都仍为未实测。此次交付是官方资料调研与实施设计，验证结果见 文档验证记录。
对当前需求，建议先稳定这套厂商无关的认证契约，然后根据实际部署平台选择适配器。无需为了使用 Agent 名称而一次性引入六家身份服务。