你的 AI 想跑个脚本，另一个 AI 先把它拦下来了

事情是这样的。昨天 Cursor 发了篇博客，介绍一个叫 Auto-review 的新机制。一句话概括，他们给编程 agent 配了个贴身保安，也是个 AI，专门在 agent 动手之前看一眼，这一步危不危险，要不要拦。

AI 管 AI。我看到这个设定的第一反应是想笑，第二反应是，诶，这事我熟。

我的日常工作就是给大模型搭脚手架，就是让模型真正能干活的那层工程，工具怎么接、权限怎么给、跑飞了怎么兜底。所以 Cursor 这篇博客里描述的每一个纠结，我都能对上号。今天想跟你唠唠这个。

先把背景铺一下。现在的编程 agent，不管是 Cursor 还是 Claude Code 还是 Codex，都在往「自主」这个方向狂奔。你给它一个任务，它自己读文件、改代码、跑命令、装依赖，一路干到底。爽是真的爽。但你想想它手里都摸着什么，你的文件系统、环境变量、各种密钥凭证、MCP 工具，运气好的话还有生产环境的访问权限。

一个不受管的 agent 加上这些权限，等于什么，等于你把家门钥匙、车钥匙、保险柜密码全交给一个刚认识三天的实习生，然后跟他说，放手去干。

那管起来不就完了？每一步都问用户，你批准我再动。

问题就出在这。所有重度用过编程 agent 的人都知道那个体验，弹窗，批准，弹窗，批准，弹窗，批准。前十次你还会认真看一眼它要跑什么命令，第三十次开始你的手指已经形成肌肉记忆，弹出来就点确认，看都不看。

Cursor 在博客里把这层窗户纸捅破了，反复请求许可本身也是安全问题。提示多了，人就不读了，审批流程就成了走过场。

这个观察有点子牛逼。它说出了一个大家都在干但不太好意思承认的事，市面上多少人是直接开着 YOLO 模式跑 agent 的，Claude Code 那个 dangerously-skip-permissions 参数，名字都把「危险」写脸上了，照样是高频选项。不是大家不怕死，是审批这个交互形式本身已经失效了。Anthropic 自己的最佳实践文档里也只能委婉地建议你配 allowlist、上沙箱，但 allowlist 是静态的，它不认识上下文。

而上下文恰恰是关键。

同一条命令，在这个项目里无害，在那个项目里就是事故。python script.py，安全吗？不知道，得看 script.py 里写了什么。rm -rf ./build，安全吗？大概率安全，但如果当前目录被 agent 自己刚刚 cd 错了呢。静态规则对这些问题无能为力，因为危险从来不在命令本身，在命令和意图的关系里。

所以 Cursor 的思路是，既然判断需要上下文，那就找个有脑子的来判断。他们训练了一个专门的分类器 agent，挂在主 agent 的执行路径上，每次有需要裁决的工具调用，它先看一眼，结合上下文判断这步操作是放行还是拦截。

这个分类器的几个设计决策，我觉得是全文最值得抄作业的部分。

第一个，它选了小模型，但不是无脑小。博客里提到一个挺有意思的发现，低推理配置的模型并不总是更快。模型如果理解不了策略或者看不懂工具调用，它会花更多时间和 token 在那瞎找，最后还给个更差的答案。更好的搭配是小模型加上够用的推理能力，干脆利落地下判断。这个我真的有共鸣，挑模型不是挑参数量，是挑「它能不能在你的场景里果断」。

第二个，分类器自己也是个 agent。光看命令字面判断不了的时候，它可以先用 ReadFile、Grep 这些只读工具去工作区里翻一翻，看看那个 script.py 到底写了啥，再做决定。一个保安，不光站在门口看你的工牌，还会跟进去看你抽屉里装的是文件还是螺丝刀。

第三个，也是我觉得最妙的一个，拦截之后不弹窗。

