AI Agent 的“身份证“：从 Uber 的实践看 Skill 权限治理的下一个战场
2026 年 6 月，Uber 工程师团队公开了一篇技术博文，描述了他们解决"Agent 身份危机"的内部架构。这篇发表于 InfoQ 的文章在国内技术社区引发了不小的讨论——不是因为 Uber 提出了什么石破天惊的新理论，而是因为它把一个长期被忽视的问题摆到了台面上：当 Agent 开始代表人类执行多步任务、调用内部工具、委托其他 Agent 干活时，它到底是谁？
这不是一个哲学问题。它的工程含义非常具体：当 Agent A 调用 Agent B，再由 Agent B 通过 MCP 网关查询生产数据库时，授权决策应该基于"Agent B 要查数据库"，还是应该追溯到"最初是某位值班工程师让 Agent A 去调查一个问题"？Uber 的选择是后者，而支撑这个选择的技术方案，恰好为我们打开了 Skill 权限治理的思考入口。
一、问题出在哪：Agent 不是人，也不是服务
Auth0 的 Cameron Pavey 在一篇文章中精准地指出了困境的根源：AI Agent 无法完美地融入为人类用户或后端服务构建的访问控制模型。 用户受会话和 UI 约束，后端服务是确定性的、可以通过静态代码路径审计。但 Agent 不同——它会自主规划步骤、调用工具、将子任务委派给其他 Agent，整个过程既不是"用户亲自点的按钮"，也不是"一段预编译好的代码路径"。
Uber 遇到的就是这个问题的生产级版本。当他们内部的 Agent 数量膨胀到数千个，且开始出现"值班 Agent 委托调查 Agent，调查 Agent 再调用内部工具"的多跳工作流时，传统的服务账户或 OAuth 权限范围已经无法满足要求——它们只能告诉你"谁在调用"，无法回答"谁最初发起、中间经过了哪些 Agent、每一步在什么权限下执行"。
让问题更复杂的是一层容易被忽略的维度：Agent 的能力本身——也就是它加载的那些 Skill——应该如何纳入权限体系？ 一个 Agent 在被创建时可能只是一个无伤大雅的聊天助手，但一旦加载了对生产数据库的查询 Skill，它的"身份"在功能意义上已经发生了变化。如果权限只绑定到 Agent 而不绑定到 Skill，就等于对一个拿到了武器的人只检查身份证而不检查持枪证。
二、Uber 的方案：给每个 Agent 一张"临时身份证"
Uber 的架构核心可以概括为四个组件和一个关键概念。
Agent 注册表存储了 Agent 与其被允许托管的工作负载之间的关联关系。**安全令牌服务（STS）**在验证注册表中的关联后，为工作流中的每一个跳点签发短效 JWT。MCP 网关负责协调 Agent 网格对内部系统的访问，执行工具访问检查，并在必要时对敏感数据脱敏。AI 网关/AI 守护程序则在更外层提供策略执行点。
关键概念是"参与者链"（Participant Chain）。在一个多跳调查场景中，值班工程师要求值班 Agent 调查问题→值班 Agent 委派调查 Agent→调查 Agent 通过 MCP 网关调用内部工具，提交给网关的令牌中不仅包含直接调用者的身份，还携带了完整的参与者链声明。下游系统在做授权决策时，可以同时看到"发起请求的人是谁"和"执行操作的 Agent 是谁"——这在传统的单层 OAuth 模型中是完全不可见的。
技术实现上，Uber 不依赖单一的用户凭证或长期有效的服务账户，而是让每个 Agent 利用 SPIRE 签发的工作负载身份向 STS 请求新的令牌。生成的令牌为单跳、短效，TTL 以分钟计，包含特定的受众声明。Uber 表示，该系统的令牌交换 API 的 P99 延迟始终低于 40 毫秒，已经被数千个内部 Agent 采用。
Auth0 提出的框架与 Uber 的实现形成互补：基于能力的权限（一个 Agent 能做什么由它拥有的 Skill 和能力声明决定）、基于任务的凭证（每次任务分配时签发范围限定的临时凭证）、分层执行（网关层、工具层、数据层各有独立的策略检查点）。这三个模式的共同目标，是限制 Agent 出错后的影响范围，同时又不削弱让 Agent 具备实用价值的自主决策能力。
三、Skill 容器化：为什么"管身份"必须延伸到"管能力"
Uber 和 Auth0 的讨论主要聚焦在 Agent 的运行时身份传播上，这解决了一个核心问题：一个正在运行的 Agent，以什么身份、在什么边界内执行操作。 但这张拼图还缺了另一块：Agent 加载了什么 Skill？这些 Skill 本身的权限应该怎么管？
这个维度的缺失不是一个边缘问题。现实中的场景是：同一个 Agent 实例在不同任务中可能加载不同的 Skill 组合。一个 SA-Master Agent 在处理金融系统架构时需要访问合规审查 Skill，在处理内部管理系统时则不需要。如果权限模型只按"Agent 是谁"做判断，它无法区分"SA-Master 在处理金融项目时调用了风控 Skill"和"SA-Master 在处理内部 OA 时调用了风控 Skill"的区别——后者显然应该是被禁止的。
这就需要一种能力：将 Skill 本身作为一个可被权限策略引用的实体。 在 Agent Skill Warehouse 的实践中，每个 Skillset——无论是 BA-Master 的需求规格说明书生成、SA-Master 的架构确认，还是 PM-Master 的跨角色编排——都被设计为一个具有明确边界的能力容器。这个"容器化"不是 Docker 意义上的容器，而是工程意义上的封装：每个 Skill 有独立的指令层（定义触发条件）、知识层（提供执行上下文）、执行层（脚本化的确定性校验）和评测层（对照测试闭合质量反馈）。
这种四层结构天然地为权限管理提供了锚点。指令层决定了 Skill 在什么场景下被激活——这个激活条件本身就可以成为一道权限门禁。知识层加载的领域文档和规范清单意味着 Skill 会接触到哪些信息——这决定了 Skill 的"数据访问级别"。执行层的脚本明确了 Skill 会执行什么操作——这是审计追踪的天然切入点。评测层的对照测试结果则是判断 Skill 是否在预期边界内运行的基准线。
当这四个层次被明确定义并版本化管理后，权限策略就不再是"Agent X 能不能做 Y"的粗粒度问题，而是可以细化到"Agent X 在项目 P 中加载 Skill S 执行操作 O，其参与者链是否可追溯、其操作范围是否在 Skill 的声明边界内"。
四、实践：从"谁能用 Agent"到"Skill 能用什么"
把这个思路落到实处，需要三个层面的工程实践。
第一，Skill 的身份注册。 就像 Uber 的 Agent 注册表存储了 Agent 与工作负载的关联，一个 Skill 注册中心应该存储 Skill 的声明边界——它需要访问哪些系统、它会执行哪类操作、它的预期输入输出是什么。这不是文档性的描述，而是机器可读的策略声明。当 Agent 请求加载一个 Skill 时，网关可以基于这个声明自动判断：当前 Agent 的身份、当前任务的上下文、当前 Skill 的能力声明，三者是否匹配。
第二，Skill 级权限的逐级传播。 Uber 的"参与者链"概念在 Skill 层面同样适用。当一个 Agent 通过 Skill A 调用 Skill B 时——例如 BA-Master 的需求规格说明书 Skill 触发了合规审查 Skill——授权决策应该能追溯整个链：原始用户 → Agent → Skill A → Skill B。每一层的权限应该逐级收窄，而非逐级放大。一个只读的需求分析 Skill 调用了合规审查 Skill，合规审查 Skill 不应该因此获得写权限。
第三，Skill 执行的审计闭环。 这可能是三者中最重要的实践。Uber 的方案确保了他们能回答"谁在什么权限下做了什么操作"，但真正让治理形成闭环的，是能够在事后验证"操作是否在 Skill 的声明边界内"。这要求每个 Skill 的执行轨迹被记录、可回放，并且与 Skill 的声明边界做自动化比对——就像一个持续运行的"权限一致性检查"，而不是等出了事才去翻日志。
五、从 Identity 到 Capability：治理范式的两个轮子
Uber 和 Auth0 的文章在 InfoQ 上被标注为"约 6 分钟"的阅读时长，但真正值得花时间琢磨的，是它们共同指向的一个范式转移：Agent 治理需要两个轮子同时转——身份传播（Identity Propagation）和能力治理（Capability Governance）。
身份传播解决的是"谁在操作"的问题——Uber 用 Agent 注册表 + STS + 参与者链给出了一个生产级的答案。能力治理解决的是"它能操作什么"的问题——这恰恰是 Agent Skill Warehouse 正在通过 Skill 容器化和权限声明试图填补的空白。
两个轮子缺一个，治理就不完整。有身份治理没能力治理，你知道是哪个 Agent 出了问题，但不知道它是从哪学会了做不该做的事；有能力治理没身份治理，你知道每个 Skill 的边界在哪，但不知道是谁、在什么上下文中触发了越界操作。
Uber 的工程师在文章中透露，他们正在关注 IETF WIMSE 工作组和《AI 智能体身份验证与授权》草案的进展。这暗示了一个趋势：Agent 权限治理正在从各自闭门造车的阶段，进入标准化的前夜。对企业而言，这意味着现在就应该开始构建两个核心能力：一是让每个 Agent 和 Skill 都有可验证的身份，二是让每次操作都在一个可追溯、可审计、可收窄的权限链中执行。
结语
"Agentic Now, Go Build"是 2026 年被反复提及的口号。但当 Agent 开始真正进入生产环境——调用内部 API、访问业务数据、代表员工做决策——治理就不再是可选项。Uber 的实践告诉我们，给 Agent 一张"身份证"只是起点；Agent Skill Warehouse 的实践则进一步表明，真正成熟的治理体系，需要把这张身份证和 Agent 手中的每一件"工具"——每一个 Skill——都纳入同一个权限框架。
下一个战场，不是谁能造出更多 Agent，而是谁能管好 Agent 和 Skill 之间的每一次握手。
参考资料：
中国智能体开发者社区，聚焦智能体与大模型开发，提供前沿资讯、实用工具链、开源项目及行业案例。通过技术沙龙、开发者大赛等活动，促进经验交流与协作，助力开发者快速构建创新智能应用。
更多推荐
4
0- 0
已为社区贡献1条内容
所有评论(0)