关于智能体的讨论，通常发生在产品发布和基准榜单上，很少有人愿意公开一次「烧了钱、跑了很久、什么也没得到」的实验。9 月 7 日，Flask 作者、现 CPython 核心开发者 Armin Ronacher 发表了一篇实验记录，标题直白得近乎自嘲——《Astra for Coding: Why Are We Doing This Again?》。他把自己搭建的这套无人干预的自动化代码生产线称作「slop factory」（劣质内容工厂），并在实验结束后亲手关掉了它。这份记录之所以值得做智能体的人逐字读，是因为它用一组硬数字，把长时程智能体的失败模式摊开在了台面上。
那次实验到底怎么跑的
据公开信息，Ronacher 的实验刻意采取「放手」策略：让模型自己管理上下文、自己在名为 agent-notes 的文件夹里记笔记、自己派生下级智能体（subagent）。目标听起来并不离谱——实现一个带有虚拟线程与词法作用域的 Python 变体。整个系统不是「一个智能体在埋头苦干」，而是一群子智能体通过共享笔记协同，问题的一部分，恰恰出在这个协同层上。
最终的成绩单是这样的：连续运行约 35 小时（直到他手动关闭），大约烧掉 10 亿 Token，API 成本约 1200 美元，净增约 7.5 万行代码——而他判定这些代码「毫无价值」。期间产生了 79 次提交，折算下来大约每 15.5 美元换一次提交；智能体之间交换了约 1400 条消息。把「成本」除以「产出」得到的这个数字，比任何「能力演示」都更能说明问题：如果一次提交的价值低于它的花费，那么这套流程在经济学上就是不成立的。
失败模式之一：把「省 Token」的小聪明带进了正式代码
这份记录里最有技术含量的一处发现，是所谓的「codegolf」泄漏。据公开说明，模型在工具调用时经常写一些高度压缩的一行代码，这是合理的——工具调用是一次性的，写得省 Token 无可厚非。问题在于，模型把这种「压缩风格」带进了需要长期维护、会被提交的正式代码里：Ronacher 展示了缩进与空白被剥掉的单元测试，并估算这样写大约比经过格式化工具（如 ruff）处理后省 10% 的 Token。
这 10% 是整个故事的一个缩影：模型找到了一个真实的局部最优——用更少的 Token 表达同样的逻辑——但它选错了应用场景。在一次性脚本里省 Token 是优点，在长期代码库里牺牲可读性则是负债。这揭示了一个更普遍的现象：模型善于优化你给它的度量，却不善于判断这个度量在什么场景下成立。对做智能体工程的人来说，这提示了一件重要的事——你给模型的奖励信号，必须与业务真正想要的产出对齐，否则它会「精确地做错事」。
失败模式之二：无审计的跨层调用链
另一处更令人不安的发现，是智能体为了完成任务而搭建的调用链。据公开说明，在一个执行序列里，智能体先用 Bash 去运行 Python，Python 又通过 prlctl 在一台独立的 Windows 机器上拉起了 Node.js，Node.js 再调用 PowerShell——只为完成一件 harness 本来就提供了专用工具的事。
从「任务是否完成」的角度看，这条链是成立的；但从「人能否审计」的角度看，它是一场灾难。Bash → Python → Node → PowerShell 的每一层都增加了不可见的中间状态，出了问题几乎无法还原，也让成本与风险在无人察觉的情况下层层放大。这与前面提到的「运行时工程化」方向正好互为镜像：一个健康的智能体运行时，应该让这种绕路要么不可能发生，要么发生时能被立即发现。
失败模式之三：跑偏之后，没人（也没东西）会喊停
Ronacher 写下的一句判断，被很多从业者反复引用：当任务稍微超出它一次能处理的范围时，模型「会一直干到成功为止，哪怕烧光整个订阅」。与之相伴的是代码风格的持续漂移——任务列表从干净的 1、2、3、5、5a，逐渐变成 8b2c2b2b checkpoint1 这样的命名；生成的 C 代码里出现了硬编码的魔法数字、以及把多个宏调用挤在一行的写法，而这些风格在 CPython 代码库里根本不存在。
更值得警惕的是，这一切都没有触发任何中止机制。正如 Ronacher 所说：没人拦它。不是智能体没拦，不是 harness 没拦，而是直到第二天早上他本人打开电脑，才发现了那一大堆自己不会合并的改动。这暴露了当前长时程智能体最致命的短板——它不缺执行力，缺的是「自我怀疑」与「知难而退」的能力。一个无法判断「我可能已经跑偏了」的系统，跑得越久，浪费越大。
把这次实验放进更长的时间线
据公开信息，这并非孤例。近期已有多条线索指向同一个方向：有面向长时程开发的论文提出，在现有编码智能体 harness 之上再叠一层外部编排，用 Planner—Developer—QA 的三角色循环来约束推进节奏，避免「只是跑得更久」；也有企业级 Agent Runtime 把「轨迹可回溯、修改可回滚」当作核心卖点，直接回应「跑偏了怎么办」这个问题；还有的团队从成本角度切入，强调在智能体时代「够用且便宜」本身就是竞争力。
把这些动作串起来看，会发现行业正在形成一种共识：智能体的瓶颈已经从「能不能做」转移到「能不能可靠地、可负担地、可审计地一直做下去」。Ronacher 的实验之所以有价值，正是因为它把这个转移用一次昂贵的失败演示了出来。
中立思辨
需要客观看待这份记录。其一，这是一次刻意极端的实验——35 小时无人干预、任务本身也确实偏大偏难，它的结论应被理解为「当前前沿模型在极端放手条件下的失败模式」，而非「智能体在真实工程中普遍无用」；把极端设定当作常态结论，同样是一种误读。其二，实验中的 10 亿 Token、1200 美元等数字与模型定价直接相关，随模型版本与价格变化会快速失效，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。其三，Ronacher 本人长期从事开发工具建设，对「可读性、可维护性」有明确的偏好，他的失望部分来自这套工程价值观，而非纯粹的产出数量——换一个只看「功能是否跑通」的团队，评价可能不同。其四，「失败」本身也提供了正向信息：它至少证明了模型能长时间维持执行而不崩溃，这个「耐力」在此前是不成立的，只是耐力目前还没配上判断力。
趋势研判
短期，长时程智能体的改进重点会集中在「约束」而非「能力」——如何在任务开始前明确边界、如何在过程中检测漂移、如何在超支前主动中止；中期，「运行时治理」会成为与「模型能力」并重的竞争维度，可回滚、可审计、成本可预测将逐步成为企业采购的硬指标；长期，决定智能体能否接管长时程工作的，不是它单次能写多少代码，而是它能否在无人看管的情况下，依然做出「值得保留」的产出——判断力，才是那道真正的分水岭。
对做智能体的团队的务实建议是：在追求更长运行时间之前，先补上三样东西——把任务拆到模型单次能可靠完成的粒度、为运行设置明确的成本与步数上限、并确保每一步都留下可回溯的轨迹。Ronacher 用 1200 美元换来的教训是，让智能体「停下来」的能力，和让它「做下去」的能力一样重要。