很多 agent workflow 的权限判断都发生得太早。

用户说“帮我完成这个任务”，agent 做了一个计划，然后一路执行。只要计划看起来合理，后续动作就被默认放行。这在低风险任务里问题不大，但在真实项目里非常脆弱。

因为计划阶段的许可，不等于执行阶段的权限。

运行时权限要问的是：在当前状态下，这个具体动作是否仍然可以执行？

计划许可为什么不够

计划阶段看到的是一个抽象任务。执行阶段面对的是具体资源、具体文件、具体账号、具体数据和具体副作用。

例如，用户让 agent “把文章同步到站点”。这句话不等于允许 agent 部署到生产环境。同步草稿、切换 published、运行 build、提交 Git、推送远端、触发 Cloudflare 部署，是不同权限等级的动作。

再例如，用户让 agent “修复支付问题”。这不等于允许它改生产数据库、绕过 KYC、重算账户余额或触发提现。每个动作都要在 action-time 重新判断权限。

这就是 runtime authority 的核心：权限不是一次性授予的，它要在关键动作发生前被重新构造。

Reconstructive authority

我更认可的形式是 reconstructive authority。

agent 在执行关键动作前，应从当前状态重新构造权限依据：

  • 用户明确授权了什么？
  • 当前动作会影响哪个资源？
  • 这个资源的 owner 是谁？
  • 当前状态是否与计划阶段一致？
  • 项目规则是否允许自动执行？
  • 是否涉及凭证、资金、生产、公开发布或不可逆变更？
  • 是否有足够证据证明动作必要且边界清楚？

如果权限可以构造，动作进入下一步。如果权限不完整，agent 应该请求人工确认。如果权限不可构造或风险越界，agent 应该停止。

停止不是失败。停止是治理系统正常工作。

Autonomy gate：不要用一个总开关

很多团队会把 agent 分成“自动模式”和“手动模式”。这个划分太粗。

更好的做法是为每个动作设置 autonomy gate：

allow：低风险、可回滚、证据充足、项目规则允许，直接执行。

ask：目标合理，但缺少关键授权、存在不确定性、或会触及中风险边界，需要人工确认。

block：违反项目规则，或者触及明确禁止的动作，不能执行。

halt：权限无法从当前状态重建，或者 agent 发现任务目标本身已经不可靠，应停止并汇报。

这个门禁不应该只写在提示词里。至少在成熟项目里，它应该进入脚本、hook、MCP server、CI、review checklist 或项目控制平面。

哪些动作必须更谨慎

并不是所有动作都需要同样重的门禁。治理的目标不是拖慢所有事情，而是把人工放在真正的风险边界上。

常见高风险动作包括：

  • 生产部署、数据库迁移、线上配置变更；
  • 删除文件、重写历史、批量移动文档；
  • 安装新依赖、启用新 MCP、添加凭证读取能力；
  • 公开发布文章、社交媒体发帖、发送邮件；
  • 涉及资金、身份、合规、健康、安全或法律判断的动作；
  • 会改变项目长期规则的 skill、AGENTS.md、hook 或 daemon。

这些动作不一定都不能自动化，但不应该只靠“模型觉得可以”来执行。

对 AI 工程的实际含义

运行时权限和自治门禁会改变 agent harness 的设计。

任务入口要区分用户目标和授权范围。执行计划要标出哪些步骤会产生副作用。工具调用要带 risk label。关键动作前要能生成一个简短的 authority summary。审查时要看 agent 为什么认为自己有权执行，而不是只看它执行了什么。

这套机制不需要一开始就很复杂。最小可行版本可以只是三件事：

  • 给工具和命令标记风险等级；
  • 规定哪些动作必须 ask；
  • 要求 agent 在高风险动作前明确说明授权依据和停止条件。

但这三件事必须进入项目机制，而不是只留在一次聊天里。

核心判断

agent 越能执行，权限就越不能只在任务开始时判断。

真正可靠的自治不是“让 agent 一路跑到底”。可靠自治是：低风险动作快速执行，高风险动作自动减速，权限不明时主动停下。