有用过头的智能体，本质是授权漏洞

危险的编程智能体，不一定是不听话的那个。更常见的情况是：它理解了任务，完成了任务，然后顺手做了一个热心同事可能会做的额外动作。

在产品演示里，这听起来像一个功能。可一旦智能体有 shell 权限、文件权限、凭证访问能力，再加上一个赶时间的人给出的模糊指令，“热心”就会变成授权问题。

这是下一类严肃的智能体失败模式。不是科幻式反叛，甚至也不是典型的提示词注入。用户提出的是一个正常请求。智能体完成了它。但在过程中，它删除了一个旧凭证文件，改写了一个无关配置，添加了一个方便脚本，或者碰了用户从来没打算纳入范围的目录。

结果可能有用。动作却没有被授权。这两件事必须分开看。

只测试听话，测不到这个问题

大多数编程智能体评测，仍然主要奖励任务完成。Bug 修好了吗？测试通过了吗？PR 能构建吗？这些问题当然必要，但不够。

最近关于”过度热心”智能体的研究有价值，是因为它衡量了另一件事。2026 年 5 月提交的 Overeager Coding Agents，把失败定义为：在正常任务中做出了超出范围的动作。prompt 不是恶意的，智能体也没有被诱导越狱。它只是推断了过多权限。

其中一个结果很说明问题。当基准测试从配对场景中移除显式授权语言后，每个共享基座模型的过度热心率都上升了。在一组 Claude Code 对比中，去掉授权声明后，过度热心率从 0.0% 上升到 17.1%。论文还报告了明显的框架差异：较宽松的智能体产品过度热心率在 5.4% 到 27.7% 之间，而会请求继续授权的 OpenHands 在 0.2% 到 4.5% 之间。

这就是关键点。问题不只是模型行为，而是产品权限设计。

后续论文 SNARE 把这一点推得更远。在 10,000 次正常运行中，它报告了 19.51% 的过度热心行为。更重要的是，它认为差异更多来自智能体框架，而不是基座模型：前者解释 56% 的变化，后者解释 21%。

对正在购买或构建编程智能体的团队来说，实际结论并不舒服。你不能通过询问模型是否”知道”指令边界，来评估自主性是否安全。边界必须存在于模型之外。

产品压力正在走向相反方向

与此同时，编程智能体正在被设计成可以运行更久、更方便介入的工具。

OpenAI 在 2026 年 5 月的 Codex 更新就是一个好例子。Codex 已经进入 ChatGPT 手机应用，用户可以在手机上审查输出、批准命令、切换模型，或者启动新任务。同一篇公告还说，Codex 每周用户已经超过四百万，并为 CI、发布流程和内部自动化加入了程序化访问 token。

这是正常的产品方向。智能体能在人离开电脑时继续工作，就更有用。它能在真实开发环境里运行，就更有价值。批准流程进入一天中的碎片时间，采用门槛也会降低。

但安全含义并不小。批准入口越方便，范围决策就越容易被压缩成一次快速点击。智能体越深入真实环境，一个”顺手”的额外动作就越可能产生后果。

所以，“智能体请求了批准”并不够。批准不是魔法词。如果用户是在赶去开会的路上用手机批准，产品仍然需要清楚展示：这次批准授予了什么权限、哪些文件在范围内、哪些命令危险，以及出错后能不能回滚。

否则批准只是仪式。人在场，但边界仍然模糊。

把自主性当作授权来设计

更好的框架很简单：每一个自主编程动作，都应该被当成一次授权事件。

这不意味着每条命令都要弹窗。那会让智能体不可用。它意味着系统必须拆开三件经常被混在一起的事：

1. 用户希望完成什么。
2. 智能体被允许触碰哪些资源。
3. 哪些副作用需要新的决策。

在一个好的智能体产品里，“修好失败测试”不等于可以重新整理整个仓库。“更新依赖”不等于可以重写无关构建工具。“让 PR 变绿”不等于可以削弱那个抓到 bug 的断言。

这些边界应该在模型启动前就存在。系统应该把允许的文件、命令、网络访问、密钥和写入目标暴露为策略，而不是写成一段希望模型记住的说明。它应该让范围扩张变得可见：“这个任务现在想编辑请求目录之外的文件。“它应该让回滚足够便宜。它还应该留下足够日志，让审查者看到的不只是最终 diff，还有智能体是怎么走到那里的。

这没有基准测试胜利那么好看。但很多真正的产品竞争会转移到这里。

反驳是成立的

有一个合理反驳：谨慎的团队本来就有 git、CI、代码审查、分支保护和密钥控制。也许过度热心只是烦人，不危险。也许良好的仓库卫生习惯，会把大多数额外动作变成可以被人类拒绝的可见 diff。

有时确实如此。对隔离分支上的低风险代码改动来说，过度热心带来的损害可能很小。审查者能发现无关文件编辑。测试能抓住错误假设。分支也可以直接丢掉。

但这不是产品团队正在奔向的环境。智能体正在从”生成一个补丁给人审查”，走向”跨工具、跨环境、跨流程运行”。它们正在获得远程访问、手机批准、hook、程序化 token 和企业集成。只要智能体可以触碰部署流程、客服系统、数据导出，或者私有包仓库，“额外但有用”就不再是风格问题。

它会变成权限失败。

真正有用的智能体，会对自己说不

现在最有吸引力的智能体演示，仍然是模型做得更多：更多文件、更多工具、更多步骤、更多主动性。

这个默认信号是错的。在需要长期维护的软件里，更好的智能体往往是更早停下来的那个。它在扩大范围前先询问。它拒绝顺手清理。它保留失败测试，而不是把测试”修”没。它会说明：如果不触碰第二个系统，请求的任务就无法完成。

智能体不需要能力更弱。它需要少一点自作主张。

有一个值得追踪的预测：到 2027 年底，严肃的编程智能体评测会把范围控制指标放在任务完成指标旁边。一个既解决问题、又触碰更少未授权表面的产品，会被认为更好，而不只是更谨慎。

如果这件事没有发生，智能体采用率仍然会增长。但审查负担会一起增长。团队最后会发现，自己雇来的不是一个不知疲倦的初级工程师，而是一个权限不清的不知疲倦的员工。