当 AI 开始拥有权力 — 知谱 Spectra

AI Native Company #03：从 Permission 到 Authority

在这个系列的前两篇里，我们从两个方向讨论 AI Native Company。第一篇谈 Zone：与其一次改造整个公司，不如先创造一个 AI 可以真正参与工作的区域。第二篇继续往前，讨论如何把散落在人、文档和流程里的组织知识，变成 AI 可以理解、调用和持续学习的能力。

当这两件事逐渐具备，一个更现实的问题就出现了：如果 AI 已经知道该怎么做，我们准备让它做主到什么程度？

Agent 已经从回答问题走向调用数据库、API 和业务系统，也开始调用其他 Agent。与此同时，Agent Runtime、Subagent、Orchestration 这些曾经需要开发团队自己搭建的能力，正在迅速被工程化和封装。对企业来说，技术实现可能越来越不可见，留下来的问题开始接近组织本身：谁可以代表公司采取行动，谁有权作出决定，这种权力又可以向下传递到哪里。

会做，不等于有权做

假设公司部署了一个 Procurement Agent。它可以读取历史采购数据，搜索供应商，比较报价和交付记录，最后推荐一家供应商。这首先是 Capability。

如果允许它进入 ERP、供应商数据库和合同库，这是 Permission。但如果它可以淘汰一家供应商、批准 50 万日元采购，或者代表公司确认订单，事情就不同了。这些分别涉及 Decision Authority、Approval Authority 和 Commitment Authority。

从系统角度看，它们最后可能都是一次 API Call；从公司角度看，却属于完全不同的权力。

传统 IAM 很擅长回答 Who can access what。Agent 还需要企业回答：Who can decide what, on whose behalf, within what boundary。

这也是为什么即使 Agent 沿用员工身份，也不能把账号已有的权限直接当作当前任务的授权范围。员工账号背后隐含着很多软件系统没有记录的东西：这个人知道自己的职责，理解例外情况，知道什么时候应该请示，而且最终能够承担责任。

Agent 的授权因此不能止于“可以访问什么”，还需要明确人究竟把什么决定权委托给了它。

一条新的授权链正在出现

今年 9 月发布的一篇预印本综述 Authorization Architectures for Tool-Using AI Agents，把这个问题整理成了一条 principal hierarchy：

Human → Operator / Deployer → Orchestrator Agent → Sub-agent → Tool

作者提出，一个具有实际后果的 Agent action 至少应该满足三个条件：能够追溯到最初的人类 principal；行动不能超过真正被委托的 authority；事后仍然可以审计和质疑。论文梳理了 89 个主要来源，认为目前能够端到端满足这些条件的公开部署仍然很少。

这里值得关注的是 Delegation。

软件中的委托机制早已存在。Agent 会规划任务、选择工具，还可能把任务继续交给另一个 Agent，让授权关系在运行中变得更复杂。

例如，采购负责人允许 Procurement Agent 在 50 万日元以内，从现有合格供应商中采购标准商品。Procurement Agent 把供应商比较交给 Sourcing Agent，后者又让 Risk Agent 检查交付风险。

这时候，每一层得到的都不应该是上一层的全部权力，而只是完成当前任务需要的那一部分：

Delegated Authority ≤ Received Authority

Procurement Agent 可以采购，不代表 Risk Agent 也可以采购；Procurement Agent 能看到完整报价，也不意味着它调用的每个 Subagent 都需要看到完整报价。任何一层都不应该通过重新组合几个权限，得到上一级从未拥有的权力。

未来企业因此可能同时存在两条授权链：一条从董事会、管理者到员工，另一条从人进入 Agent，再延伸到 Subagent 和 Tool。两条链连接起来的时候，Agent 就真正进入了组织的权力结构。

授权链的概念示意。人的问责职责不等于对具体法律责任归属的判定。点击图片查看大图。

不要从 Agent 出发，从 Job 出发

怎么设计这种 Authority？一些正在把 Agent 推进生产环境的公司，已经提供了可借鉴的思路。

OpenAI 今年推出 Presence 时采用了一个很直接的起点：**每次部署从一个具体的 Job 开始。**比如处理账单问题、保险理赔或者员工 IT 服务。Agent 只获得完成这个 Job 所需要的知识和系统访问，公司规定它可以采取哪些行动、哪些需要审批、什么时候必须转给人。上线以后，再根据真实 session、escalation 和 quality signal 调整 policy 和 evaluation。

这与 OpenAI 的 FDE 模式是一致的。FDE 从 discovery、technical scoping、system design 一直进入 production rollout，最终关注的是 production adoption、workflow impact，以及实际运行产生的 eval feedback。

从这些实践里，可以抽出一个很简单的顺序：

Job → Context → Tools → Authority → Eval

先确定 Agent 承担什么工作，再决定它需要知道什么、能够调用什么、可以独立决定什么，最后通过真实运行判断这些边界是否合适。

这个顺序很重要。企业最终交给 AI 的并不是一组抽象权限，而是一件具体的工作。

Authority 的边界在部署中逐渐调整

公司很难在 Agent 上线第一天就知道最合适的授权边界。

采购 Agent 的自主采购额度应该是 10 万、50 万还是 100 万？哪些供应商可以自主选择？什么风险等级必须交给人？单靠事前设计很难回答。

