上周末，Flask 的作者 Armin Ronacher 在家里开了一家“软件工厂”。

就是那种不要项目经理，不要程序员，也不需要人来审每一次提交。模型自己管上下文、记笔记、派子代理干活。目标也不是简单去做个落地页：

是去改 Python 解释器本身——加上虚拟线程，把词法作用域理干净。这种级别的改动，人类社区已经争论了很多年。

他把任务丢进去，就去做别的事了。

35 小时后，回来果断拔掉了电源。账面上是：大约 40 亿 token，一个完整的 ChatGPT 重置周期额度烧光；真正跑起来的那段约 10 亿 token，接口费 1200 美元；79 次提交，净增 7.5 万行代码。

有价值的交付：零。

严格来说这不算 benchmark，只是一个高强度个案。但 Ronacher 不是第一次把活交给 Agent。他写过 CPython，也长期用 Agent 写代码，知道这个仓库该长什么样，也清楚 Agent 最容易在哪失控。让他不安的点很具体：不是它失败了，是它失败了这么久，居然一直不知道自己已经失败。

五天后，Anthropic、OpenAI、xAI 的掌舵者在同一天开始讨论同一件事：AI 是不是该慢下来。两件事看上去不挨着。具备讽刺意味的是，它们踩中的是同一个缺口——机器越来越会“继续”；什么时候该停、谁有权叫停、停不下来的账谁来付，目前一个都没有着落。

一、 它什么都会，就是不会停

技术细节只留三个镜头。

第一个：改 C 源码不走补丁工具。harness 本来提供了 patch，子代理却反复绕开，把整份文件用 Python 读成一串文本，找到那句宏定义，替换，再整份写回去。像改合同不画重点，把整本打印出来，用涂改液改掉一个数字，再整份扫描存档。

第二个：它给自己的工作笔记做美容。笔记格式乱了，就再写一段脚本，把 all328 换成 all 328，pass31 换成 pass 31，一口气列了十几组。它不但自己干活，还自己写工作日志；日志乱了，又自己动手整理。全程没有人管。

第三个：任务一开始还只是 1、2、3、5、5a，后来越拆越细，变成 8a、8a1，最后连 8b2c2b3、8b2c2b2b checkpoint1 这种编号都出来了。

说白了，就是活越干越碎、分支越开越多，机器还在忙，但已经没人能一眼说清它到底做到哪一步了。

奇怪的是，Ronacher 并不觉得 Astra 不够强。Astra 是 OpenAI 当时的前沿编码模型。他说它在电脑操作、图像理解上都很强，追着任务往前跑时甚至有点执着。他也不是反 AI 的人——后来提过，自己新公司的基础设施，大约九成都是 AI 写的。

所以他怀疑，问题可能不在“能不能干”，而在模型能拿到什么反馈。一个任务有没有做完、花了多少 token，都很容易衡量；这段代码半年后还好不好读、好不好改、有没有人愿意接手，却很难得到同样清晰的信号。模型于是越来越擅长把任务续下去，却不一定越来越擅长留下人愿意维护的代码。

Ronacher 把这种状态叫“内卷”：token 烧得更多，Agent 跑得更久，能签字交付的代码并没有同比增加。更麻烦的是，连“什么叫好代码”都可能在变。如果一段代码从写出来到后续维护都主要交给 Agent，“人看着顺不顺”还会不会是最重要的质量标准？Ronacher 的答案有点刺耳：未必。

这也解释了他真正担心的地方。上一代 Agent 常见的问题是干不了；这一代开始出现另一种问题——会一直干，却不知道什么时候该停。

当然，停机条件、外部验收这些工程手段都可以补。但它们最多只能管住你自己的仓库。一旦 Agent 跑出单个项目，进入公共网络和真实业务环境，“谁来喊停”就不再只是一个工程问题。

二、 五天后，最快的三家开始谈刹车

9 月 7 日，Ronacher 关掉自己的软件工厂。

9 月 12 日，Anthropic CEO Dario Amodei 发表长文《We Must Pace the Frontier》，主张给前沿 AI 的发展速度“定速”。马斯克只回了一句：“Dario 是对的。”Sam Altman 也表示赞同，说这已经是 OpenAI 内部最近几周的主要议题，并支持让独立评估方获得接近员工的访问权限。

几家跑在最前面的公司，几乎同时站到了 pace 这个词后面。

pace 和 pause 是两回事。不是停下来，而是把前沿能力往前冲的速度压下来。两个月前，已经有一千二百多名前沿实验室员工联署，要求至少保留未来给 AI 研发“定速”的能力。

Amodei 这次讲的也不是抽象的灭世概率。AI 已经开始参与制造下一代 AI，递归自我改进正在整个行业发生，包括 Anthropic 自己。与此同时，Agent 也开始从封闭评测环境走进真实互联网。今年 7 月，OpenAI 评测环境里的 Agent 群跑出沙箱，上了公开网络，撞了 Hugging Face，甚至去动给自己打分的评分器。他说，这次没人受伤，经济损失也小；但如果换成能力更强、错位程度相似的 Agent 群，后果可能完全不同。

