授予工具≠批准所有操作：AI Agent 权限控制的三个关键层级

给 AI Agent 接入一个工具，和批准这个工具能做的每一件事，是两码事。Cisco 总裁兼首席产品官 Jeetu Patel 在 Chain of Thought 播客第 67 期中把这层区别讲得很直白：你可以给 Agent 邮箱访问权，让它帮你订餐厅，但这不等于它可以随手给董事会成员发消息。

这套主张的核心可以拆成三块：动作级授权、运行时边界监控、以及自建评测体系。三块缺一块，Agent 就会从「帮手」变成「风险」。

工具授权和动作授权不是一回事

工具授权回答的是「这个 Agent 能不能用这个集成」，动作检查回答的是「它具体能做什么、对谁做」。Patel 用邮箱场景把两者切开：同样一条邮箱连接,「订晚餐」和「联系董事会」是两个完全不同的动作，需要分别审批。

你不能只对 Agent 做访问控制，你必须做动作控制。你想给 Agent 发邮件的权限、访问你收件箱的权限，但你不希望给它一张空白支票。你希望它说：你可以出去帮我订个晚餐餐厅。但你不能做的是联系我的董事会，然后开始随机给他们发消息。

—— Jeetu Patel, Cisco 总裁兼首席产品官, Chain of Thought 第 67 期

落到工程实现上，Patel 建议把每个敏感决策存成「工具、动作、目标类别」的三元组。("inbox", "reserve", "restaurant") 和 ("inbox", "message", "board") 需要走不同的审批路径。任何没被预先批准的三元组，都应该在调用前被拦截。

关键是这层允许列表必须放在模型外面强制执行，再配一套运行时意图校验。Patel 的判断是：Agent 太聪明了，静态规则很快就会被绕过。边界条件必须在运行时根据「当前行为是否偏离原始意图」动态计算，一旦漂移就拦截。

「工具、动作、目标类别」三元组的设计思路类似访问控制领域里常见的 ABAC（基于属性的访问控制）模型。在传统安全体系里，RBAC 只回答「谁有什么角色可以调什么接口」，而 ABAC 会把资源、动作、环境属性一起纳入判断，从而支持类似「财务角色可以对金额小于一万元的转账执行发起操作」这种细粒度规则。Agent 场景下，目标类别就相当于资源属性的一种粗粒度切分。把审批粒度从「集成」下沉到「三元组」，本质上是把 Agent 当成一个可能被提示注入劫持的不可信调用方来对待。

另一个容易混淆的概念是「允许列表」与「意图校验」的分工。允许列表负责静态拦截已知越界组合，属于白名单;意图校验负责捕捉允许列表未覆盖的新出口，属于动态异常检测。两者叠加才能覆盖 Patel 所说的「Agent 太聪明，静态规则会被绕过」这一问题。

动作监督与 Token 监控要一起做

拦截只是第一层。Patel 把 Token 消耗监控和系统韧性、护栏越界放在同一个监控层级——也就是说，Agent 的「经济行为」要和它的「行为边界」同等对待。

第三，你必须确保你在监控 Token 经济，这些 Agent 在 Token 使用模式上不能过度消耗。

—— Jeetu Patel, Chain of Thought 第 67 期

Cisco 的做法有阶段性：先给员工宽松的 Token 访问权限让大家熟悉，然后转向按人头配额一样的 Token 配给制——一个团队拿多少 Token，就要交付对应的产出。Patel 提到的下一个问题是架构层面的：怎么在同样成本下，把 Token 产出效率提升 20% 到 60%。

实现上可以用一个检查函数把多个决策点收拢：先校验参数合法性，再检查 Agent 是否已被隔离，再判断本次调用会不会让 Token 用量超出预算，最后才比对 allowed_actions 三元组。Token 预算超限时直接把 Agent 标记为隔离状态，后续调用全部阻断，直到有人工解除。

def check_action(agent, tool, action, target_class, tokens_needed):
    if agent.quarantined:
        return "blocked"
    if agent.tokens_used + tokens_needed > agent.token_budget:
        agent.quarantined = True
        return "quarantine"
    key = (tool, action, target_class)
    if key not in agent.allowed_actions:
        return "intercept"
    agent.tokens_used += tokens_needed
    return "allow"

