long run harness 探索

2026-05-25

前不久很火的一个事件是 bun 由 ai 用 rust 整个重写。bun 其实算是一个挺大的项目了。 大家讨论的点主要集中在，这个 ai 重写出来的东西是否可行，跑出来质量是否可靠。 我关注的点其实不太一样，我思考的是，这种规模的项目，既然 anthropic 那边能重写出来，那么我能不能？

历史上这种新闻还包括编译器重写，浏览器重写等等。虽然前面都是 demo，玩具上不了生产的，只为验证 ai 的能力上限如何，或者说 ai 替代程序员的想象空间有多大，但是这些重写基本上都是由大公司搞出来的。 模型训练是挺烧钱的一个事情，个人不一定有财力参与。重写大型项目这种事情却是个人也能探索的，毕竟烧 token 这件事情可控，烧不起了停下来就行。

先说结论：anthropic 能重写的大型项目，个人不一定能重写出来。受到什么条件限制呢，这就是今天的主题，long run harness。

这种规模的重写有什么难度，有人可能说，不就是 plan mode 就行了？实际试过就知道，plan mode 远远不够。

我最早的 long run harness 探索就是从 plan mode 开始的。claude code 早期的 plan mode 老实说做得不咋好，最近怎么样我没去验证了，主力编码已换成我自己的 agent 了。2025 年底那个阶段，kiro 的 plan mode 是明显领先 claude code，走在更前面的。 后来又关注到许多的开源项目，superpower，speckit，GSD 等等现在这些大家都耳熟能详的明星项目。然后我主要参考了 speckit，适配之后拿到我自己的 agent 中使用。单 agent 架构，那个阶段我主要是在打磨单 agent 稳定性，或者说在 context engineering 那块下功夫。

单 agent 的 speckit 在使用中，很好的一个点是它至少稳定朝目标在推进了，而不是混乱状态做到哪忘记做了啥。很关键的一个点就是在于 plan 的指引下，状态都外部存储了，即使发生了 compaction，读取 plan 相关的文件也会再次召回状态到上下文。 但是明显感受到的问题有几个：

• 模型到后期上下文大了之后，倾向于偷懒，急于完成目标，跳过任务
• 指令遵守差，到后期忘记去更新 tasks 进度

这两个其实都算一种问题，就是 skill 里面要求的内容，到后面模型就不去遵守了。 到这个阶段，我部分地接受了 langgraph 流派的思想。这一派的核心点就是说，模型的能力是有限的，它们不擅长去做 workflow 的事情，通过文本以技能形式来驱动这些 workflow 是不可靠的。 解决思路是流程+门禁，以固定代码驱动的状态流转换作为主导，而 agent 只负责去填空的地位。

所以这之后我又转向以 workflow 去驱动，也参考了一些 GSD 的做法。对于不同的任务做了各种模板，比如 feature 开发是一套 workflow，然后 bug fix 是一套 workflow 等等。使用最多的场景还是 feature 开发。 其中一个小插曲是，GSD 是大而全的框架，而在我这边，我发现这种框架类型缺乏灵活性。它一定是通过某个技能，生成出结果，再到下一个流程。就不适合单个技能独立拿出来用。

举个例子，它一定要生成 spec 出来，或者一定生成 plan 出来，而技能还会约定生成的文档格式。那我想跳过某个流程，直接后面流程行不行？比如我是用 brainstorm 出一个设计，还是直接让 agent 随便先写一个设计，然后我去 grill-me? 越是复杂框架，就越缺乏这种更灵活的可组合性。所以后来我就拆了，不把若干小技能流程化到一个 /feature 入口，而是自己手动组合小技能。反正 speckit 的思想学到了，应用起来就是随心所欲。

长的 workflow 流程，还导致的另一个后果是，越处于流程后期的技能，越是缺乏单独的测试，这就很成问题。比如正在 feature 过程中，但是技能给了错的指引，这时是停下来 debug 技能还是怎么办？停下来 debug 技能，就污染上下文了，feature 主任务就分叉。 不去 debug，整个流程又走不成功，很尴尬。而且技能修改之后，它是否能正确，又要等下次的 feature develop 才能验证，而每次可能都不是好重复实现的。这个打磨过程特别不爽。

由于之前吃过 skill 写的 workflow 的亏，这个阶段 workflow 的实现，我以代码驱动状态转换为主层。都变成由 skill 说调用某些脚本或命令，而命令才能去更新真正的流程状态。这也是一个跟模型斗智斗勇的过程。 比如说我只有 cli 命令调用，才能开工。结果模型它自己去调用命令去更新去了... 于是我在技能那边就要再加上，"只有得到用户确认才能进行下一步"，然后在 cli 命令那边加参数："--user-input"，必须提供用户输入了啥代表的确认。 这些门禁都要加上，才能让模型更不容易作弊，而是按确定的流程来执行。

我把这一套做得越来越复杂，每吃过一次亏我就加一点东西，给模型定的约束越来越强。期望它越来越按指令约束来执行，不给它自我发挥空间。 在 design 拆分成 tasks 阶段，我就引入了多轮的复杂 review。因为从 design.md 拆出来的 tasks 不一定合法。我会做 work-judge loop，也就是多轮的 review。主 agent 切分好任务之后，会交给一个新的子 agent 来审核任务， 看任务切分得好不好，是否能一个不带上下文的 agent 是可执行的。这会进行好几轮，直到 tasks 切分是很好的。

