AI Agent 真正进项目以后，最难的不是执行，而是治理

这几天 AI Agent 相关的信息很多。有论文在讨论生产级 Agent 的运行时治理有项目在把本地记忆做成事件日志有新的 coding-agent benchmark 开始把 harness、成本和工作区契约放进评测里OpenAI 官方源里也出现了模型和 Codex 接入企业云承诺、采购体系的信号。如果只看表面会觉得这是又一轮 Agent 热闹更会写代码更会调用工具更会自动推进任务。但我看完这些信息后反而更强烈地感觉到一件事AI Agent 真正进项目以后最难的不是执行是治理。这里的治理不是写一份原则文档也不是在 prompt 里加一句“请谨慎操作”。我理解的治理是 Agent 在真实项目里行动时有没有目标边界、权限控制、状态恢复、验证证据和审计记录。没有这些东西Agent 越能执行风险越大。最近几个信号都指向同一个问题先看几个最近三天里比较值得关注的信号。第一类是运行时治理。一篇 2026 年 6 月 10 日提交到 arXiv 的论文讨论的是生产级 AI Agent 的运行时治理架构。它的核心判断很直接传统企业安全主要管数据边界但 Agent 会读取上下文、调用工具、访问连接器、修改系统记录风险已经进入工作流内部。这句话很关键。过去我们更习惯问这个人能不能访问某个数据这个系统能不能调用某个接口但 Agent 带来的问题是每一步看起来都被允许组合起来却可能完成一个没人真正授权过的业务流程。这篇论文提出的 Five-Plane 架构把治理拆到 reasoning、network、identity、endpoint、data 这些不同平面里。其中 reasoning 平面负责裁决意图其余四个 enforcement 平面负责把决策落到网络、身份、终端和数据这些执行边界上。它也明确说自己治理的是 delegated action也就是被委托出去的行动而不是直接治理模型本身。这个边界很重要因为它把问题从“模型听不听话”拉回到了“系统怎么管动作”。第二类是本地记忆和判断层。另一篇 arXiv 论文 PROJECTMEM 把 AI coding agent 的项目记忆做成本地优先、事件溯源的日志系统。它提到一个很现实的问题Agent 每次重新进入项目都要重新读文件、重新推导之前的决策甚至重复已经失败过的调试尝试。论文里给了一个估算重建这些上下文每个 session 可能会消耗 5,000 到 20,000 token。它的做法是把开发过程记录成 append-only 的事件日志再投影成 AI 可读的摘要并在 Agent 行动前提醒它这个修法之前失败过这个文件是脆弱区域不要直接动。这就不是普通的 memory 了。它更像一种轻量治理记忆不只是回答 Agent 的问题而是在 Agent 行动前形成约束。论文还提到这个项目是离线运行、没有遥测包含 14 个 MCP tools、19 个 CLI commands、37 个自动化测试并在 10 个项目、207 条记录上做了两个月自用评估。第三类是评测开始看 harness。Claw-SWE-Bench 这篇论文很有意思。它不是只问“模型能不能修好 issue”而是把 agent harness 也放进评测对象里。论文摘要里提到同一个模型下不同 adapter / harness 的设计会显著影响 coding task 的成绩和成本。这说明一件事Agent 能不能交付不只取决于模型。它的完整 benchmark 包含 350 个 GitHub issue-resolution instances覆盖 8 种语言、43 个仓库Lite 版本是 80 个样本。更关键的是同一个 GLM 5.1 backbone 下OpenClaw 使用 minimal direct-diff adapter 的 Pass1 是 19.1%使用 full adapter 可以到 73.4%。论文还提到模型选择会带来 29.4 个百分点的 Pass1 差异harness 选择也会带来 27.4 个百分点差异。这组数字说明工作区契约、patch 提取、运行预算、评测器、工具链这些工程外壳会直接影响结果。Agent 的能力不是裸模型能力运行环境本身就是能力的一部分。第四类是企业接入。OpenAI 最近也发布了 Oracle 相关信息Oracle 客户可以通过已有 OCI 采购和云承诺访问 OpenAI 模型和 Codex开放会在接下来几周开始。这个信息本身不是技术细节但它说明 AI 编程工具正在进入更正式的企业采购和云治理流程。进入这个阶段以后问题就不只是“个人开发者觉得好不好用”而是权限、审计、成本、合规、数据边界都要被纳入系统。这些信号放在一起看我看到的不是“Agent 又变强了”。我看到的是Agent 正在从工具能力问题变成运行时治理问题。为什么只靠 prompt 管不住 Agent很多人第一次做 Agent会本能地把约束写进 prompt。比如只修改必要文件不要执行危险命令遇到不确定情况先问我完成后说明验证结果。这些要求当然有用但它们只能算软约束。真正进项目以后光靠 prompt 不够。原因很简单prompt 约束的是模型表达和倾向管不住真实世界里的副作用。Agent 一旦能读文件、改代码、跑命令、调接口、访问浏览器、连接数据库它就不再只是“回答问题”。它的每一步都会改变环境或者基于环境做下一步判断。这时候风险经常不是某一个动作本身而是动作之间的组合。读一个配置文件没问题改一个小组件也没问题跑一次脚本也没问题。但如果这几步组合起来让 Agent 绕过了项目原来的权限边界或者修改了不该动的模块那就不是 prompt 能完全兜住的。所以我现在看 Agent不只看它会不会执行。我更看它执行前有没有边界执行中有没有状态执行后有没有证据。运行时治理至少要管五件事如果把最近这些信号落到自己的项目里我会把 Agent 运行时治理拆成五层。这不是照搬某篇论文的架构而是面向个人和项目开发场景做的一套简化拆法。第一层目标和任务边界。Agent 必须知道这次任务到底是什么也要知道这次任务不是什么。比如只做审查不改代码只改一个页面不碰公共组件只生成方案不执行命令。边界不能只写在一句自然语言里最好变成结构化的任务契约目标、可读上下文、可改文件、禁止事项、交付证据以及信息不足时怎么停下来。第二层上下文和记忆。Agent 不能每次都从零理解项目也不能把所有旧信息都塞进上下文。真正有用的是当前任务相关的上下文以及已经被验证过的历史判断。比如某个修法之前失败过某个文件很脆弱某条规则是最新的某个接口不能随便改。这也是 PROJECTMEM 这类方向有价值的地方它提醒我们记忆不只是“让 Agent 记得更多”而是让 Agent 在行动前知道哪些路不该再走。第三层工具和权限。工具能力越强越要分级。搜索、读取、列目录属于低风险只读操作写文件、改配置、生成资源属于有副作用的写入操作执行命令、访问外部系统、操作数据库、触发发布属于高风险动作。这些动作不能只靠模型自己判断。至少要有 allowlist、确认点、沙箱、临时工作区、回滚方式和日志记录。第四层状态和失败恢复。Agent 做长任务时最容易出问题的不是第一步而是中间被打断以后还能不能接上。如果没有状态Agent 只能靠聊天记录恢复。聊天记录长了以后旧结论、失败尝试、已过期约束混在一起很容易带偏。状态应该记录当前目标。已完成节点。正在执行的步骤。阻塞原因。下一步建议。最新验证结果。这样任务中断以后恢复入口不是“往上翻聊天”而是读状态。第五层验证和审计。Agent 不能只说“我完成了”。它要留下证据改了什么、为什么改、跑了什么验证、哪些没验证、哪里失败过、调用了哪些工具、哪些动作需要人工确认。Claw-SWE-Bench 这类评测提醒了一个很重要的点Agent 的结果不能脱离 harness 看。模型、工具、工作区契约、patch 提取、评测器和成本都属于结果的一部分。所以未来我们评估一个 Agent不应该只看它最后答案对不对还要看它是怎么得到这个答案的。这些治理能力普通开发者也需要很多人一听“生产级治理”会觉得这是大公司问题。我反而觉得个人开发者更早会遇到这些问题。因为个人使用 Agent 时很多时候没有完整平台兜底没有企业级权限系统没有统一审计平台没有专门的安全团队也没有完整的评测流水线。所以更需要轻量版本。我自己会从几个很小的动作开始。第一先把任务写成契约。不要只说“帮我改一下这个功能”而是写清楚这次允许读什么、允许改什么、不能做什么、完成后要验证什么。第二先开放只读工具。让 Agent 先搜索、读文件、整理方案。等只读分析稳定以后再逐步开放写入和命令执行。第三高风险动作必须有人类确认。比如删除文件、改公共组件、执行迁移、访问外部系统、跑发布脚本都不应该让 Agent 自动决定。第四状态要落文件。长任务必须有 status。里面不用复杂写清楚目标、已完成、阻塞点、下一步、验证结果就够。第五结果要带证据。完成后不能只给总结。要说明 diff 范围、验证命令、失败输出、未验证项和需要人工复查的部分。这些做法看起来不复杂但它们把 Agent 从“会执行的模型”放进了一个可控系统里。我现在怎么判断一个 Agent 能不能进项目以前我会先看 Agent 能不能完成任务现在我会先看它有没有治理入口。我会问五个问题它能不能在行动前明确边界能不能把工具分成不同风险级别能不能在任务中断后恢复状态能不能把验证结果当成交付的一部分能不能留下可追溯的审计记录如果这些问题都答不上来即使 demo 很惊艳我也不会放心把它放进真实项目。因为真实项目里最怕的不是 Agent 做不出来。最怕的是它做了很多但你不知道它为什么这么做不知道它有没有越界不知道它失败过什么也不知道它的结果能不能复现。结尾这几天的 Agent 更新给我的最大提醒是Agent 的下一步竞争不只是模型能力更重要的是谁能把执行放进一个可恢复、可验证、可追溯的工作系统里。执行能力决定 Agent 能不能动起来治理能力决定你敢不敢让它进入项目。所以我现在看 AI Agent已经不太只问“它能不能自动完成任务”。我更关心它怎么被约束怎么留下状态怎么证明结果怎么在失败后恢复。这才是 Agent 从演示走向真实项目时真正要补上的东西。