一个编程 Agent 没有报错，也没有拒绝工作。它只是永远觉得，还差两件事。

Steve Yegge 在文章 《The Shape of Things to Come》 中说，他原本希望 Gas Town 能成为一套可复用的工具，结果它基本只被用来开发自己。更麻烦的是：Gas Town 在 Opus 4.6 上运行良好，换到 4.7 后却开始反复修改自身，迟迟无法进入真正任务。

4.6 能收工，4.7 总想再改两处

Yegge 把这种行为称为“just two more things”——模型每次都认为还需要再处理两件事。

问题在于，这两件事做完后，往往又冒出两件事。Agent 看起来一直在忙，任务却没有结束。

观察项Opus 4.6Opus 4.7目前缺少什么
Gas Town 的运行状态Yegge 称其表现很好开始持续调整 Gas Town 自身完整运行日志与可复现实验
任务收敛能进入实际工作反复增加待办，难以结束准备阶段明确的终止条件和步数、时间、Token 上限
实际损失未披露Yegge 用“烧掉了”形容项目失效时间、费用、代码返工量等量化数据
测试条件未披露未披露提示词、工具权限、上下文和任务是否完全一致

“烧掉了”是 Yegge 的比喻，不是说代码或数据真的消失。更准确的理解是：模型行为变化破坏了原有工作流，Gas Town 因而失去实用性。

这段公开引文也没有提供运行记录。我们不知道 Gas Town 是否设置了硬性停止机制，4.6 与 4.7 是否使用相同配置，也不知道问题能否在其他项目中复现。

所以，它不能证明 Opus 4.7 整体退步。

但它是一份很有价值的故障报告。

模型答得更好，Agent 仍可能更难用

普通聊天任务很短。模型多补一个建议，用户大不了关掉窗口。

Agent 不一样。它会读取代码、调用工具、修改文件、检查结果，再决定下一步。如果每轮都倾向于增加一点工作，任务树就会不断生长。

短对话里，这种倾向像“认真负责”。放进自治工作流，它可能直接破坏收敛。

一个长任务 Agent 通常要同时过三关：

  • 能力够不够.能否理解代码并完成修改。
  • 执行稳不稳.会不会误用工具、扩大改动范围。
  • 知道何时停.达到验收条件后，能否结束任务。

行业评测经常把注意力放在第一项。比如答案是否正确、补丁能否通过测试、单次任务完成率是否提高。但生产系统还要看后两项，尤其是收敛性。

“差之毫厘，谬以千里。”模型每轮只多出一点修补欲望，放进几十轮甚至更长的执行链，最后可能变成完全不同的系统行为。

软件行业早就习惯给数据库、编译器和依赖库升级做回归测试。版本兼容，仍不代表业务行为兼容。Agent 更棘手，因为模型输出带有概率性；API 没变，语气偏好、规划习惯和停止倾向也可能变。

我的判断很明确：长任务 Agent 的收敛性必须单列为上线指标，不能藏在模型总分后面。

不过，责任也不能全推给模型。

如果 Gas Town 没有硬性预算、验收规则和自我修改边界，那么它本身就过度依赖模型“自觉收工”。健壮的 Agent 编排，不该把刹车踏板也交给模型。

生产环境升级，先测它会不会停

这件事最直接影响两类人。

个人开发者用 Agent 辅助写代码，通常还能人工打断。损失多半是多花一点时间、多烧一些 Token，或者清理一堆没必要的改动。

维护自动化编程工作流的团队承担的代价更高。Agent 如果接入代码库、CI 或内部工具，一次行为漂移就可能带来长时间空转、变更范围膨胀，以及更难审查的提交。

模型升级不该直接全量替换。更稳妥的做法如下：

动作具体检查不通过时怎么办
固定旧版本作为基线保留 4.6 或当前生产版本的任务结果不要自动跟随新版本
重放真实长任务使用相同提示词、工具、上下文与权限条件不一致，就无法判断版本差异
记录收敛指标任务树是否持续增长、工具调用是否异常增加、何时首次满足验收条件把异常增长列入阻断条件
设置硬停止机制限制执行步数、时间、Token 和可修改目录达到预算后转人工确认
限制 Agent 修改自身编排文件、系统提示和工具配置默认只读确需修改时单独授权
灰度并保留回滚先让少量任务使用新版本出现空转或改动膨胀，立即退回基线

是否应该放弃 Opus 4.7？目前证据不够。

交互式使用者可以尝试新版本，因为人就在旁边。依赖 Agent 自主运行的团队则不该凭跑分升级。至少要等同条件复现、更多项目反馈，以及更完整的运行日志。

真正需要观察的也很具体：同一任务、同一工具权限、同一预算下，4.7 是否比 4.6 更频繁地扩展任务；加入明确验收条件后，这种行为能否消失；问题究竟来自模型偏好，还是 Gas Town 的停止设计。

模型版本号可以一夜换掉。工作流的责任，不能跟着一起外包。