一种可行的方式是从较小的授权范围开始。

最开始，Agent 负责调查、分析和推荐，人负责决定。经过一段时间运行，如果某类判断持续稳定，就可以允许 Agent 处理部分低风险决定。随着 Eval、异常记录和实际业务结果不断积累，再决定是否扩大它的自主范围；风险发生变化时，也可能保持或收回部分授权。

例如同一个 Procurement Agent，最初可以研究和推荐供应商，但没有采购决定权。之后可能允许它自主处理 10 万日元以内的标准采购；再往后，对特定供应商、特定品类，可以提高到 50 万。

这里可以把 Agent 获得的自主空间理解为一条逐渐移动的 Authority Boundary。

它不需要从 Copilot 一步跳到完全自治。企业每次只放出一小部分决定权，同时观察结果。

这和我们第一篇谈 Zone 的思路其实很接近：先缩小范围，再从真实运行中学习。

边界还要真正管得住

组织规定了一条边界，还需要系统在执行时检查并拒绝越界的操作。

Palantir 的 AI FDE 提供了一个具体例子。AI FDE 在用户现有身份和权限下工作，只读操作可以自动执行；修改 Ontology、发布应用等敏感操作默认需要明确批准。在 feature branch 上允许自动完成的一些修改，到了 protected branch 又重新需要 approval，所有操作同时进入既有的 audit log。

Palantir 的 pro-code Agent 又让 Agent 对 Ontology SDK、Ontology MCP 和 Palantir MCP 默认使用 scoped permissions，避免开发者直接把 client ID 和 secret 交给 Agent。

这里提供了一个很实用的原则：授权边界应该落实到独立于 Agent 判断的执行层。

Prompt 里写“不要修改生产数据”当然有用，但真正可靠的是系统根本不给这个 Agent 修改 production 的 authority。

于是前面的过程可以闭合起来：

Job → Authority Boundary → Runtime Enforcement → Audit / Eval → 调整 Boundary

先给 Agent 一小块自主空间，系统负责守住边界；运行结果、异常和升级记录再成为下一轮调整的依据。

这样，Authority 就不是上线前配置一次、以后不再变化的权限表，而是随着实际表现逐步调整的工作边界。

当 Agent 开始把工作交给 Agent

单个 Agent 到这里还比较容易管理。Multi-Agent 出现以后，Delegation 才真正变得棘手。

Procurement Agent 可以把供应商调查交给 Research Agent，把风险判断交给 Risk Agent，把合同检查交给 Legal Agent。但它显然不应该把自己的完整权限复制给这三个 Agent。

更合理的方式是，一项 Job 进入系统时带着明确的授权边界；Job 被拆成 Task 后，每个 Task 只带走完成它所需要的那部分 Authority。

可以把一次 Delegation 简化成四样东西：

Task + Context + Authority + Trace

Risk Agent 得到风险评估任务、必要的供应商资料和读取权限，但拿不到采购权；Legal Agent 可以读取合同并提出修改，却不能代表公司签署合同。Agent 继续拆分任务时，同样遵守这个原则。

这也是 Delegated Authority ≤ Received Authority 真正落到企业系统里的样子。

Multi-Agent 架构图以后可能很容易画。真正困难的那张图，是每个 Agent 为什么获得这项权力，它从哪里来，又能继续传到哪里。

工作与授权交接的概念插图。点击图片查看大图。

权力交出去以后

走到这里，第三篇真正想讨论的问题其实已经比较具体了。

企业采用 Agent，并不只是部署一种新的软件。随着 Agent 从建议走向行动，企业需要建立一种过去很少面对的能力：把原本属于人的一部分决定权，有边界地交给机器，并根据实际结果决定是否继续放权。

这件事至少包含三个动作。

先从具体 Job 开始，明确 Agent 可以决定什么；再用 Runtime 真正守住这条边界；最后通过 Eval、异常和业务结果，决定边界扩大、保持还是收回。

如果 Agent 继续把工作交给其他 Agent，还要保证 Authority 随任务向下传递时只会收窄，不会膨胀，并且整条 Delegation 留下可追溯的记录。

这已经不太像传统意义上的“权限配置”了。它更接近一种新的管理工作。

而它最终会碰到一个具体的问题。

假设 Procurement Agent 最初只能推荐供应商。半年运行后表现稳定，公司把它的自主采购额度从 10 万提高到了 50 万。某一天，它选择了一家供应商，并把风险评估委托给 Risk Agent。Risk Agent 判断错误，但整个过程都符合公司的既定规则：没有越权，没有绕过审批，Audit Trail 也完整保留。

这笔交易连同后续影响，最终给公司造成了 300 万日元损失。

这时再说“AI 做错了”，其实已经解释不了多少。

更值得追问的是：当初是谁决定把这部分决定权交出去，又依据什么认为这条边界已经可以向前移动？

如果错误来自被委任的 Risk Agent，问题还会再往前一步：

权力可以沿着 Delegation Chain 向下传递，责任呢？

组织已经发展出一整套把权力从董事会、CEO、Manager 向员工委托的方法。当 Agent 继续拆分和委托任务时，这条链也会在机器之间延伸。

我们开始知道怎样把权力交给 AI。接下来要弄清楚的，是责任该留在哪里。

本文三张配图均为 AI 生成的概念插图，并非企业实际工作场景。