你没看错。分类器拦下一个操作之后，第一选择不是去打扰用户，而是把拦截理由反馈给主 agent，主 agent 拿着这个反馈，通常可以自己换一条更安全的路径继续干。缩小操作范围，换个工具，或者干脆绕开那个高风险步骤。

好家伙，这等于在 agent 内部装了个自我纠错的回路。用户的注意力被当成稀缺资源保护起来，只有真正过不去的坎才会上升到人这一层。

数字也给得挺实在。分类器实际运行时大约拦截 4% 的操作，而这些拦截大部分被主 agent 内部消化掉了，最终只有约 7% 的对话会出现至少一次对用户的打断。作为对比，他们接触过的一些企业客户，之前内部的拦截率是 40%。从 40% 降到 7%，这不是优化，这是把一个不可用的东西做成可用了。

测试这块也值得说两句。他们先收集了大概 12 小时的内部开发会话，整理出 6122 行带标签的数据，用来确保分类器别把日常开发当贼防。然后又造了一批合成数据，专门覆盖最坏情况，agent 读密钥、碰生产数据、执行来路不明的指令这些。正常使用里这些场景出现得太少，不造数据根本测不到。

还有个细节我看完愣了一下。他们会专门盯那些结果反复横跳的用例，同一个 case 跑十次，六次放行四次拦截，这不是模型不稳定，是策略本身没定义清楚。把这些摇摆用例当成策略的 bug 来修，而不是当成模型的锅甩出去。

怎么说呢，这套东西读下来，你会发现它没有任何一步是「大力出奇迹」，全是工程上的细抠。在哪个环节插入审查，用多大的模型，拦截之后反馈给谁，数据从哪来，摇摆怎么处理。每一个问题都不性感，但拼起来就是一个能用的系统。

当然我也不是没有疑问。

最大的一个，分类器自己也是个模型，那谁来保证它不被骗？提示注入这个老大难问题，Simon Willison 追了好几年了，至今没有根治方案。如果恶意指令藏在 agent 读到的某个文件里，先把主 agent 带歪，再顺手把分类器也忽悠了呢。分类器能读工作区，这既是它的能力，也是它的攻击面。博客里没展开聊这个，我猜他们内部肯定也在想。

第二个，4% 和 7% 是 Cursor 内部和早期用户的数据，样本偏程序员、偏规范的工程环境。等它默认开给所有新用户，撞上千奇百怪的真实项目，这俩数字还能不能稳住，要打个问号。

不过这些疑问不影响我对方向的判断。把权限从开关做成旋钮，把审批从打断用户做成 agent 之间的内部协商，这个思路是对的。我自己搭 agent 工具链的时候，最头疼的就是权限这层只有全有或全无两个档位，中间那片灰色地带全靠人肉盯着。现在有人把这片灰色地带做成了产品，还附赠了完整的工程笔记，Composer 2.5 之后 Cursor 这一波接一波的节奏，确实厉害了。

往大了看，这件事还有另一层味道。我们花了两三年时间教 AI 干活，现在开始花时间教 AI 管 AI 了。监督这件事本身也被自动化了，而且理由跟当初自动化干活一模一样，人来做太慢、太贵、太容易疲劳。他们在聊云端 agent 的文章里也提过类似的演化，agent 越自主，围绕它的配套系统就得越完整。

写到这我想起航海里的一个老规矩，再有经验的船长，进港的时候也要请引航员上船。不是船长不行，是港口的暗礁只有天天泡在这片水域的人才认得。分类器干的就是引航员的活，平时不碰舵，只在水浅的地方提醒一句。

船还是那条船，舵还是 agent 在掌。只是从今往后，进港的时候，旁边多了个看水的。

我自己还没把 Auto-review 打开跑一圈，新用户已经默认开启，老用户得去设置里的 Agent 选项手动打开。等我拿真实项目折腾一段时间，有发现再来跟你汇报。