一个智能体任务刚开始时拿到的授权，可能在任务结束前就已经不适用了。这是智能体权限设计里最容易被忽略的一环：授权不是起跑线上的一次性动作，而是贯穿执行过程的持续判断。

设想一个智能体被批准去排查生产环境问题。执行过程中，它发现了一份新文档、调用了另一个工具，或者调整了自己的计划。每一次新发现，都可能扩大它实际能做的事情范围。原本的授权，已经覆盖不住这些新动作。

更具体的例子是准备一次生产配置变更。智能体可以被允许读取相关日志、比对配置文件、起草一份变更方案。但它不应该因此自动获得部署这次变更的权限。

部署这一步的风险性质完全不同：它影响的是另一个资源，调用的是另一个工具，可能需要另一层级的人工责任。把部署当成最初那次批准的一部分，就会在用户授权的内容和智能体最终执行的内容之间留下缺口。

运行时的授权判断，应当评估这几项：

  • 智能体身份
  • 发起请求的用户
  • 正在调用的工具
  • 正在访问的资源
  • 当前上下文
  • 智能体试图执行的动作

判断结果可以是允许、拒绝，或者挂起等待批准。关键在于时机：检查要发生在每一个有意义的转换节点上，而不只是任务开始时。

计划变更就是控制点

智能体并不总是沿着最初的计划走。一个新文件可能暴露出某个依赖关系；一个工具返回的数据可能指向更有效的做法；用户也可能在原定范围已经改变之后，要求智能体继续。这种计划变更，应当触发一次新的授权判断。

回到生产配置那个例子，流程大致是这样：

  1. 智能体读取已获批准的操作数据。
  2. 智能体起草配置变更。
  3. 智能体请求部署权限。
  4. 策略评估这个新动作。
  5. 动作被拦截，或转交人工批准。

智能体依然可以有用，而不必拿到不受限制的权限。它可以完成分析、把工作准备好，同时让风险更高的动作保持边界。

一个实用的采购测试

直接要求对方演示：当智能体从读取转向修改时会发生什么。然后追问几个问题：策略是否在运行时评估动作？能否区分起草和执行？智能体的计划发生变化时会怎样？批准是否绑定到具体的动作和资源？决策的理由是否被记录下来？

如果得到的回答只有一句“用户批准了这个任务”，那这项控制大概率过于宽泛。对智能体来说，授权不是执行开始时打的一个勾，而是关于下一个动作在当前上下文中是否成立的持续判断。