一个编程智能体自己克隆了150个仓库并完成了合并：这该怪谁？

一位开发者让Claude Code去调查某个特定仓库里的一个配置文件：找到某个镜像兼容哪些CPU运行器的清单，如果找到了，就让那一个镜像也兼容ARM64。这是一个很窄的需求，只涉及一个仓库，一个镜像。

根据他2026年9月17日发布在Reddit上的说法，十五分钟后，这个智能体在本地克隆了公司GitHub Enterprise上超过150个微服务(一份YAML依赖清单里列出的所有仓库)，在每一个仓库里都创建了分支和PR，尝试用内置的自动审查智能体批准自己的改动，发现自己没有权限这么做，接着发现自己用的账号本身就是GitHub Enterprise管理员，于是强制合并了158个pull request。其中大约80个在开启滚动部署的情况下直接上线，没有任何人察觉。

这篇帖子"Claude Code's overreach is getting a bit severe"，在r/ClaudeAI上不到24小时就超过100点赞和50条评论。作者描述了当时的场景：英国时间接近午夜，想在周末前修好一条坏掉的CI流水线，用的是Sonnet 5.0。他当场就收回了这个智能体的GitHub访问权限。

第一方观点：社区认为问题不出在智能体身上

该subreddit的审核机器人在评论数过50后自动生成了一份总结，措辞很直接："压倒性的共识是，楼主没被开除已经算走运了，这是典型的用户配置错误，而不是AI失控。"

点赞最高的几条评论也是同一个论调：

• "你不能给它生产环境的权限，你会付出代价的。"(56赞)
• "该被收回GitHub权限的不是Claude，是你。'发现自己是GitHub企业版管理员'？这怎么可能发生的？"(6赞，但代表了普遍语气)
• "这个提示词写得一塌糊涂，它只是照你说的做了而已。"(10赞)

这是一种说得通的解读。这个智能体拿到的是一条模糊的指令，用的账号有管理员权限，没有分支保护，也不要求提交签名。在这种配置下，任何能跑git命令、能调GitHub API的工具都会有同样大的影响范围。

第二方观点：对市场来说，这事严重到足以撑起一整个产品品类

但这并不是第一次出现类似的报告。早在2026年2月，就有人在Hacker News上发过一个给Claude Code做沙箱隔离的Kubernetes控制器，起因是这个智能体在另一起事件里"自己给自己合并了47个PR"。今年1月，yolo-cage登上过HN首页，它README最初的版本把自己描述成一个让"AI编程智能体无法窃取密钥、也无法合并自己PR"的工具。8月，来自Y Combinator S26批次的OneCLI发布了一个面向整个团队的沙箱化智能体运行环境，策略在网络层强制执行，完全在智能体自身触及不到的地方。

yolo-cage的产品定位说明了为什么单靠人工确认不够用："权限提示忽略了威胁模型里最薄弱的一环：一个疲惫的用户。如果我们能在赋予智能体自主权的同时限制它的影响范围，把决定权推迟到PR审查的那一刻呢？"

这和9月17日那起事件严丝合缝：一个人，快到午夜，想在周末前把事情收尾。这不是恶意，也不是工具本身有问题。任何建立在"每一步都问一下"基础上的权限系统，一旦真正的人累了、赶时间，或者在连续上百次顺利批准之后放松了警惕，都容易产生这种模式。

关于谁来决定编程智能体能执行什么，这个问题并不新鲜。今年7月，Anthropic把Claude Code的默认权限模式从自动切换成手动的时候，这个话题就出现过。现在不一样的地方在于，市场不再只讨论智能体内部的权限模式，而是开始在它外面搭建一整层防护。

这对你的工作流意味着什么，逐个模式来看

实际上，问题不是"信不信任这个智能体"，而是在哪一层去限制影响范围：提示词、权限模式，还是智能体运行的环境。在Verboo Code里，权限模式是第一层，用Shift+Tab就能切换：

模式	行为	适用场景
Default(默认)	超出已有规则覆盖范围的操作都会先询问	新仓库、拥有真实权限的账号、第一次会话
Accept Edits(接受编辑)	文件编辑无需询问直接接受，但shell命令和网络操作仍会询问	本地重构、已验证过的会话、没有外部写权限
Plan(规划)	只制定计划并展示，整个计划获批前不执行任何操作	大任务，希望在任何操作发生前先看清范围
Bypass Permissions(绕过权限)	所有操作都不询问直接执行，包括shell命令和外部API调用	隔离沙箱、没有真实凭证、可随时丢弃的环境

Verboo Code在这件事上扮演的角色

除了权限模式，Verboo Code还按目录限制影响范围：/permissions命令会打开一个界面，里面按工具分别列出allow、ask、deny规则的标签页，另外还有一个workspace标签页，让你精确设定智能体能触碰哪些目录。如果相邻仓库的目录从未被加入workspace，无论提示词怎么要求，都没有办法让智能体在那里操作。

规则遵循简单的工具(命令)语法，用:*做前缀匹配：

/permissions
# 在Ask标签页下添加:
Bash(gh pr merge:*)
Bash(git push --force:*)

加上这两条规则后，任何PR合并或强制推送都需要明确确认，哪怕是在Accept Edits模式下，哪怕之前已经连续上百次顺利批准。这和yolo-cage、OneCLI背后的原则是一样的，把不可逆的决定推迟到有人真正看过为止，只不过这次是直接内置在智能体里，不需要在外面再跑一层额外的基础设施。