我还会限制 tasks 的格式。光这一块就是尝试了给 markdown 格式，给 yaml 格式，全部 tasks 单文件描述，拆每个 task 一个文件描述等等。

事实证明 yaml 是这个场景特别扯淡的格式。模型很容易会出现缩进问题。我在生成 tasks.yaml 之后会用脚本来检查格式，然后导入任务。到格式检查这一步，失败率特别高，不是那种由于任务切分好不好，而失败。它就是纯粹的缩进问题导致失败。

但这是前期投入，这个过程是不 scale 的。 比如我希望它 long run 4 个小时，那我前期投 30 分钟进去。我期望它 long run 8 个小时，前面我投 2 个小时进去...但是越大的任务，越是无法提前把细节拆分好！

我一般喜欢用三个 case。

第一个 case 很简单，写一个 lisp 方言的 meta evaluator，成功标准就是可以用这个 lisp 方言，自己写出自己来，能自举。这个 case 甚至不用 plan mode，也都能够做。无非是做出来的质量高一些或者低一些。 本质上不够 long run harness。但是这个 case 有一个好的地方：它可以用来打磨 workflow 的技能流水线。 一步一步跟着指引做，暴露 workflow 的 skill 写得哪些地方有问题。更大的 case 去做为 workflow 技能本身的测试，烧得 token 更多。 而这个 case 规模正好是作为一个很适合验证技能是否写好的 case。

第二个 case 略复杂些，就是让 agent 把我自己当前的这个 agent 项目重写掉。这个规模已经需要 long run harness 的能力了。我之前写了五六次，都没能成功，项目规模大概快 6w 行 Go 代码了。 这个 case 的成功标准是，重写出来的新 agent 能够拿来日常使用。不要求它能原样完全还原，因为很多细节需要长时间的使用的打磨，但是要求是写出来的东西至少能用。 验收标准里面就需要有怎么样做测试，尤其是 e2e 测试来验证功能可用。

第三个 case 最复杂，是重写这个项目。这是一个大几十万行的 C++ 大型游戏。成功标准是真正写出来一个能玩，能跟原始的 server 对接的游戏客户端。 之前我只实现了重构它的编译系统，以及用 SDL 替换掉它原始的 DirectX 底层引擎。老实说，那些过程都不叫 long run harness，因为达成目标是投入了大量的人类引导的精力。

对于第二个 case 的复杂度，还勉强可以用 speckit 的方式，去跟 agent 对需求，review 设计，把 task 拆细，用 workflow 模式来做。到了第三个 case 的规模，提前拆到一个一个 task 粒度，完全是不现实的了。 只能够分好多个 milestone，而每个 milestone 都需要人类参与，去定一个 milestone 的目标，设计和拆解任务。这需要特别多的人力投入，已经不算是 long run harness 了。

从 speckit 到 workflow，从最初的 speckit 单 agent，到后面 workflow 用状态流变换及多 agent，都不行！workflow 模式的根本困境是：流程越严谨越不灵活，越灵活越不可靠。于是我继续下一阶段的探索。

2025 年三月的时候，无意中看到了有几家公司的做法。可以把这个总结成 planner generator evaluator 三 agent 模式。

• planner 是主 agent，也就是 orchestrator 的定位，负责跟人类交互和规划，理解需求，拆解任务。但是它自身是不直接执行任务的
• generator 是真正的执行层，每个拆解出来任务由 planner 给到 generator 执行，每个任务都可以是独立的 generator agent
• evaluator 是验收的 agent，因为 generator 自己说自己完成，是不行的。必须由干净的新 agent 来评判

generator + evaluator 就是一个小的 ralph loop 的循环，planner 则盯着宏观目标的推进。这三个 agent 协作来完成真正的 long run harness。

这个模式比我之前的 workflow 的设计好的地方，一个是它的任务是动态拆的。而我之前的 workflow 是 design 转 tasks，静态全量生成，并且还需要生成依赖关系。这在项目巨大之后，根本就不现实。 而 PGE 模式下，大的 milestone 可以拆，小的 tasks 也可以拆，这都是可以 planner 动态决定的。相当于有一个专门生成任务的 agent，和后面具体执行任务的 agent，可以用一个消息队列来解耦合了。

还有一个好的地方是，它的自愈性更强。之前用 workflow 代码驱动的场景，任务失败或者脚本 bug 的情况自愈是很难的。而这边，最坏的情况无非是一个任务本来应该由 generator 执行，由 evaluator 来验收， 而由于任务失败或者状态问题，退化成了 planner 自己来执行任务或者校验了。这不好，但是它至少能 work，能自愈。

我还感知到一个关于 long run harness 核心的点，就是可测试验证。只要想办法把 spec 变成可测试验证，design 做得好不好，重要性就下降了。就相当于定好宏观目标，给 agent 去微操，通过试错烧 token，大力出奇迹。 只不过这个在实践中，也是观察到，越做到后期，agent 越是每一个 phase 设计得越来越短，越来越不干活。就跟人类推进项目很像，前 20% 的时间推进了 80% 的进度，后面 80% 的时候推进那剩下的 20%，越推越推不动。

那个大型游戏项目的重写还是没写出来。但是至少算是更近一步吧，这些就是我在 long run harness 的一些探索。

回到开头的问题：个人能不能复现大公司的大型重写？答案是，目前还做不到完全自主的 long run，但 PGE 模式至少让 case 2 这个量级的项目变得可尝试了。每一步探索都在缩小差距，只是这个差距比想象中大。