allowed_actions 存的是已批准的三元组。越界 Token 预算直接触发隔离，后续调用停摆直到人工放行。同时把实时动作和任务原始意图持续比对，一旦分叉就拦截——Patel 反复强调的正是这一点：设在部署时的静态规则，Agent 会绕着走。

Token 预算与隔离机制在工程上对应的是「熔断」与「限流」两种模式。熔断针对的是异常，比如某次调用触发了越界动作，就切断该 Agent 的后续能力;限流针对的是量，比如 Token 使用速率或总量超过配额。把 Token 超限直接触发隔离而不是简单拒绝本次调用，是因为持续超额往往意味着任务目标本身偏离了预期规划，单次拒绝无法阻止它继续尝试。

Patel 提到的「同成本下提升 20% 到 60% Token 产出效率」，本质上属于推理效率优化问题，常见手段包括 prompt 压缩、缓存复用、把小任务路由到更小的模型、以及减少不必要的工具调用往返。这一指标的意义在于，Token 成本不是单纯的财务问题——在算力受限的环境里，节省 Token 等于把推理容量释放给其他任务。

在路由模型之前先自建评测

公开榜单上的高分，不代表模型在你的场景里表现好。它只说明模型在榜单测量的那些行为上做得好。Patel 的建议顺序是：先围绕你自己的任务建评测，再用评测结果决定一个 prompt 该发给便宜模型还是贵模型。

你的基准和评测不会告诉你完整的故事，这是大多数人没意识到的另一件事。一个模型在一个评测上表现好，不代表它在你的环境里也会表现好。它只意味着在那个评测所测量的、那组特定行为上表现好。

—— Jeetu Patel, Chain of Thought 第 67 期

Patel 对「成本」的定义也值得记下：不只是 Token 的美元价格，还包括它消耗的瓦数——有钱但没电的情况是可能发生的。他提到当前可用的总算力中，60% 正投向推理。每个任务要写清楚三个维度的取舍：智能、成本、控制。在控制更重要的任务上（比如敏感数据），最后 5% 的智能可能没那么重要。

人工审批环节要保留到用例积累出可信记录为止。Patel 的版本是：一直保留人工批准，直到模型对你的环境微调得足够好，你对它的决策有足够的统计样本感到放心，才考虑把人从回路里拿掉。这个临界点因用例、因组织而异，也因任务复杂度而异。

「模型路由」指的是在同一个系统里准备多个不同价位、不同能力的模型，根据任务类型、敏感度、预算把每个 prompt 分派给最合适的那一个。路由决策依赖两个信号：任务的重要程度，以及任务在候选模型上的历史表现。公开榜单无法提供后者，因为它测的是通用能力，而你的任务分布是特定窄域。

Patel 强调的「智能、成本、控制」三维取舍，对应的是评测集设计上的分层。智能维度可以用正确率、完成度衡量;成本维度包含 Token 价格与功耗;控制维度则要看模型在敏感操作上是否稳定遵守约束、是否容易被诱导越界。对敏感数据类任务，控制权重应调高，此时哪怕选用便宜模型牺牲少量智能也可能是划算的。人工审批的保留期，本质上是在等待评测样本量达到统计显著，让决策不再依赖对模型的直觉信任。

常见问题

给 Agent 接了邮箱，它就能随便发消息了吗？ 连接只是工具授权。Patel 把订晚餐和联系董事会分开处理，同一收件箱上这两个动作需要各自的动作检查。

公开基准能告诉我该路由到哪个模型吗？ 它报告的是模型在那个评测行为上的表现。Patel 认为这不能证明它在你的环境中的表现。先为你的用例建评测，再路由。

Agent 烧 Token 或越界了该怎么办？ 拦截越界的那次动作。如果 Token 使用过度消耗，隔离该 Agent，让它先「冷静」下来。

要点回顾

• 把敏感调用按「工具、动作、目标类别」建键，未批准的组合一律拦截。
• 给每个 Agent 设 Token 预算，超预算即隔离。
• 运行时对照原始意图重算边界检查，同时把授权强制放在模型外面。
• 在便宜和贵模型之间路由 prompt 之前，先在自己的用例上建评测。
• 保留人工审批，直到该用例积累出可信记录。

完整对话（含文字稿）在 Chain of Thought 第 67 期。