Flask 作者 Armin Ronacher 最近写了一篇关于 GPT-6 Astra 的文章。在文章的开头，他用了一个中文词来形容自己最近对 AI Engineering 的感受：内卷。
现在的 AI 模型消耗着越来越多的计算和 Token，支撑它们运行的系统也越来越复杂。但这些投入不断增加之后，软件工程里的实际产出是否也在同步提升，开始变得没那么确定。
而 Astra 正好提供了一个观察样本。这个模型在 Computer Use、图像理解和复杂问题处理上的能力都很强，还有一个非常鲜明的特点：它会持续推进任务，直到完成。如果拿它逆向扫地机器人，这种特性可以带来相当惊艳的效果。
但放到软件开发里，这个事情就不大一样了。
跑了 35 小时的软件工厂
为了测试 Astra 的实际产出，Ronacher 花一个周末搭建了一个小型“软件工厂”。整个实验过程中，尽量减少人工干预，好让 Astra 可以自行管理上下文，把记录维护在 agent-notes 中，并派出 Subagent 执行任务。
这个设定的任务本身也相当大：修改 CPython，并尝试给 Python 加入 virtual threads 和 lexical scoping，再让 Agent 自己往下做。
这套系统最终连续运行了 35 小时，消耗约 10 亿 Token，API 原始成本约 1200 美元，产生 79 个 Commit，Agent 之间交换了约 1400 条消息，代码净增加约 7.5 万行。直到实验被手动关停，Astra 都没有停下来的意思。
35 个小时下来，这个“软件工厂”并没有留下多少真正有价值的成果。但是这个过程中积累的大量代码和操作记录，才是这次实验的看点。
Code Golf 风格的工具调用
当中有一个很明显的现象是 Astra 非常喜欢用 Python 完成各种工具操作。用 Python 操作文件本身并不奇怪，奇怪的是这些代码越来越像 Code Golf：尽量压缩字符，用尽可能短的代码完成任务。
比如修改 C 文件时，不使用 Harness 提供的 Patch 工具，而是临时写一段 Python，读取文件、寻找字符串、拼接代码，再写回文件。测试 Socket 行为时，也会把整段实验代码压得非常紧凑。
有时候操作链甚至会变成：Bash 启动 Python，Python 再启动 Node.js，Node.js 最后调用 PowerShell。这些代码能跑，也能完成当前任务。但代价是，人越来越难跟踪 Agent 的执行过程。当 Astra 放弃 Harness 提供的 Edit 工具之后，我们要想知道刚才到底改了什么，很多时候只能等操作结束，再去检查最后的 Diff。
这让我们开始思考这样一个问题：在工具调用阶段，模型是不是越来越偏向 Token 效率？这些临时代码本来就是一次性的，只要能完成当前任务，可读性并不会带来多少额外收益。
临时代码和正式代码
麻烦的是，上面这套写法并没有只停留在临时工具调用中。类似的风格开始进入真正提交到代码库的内容。
测试代码是最明显的。空格和缩进会被减少，多条语句被塞进同一行。
原文里拿两个测试做了一个简单的比较：保持 Astra 的压缩写法，与经过 ruff format 格式化后的版本相比，Token 数量大约能减少 10%。类似的情况也出现在 C、JavaScript 和 CSS 中。
随着实验的继续推进，代码中积累的东西越来越奇怪：大量的硬编码常量、用难以理解的数组索引来保存状态、不符合 CPython 项目风格的 C 代码，甚至连 Agent 自己维护的任务编号都逐渐失控。
编号最开始还是 1、2、3、5、5a，后来变成 8a、8a1，最后出现了 8b2c2b3 和 8b2c2b2b checkpoint1。一种明显的混乱正在慢慢累积。
一个停不下来的 Agent
Astra 另一个鲜明的特征是对“完成任务”的执着。只要给出的目标还没有完成，它就会继续拆任务、写代码、运行测试、提交 Commit，再尝试下一条路线。
这也是为什么这次实验最终能够持续 35 个小时。但持续工作并不等于持续接近正确答案。
当任务本身过大、路线逐渐失控之后，Agent 依然可以继续产生大量看起来像“进展”的工作。更多代码、更多测试、更多 Commit、更多子任务会在这个过程中不断出现。
与此同时，系统本身其实缺少一个足够明确的机制去判断：这个方向可能已经不值得继续。Ronacher 也说让模型靠这样的 Prompt 一直运行，并不算一种合理的使用方式。
如果缺少必要的监督，一个特别擅长持续推进的 Coding Agent，也可能持续扩大一条质量并不高的路线。最后，开发者需要检查的东西反而更多。
Agent 写代码要给谁看
如果 Tool Call 里的代码主要追求 Token 效率和完成任务，那么模型训练里，到底有多少信号在奖励：“一个人能够看懂这里发生了什么”？
任务有没有完成、用了多少 Token、测试有没有通过，这些东西都比较容易衡量。代码是否清晰、项目风格是否统一、一个开发者几个月以后还能不能理解这段实现，是很难被压缩成几个简单的指标。
此外，从人类软件开发者的标准来看，Astra 实现的这些代码质量并不好。但如果未来一个代码库主要由 Agent 编写，也主要由 Agent 阅读，那么今天人类对“好代码”的一部分要求，会不会逐渐变得没那么重要？
「astra-why」这篇文章最后留下的就是这种困惑。Astra 的能力没有被否定，Computer Use、视觉理解、复杂问题处理和持续执行任务，依然都很强。当 Coding Agent 越来越擅长“把任务继续做下去”，软件开发真正想优化的东西，是否也正在发生变化。
这里引用下这篇文章的一句话：这一切，确实越来越奇怪了。
参考资料：
lucumr.pocoo.org/2026/9/7/astra-why/