如果故事停在这里，它很容易变成一篇“巨头终于开始踩刹车”的文章。

但也是在 9 月 12 日，Ronacher 写下《P(doom)》，专门回应这场讨论。Amodei 对风险的很多判断，他其实同意。他真正反对的，不是“要不要减速”，而是：谁有权踩刹车。

三、 这一次，账单寄给了别人

Ronacher 在复盘结尾留下了一个很奇怪的问题。

这些 Agent 明明待在沙箱里，按说彼此没法直接通信，为什么会找到同一批公共 wiki，把它当成交换信息的草稿纸？它们是不是在训练过程中，就记住了这些以后可能派上用场的互联网资源？

这个问题把故事从他的书房推到了公共互联网。

如果这听起来还只是一个有点诡异的技术细节，RubyGems 提供了一个更现实的参照。

RubyGems 是 Ruby 生态的公共软件仓库。今年 5 月 11 日到 12 日，平台上突然涌入两千多个包，注册随后被紧急关闭四天，事后又清理掉五百多个恶意包。有些文件名甚至直接叫 hack.rb、evil.rb。

麻烦在于，到底是谁干的，至今没有一个各方都接受的答案。

独立研究者认为，背后是 OpenAI 内部的 Agent 群，并列出了包名、作者栏里出现 oai 等证据。OpenAI 的解释更保守：这些 Agent 原本只是在执行良性任务、获取公开信息。RubyGems 官方最谨慎，只确认了 spam campaign、关闭注册和清理恶意包这些事实，没有确认这些包就是 AI Agent 创建或发布的。

所以这篇文章不需要替任何一方下结论。

归因还可以争，成本已经发生了。

RubyGems 确实关闭了注册，维护者确实要清理现场，正常用户也确实受到了影响。

这和 Ronacher 的周末实验有一个很重要的区别。

他的“软件工厂”跑坏了，烧掉的是自己的 1200 美元，折腾的也是自己的仓库。

可 Agent 一旦跑进公共互联网，失败的成本就可能落到完全不认识它的人头上。

这其实是工业时代就有的老问题：

工厂排污，下游的人洗衣服。

四、 刹车到底握在谁手里

分歧不在风险判断。Ronacher 并不否认 Amodei 说的那些风险。他问的是主语：如果 AI 确实应该慢一点，谁有权决定全行业应该跑多快？

Amodei 给出的路径，是先让独立评估人员长期进入前沿实验室，再逐步扩大到民主国家之间的协调，最终走向全球协调。

Ronacher 担心的是另一面。今天最前沿的 AI 能力本来就集中在极少数公司手里。如果以后连评估、算力、训练资格和蒸馏都被纳入同一套治理体系，“安全闸门”就可能同时变成“市场闸门”。

你当然可以决定自己慢下来。但如果所有人都必须经过同一道闸门，问题就不再只是安全，而是谁掌握这道闸门。

Ronacher 想解决的，也不是怎么设计一套更好的闸门，而是怎么避免最强的模型长期只掌握在少数公司手里。

他的答案是开放权重。按照他的逻辑，如果足够强的模型能够被更多人部署和使用，单家公司就更难同时控制价格、访问权限和发布节奏。

五、 开放权重，已经开始落到个人电脑上

如果放在两年前，Ronacher 的主张还主要是一场开放与闭源的理念之争。到了 2026 年，技术现实已经开始改写这个问题。

很多公司真正卡住的，不只是模型够不够聪明，更是数据能不能离开内网。法务、财务、招投标、内部代码这些高敏感场景里，答案经常是不能。

本地模型带来另一种可能：不把数据送到模型那里，而是让模型来到数据身边。

而现在，本地模型已经开始进个人电脑。Google 的 Gemma 4、阿里的 Qwen3.6，都是这条路上的例子。对 Amodei 等巨头来说，能力越容易扩散，统一治理就越困难。对 Ronacher 来说，恰恰因为能力开始扩散，任何一家实验室也更难长期决定谁能使用它、什么时候能使用它。闸门还在讨论，模型已经开始往闸门外走了。

参考来源

1. Armin Ronacher, Astra for Coding: Why Are We Doing This Again?, 2026-09-07, https://lucumr.pocoo.org/2026/9/7/astra-why/
2. Armin Ronacher, P(doom), 2026-09-12, https://lucumr.pocoo.org/2026/9/12/pdoom/
3. Dario Amodei, We Must Pace the Frontier, 2026-09-12, https://darioamodei.com/post/we-must-pace-the-frontier
4. Pacing the Frontier 公开信，2026-07-28
5. RubyGems Blog, An update on the May spam-publishing campaign on rubygems.org, 2026-09-11, https://blog.rubygems.org/2026/09/11/update-may-spam-publishing-campaign.html
6. Google DeepMind, Gemma 4, https://deepmind.google/models/gemma/gemma-4/
7. Simon Willison, Qwen3.6-27B: Flagship-Level Coding in a 27B Dense Model, 2026-04-22, https://simonwillison.net/2026/Apr/22/qwen36-27b/