过去一年里，AI agent 的讨论很容易滑向两个极端：一端是模型能力崇拜，仿佛模型越强，组织流程就自然变好；另一端是风险恐惧，仿佛只要 agent 会调用工具，就应该被关在聊天窗口里。

这两个判断都不够工程化。

真正的问题不是“agent 能不能干活”，而是“它能不能被放进真实流程里干活”。真实流程有权限、证据、工具、成本、失败恢复、审计、人工责任和发布边界。模型本身不会天然拥有这些东西。

我把这一层称为 AI Agent Operational Governance：AI agent 运行治理。

它不是写一份更长的 policy，也不是再堆一层 prompt。它是一组进入执行路径的约束：agent 在做关键动作前，如何确认权限；在引用事实时，如何携带证据；在选择工具时，如何接受工具注册表治理；在长任务中，如何避免承诺漂移；在失败后，如何恢复到语义上仍然有效的状态。

为什么现在需要这层治理

早期 AI 工具的主要风险是“回答错了”。今天 agent 的风险已经变成“做错了”。

它可能改代码、创建 PR、安装依赖、调用 MCP、写入数据库、发布文章、发送社交媒体内容、处理财务数据，甚至触发真实业务动作。这个变化让治理对象从文本输出扩展到行动轨迹。

在这种场景下，“让模型更聪明”只能解决一部分问题。真正会长期留下来的，是项目或组织如何定义 agent 的运行边界。

一个可用的 agent 系统，至少要回答这些问题：

  • 它当前是否有权做这个动作？
  • 当前动作应该自动执行、请求人工批准，还是直接停止？
  • 它引用的事实来自哪里？
  • 工具描述、权限和副作用是否可信？
  • 任务执行过程中是否偏离了早先承诺？
  • 完成一个目标的总成本、延迟和失败率是多少？
  • 失败后是重试、回滚、人工接管，还是进入事件处理？

如果这些问题都交给模型“自己判断”，那就不是治理，只是把风险包装成了自动化。

运行治理的最小结构

我会把 AI agent 运行治理拆成六个最小部件。

Runtime authority 负责判断 agent 在当前状态下是否仍然有权执行某个动作。计划阶段同意过，不代表执行阶段仍然可以做。

Autonomy gate 把自动化从一个总开关变成逐动作决策：允许、询问人工、阻断或停止。

Evidence contract 要求 agent 的关键判断和副作用动作携带可复核证据，而不是只给一段流畅解释。

Tool registry governance 把 MCP、插件、connector、本地脚本和依赖包都视为控制面的一部分，而不是普通配置。

Commitment tracking 记录长任务里的用户约束、系统承诺和最终产物，避免没有显式矛盾却慢慢漂移。

Trajectory evaluation 评估 agent 的行动过程、恢复能力、成本和不确定性处理，而不是只看最后有没有生成一个结果。

这些部件合在一起，才让 agent 从“会执行任务的模型”变成“可放进流程的受控执行系统”。

这个系列讨论什么

这个系列会围绕五个关键问题展开。

第一，运行时权限和自治门禁。为什么 plan-time approval 不够，关键动作必须在 action-time 重新确认权限。

第二，证据和来源权威。为什么流畅的自然语言解释不能压过结构化数据、工具输出、系统状态和 source evidence。

第三，工具注册表和供应链治理。为什么 agent 看得见的工具描述、MCP server、插件和依赖包，本质上都是运行控制面。

第四，承诺跟踪和长任务漂移。为什么多轮任务即使没有明显矛盾，也可能逐步偏离最初约束。

第五，轨迹、成本和恢复。为什么评估 agent workflow 不能只看最终成功率，还要看执行轨迹、goal-level cost、semantic recovery 和 confidence calibration。

一个边界说明

这个系列不是一套完成的行业标准，也不是声称某篇论文已经给出了终局答案。它来自三个来源：真实项目里的 agent 使用经验、中央知识库中持续整理的外部研究信号，以及对 AI 工程流程的抽象。

其中不少外部材料是论文摘要、产品发布、工程实践和 RSS intelligence 层面的信号。它们的价值是提示方向，不是替代验证。

核心判断很简单：

AI agency grows faster than organizational control.

如果组织只升级模型，不升级运行治理，agent 越能干，风险边界就越模糊。真正应该沉淀的，不是某个 prompt，而是项目如何约束、验证、记录、恢复和升级 agent 的执行。