夜雨聆风
这几天 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 的 Pass@1 是 19.1%，使用 full adapter 可以到 73.4%。论文还提到，模型选择会带来 29.4 个百分点的 Pass@1 差异，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 从演示走向真实项目时，真正要补上的东西。
