[开源推广] rasen - 基于 spec 的 harness 工程，一句话全自动 vibe coding。
项目地址： https://github.com/DumoeDss/rasen
文档站： https://rasen.io
安装：npm i -g @atelierai/rasen
第一次发帖，推广一下自己做的 harness/loops 框架，欢迎各位坛友试用，并给出一些反馈~ 这个框架算是蒸馏了我这一年多的 vibe coding 开发流程，也是边用边改，目前是我比较满意的版本。
先说明一下项目的起源（一些废话） 我使用 ClaudeCode 和 Codex 的开发的第一阶段是手搓流程。先让 agent 规划出文档，包含详细的任务列表。接着让 agent 开发，目标是任务列表全清。清完之后再起个 agent 去审查。每一个开发任务启动都需要手动一些 Prompt （比如告诉 agent 我要开发什么功能，你去给我调研一下，然后制定开发计划，编写开发文档），这个手搓流程我用了几个月，虽然也能用，但每次手搓 Prompt 都是重复工作。主流的两种开发模式 tdd(测试驱动开发)和 sdd(规范驱动开发)我也都有尝试，不过早期的 spec 项目都多多少少有些问题，要么是整体比较臃肿要么是流程不靠谱，开发出来的东西不太能用，我就维持手搓流程了。
在使用手搓流程几个月后我实在是不想再手搓 Prompt 了，于是决定升级一下流程，试了几天 openspec 发现当时的版本效果已经很不错了，就开启了由 opensepc 驱动的第二阶段。简单介绍一下 openspec 给不熟悉的坛友，openspec 并不是一个独立的框架，而是为 claudecode/codex 等 code agent 提供了一系列的 system prompt ，skills(与快捷 commands)。内置的工作流是规划写文档->开发->归档（ propose->apply->archive ），而且每个任务都会产出 spec 文档，作为后面开发的指导(知识积累)。对于一个任务使用方法是先开一个对话，使用/opsx:propose 调用 codecli 去编写 changes(计划)。然后新开一个对话/opsx:apply 执行开发。接着再新开一个对话/opsx:archive 归档。
靠着 openspec 的快捷指令，我再也不用每次手搓 Prompt 了，但是工具越好用，我就越懒，本质手动挡的 openspec 很快就满足不了我的需求，所以第二阶段到第三阶段的过渡很短。这段时间 openai 和 anthropic 都先后发布了 harness 相关文档，这些博客也都指导了我的设计。我决定动手提升一下我的工作流，于是 fork 了一份 openspec 开始魔改。
每个人对 harness 的定义都不同，我之前和群友争论了好几天，互相谁也没能说服谁。所以这里就只说我对于 harness 的理解: 我认为 harness 的核心是在 agent 的内循环之外创建流程化的外循环。交给 code agent 一个任务，code agent 自己去规划处理完成这个任务(包含调用 subagent 执行子任务，而且也不论这个任务是不是编码任务)，这个属于内循环。而 harness 能够从一个任务到另一个任务，一直推进下去，每个任务都是一个内循环，整个流程推进是一个外循环。比如 openspec 的 propose, apply, archive 都各自是一个内循环(每个任务跑在一个 session 中)，把 propose->apply->archive 串起来就是一个外循环。 我对于 openspec 的改造的第一步是创建一个简单的外循环: 依靠着主 agent-subagent 架构，把主 agent 作为 leader 控制外循环，每一个 subagent 负责一个模块的内循环任务。同时吸收了 gstack 和 grill me 为 pipeline 扩展了一些步骤。 一个标准的自动化 pipeline 为 planner(propose)->implementer(apply)->reviewer->fix-cycle(如果 reviewer 审查出实现有 bug ，就打回让 implementer 修复，修复完让 reviewer 重新审查)->ship(根据情况提交代码/开 pr 等)->archive ，核心优化是靠着 sendmessage 热恢复与 transcript 冷恢复，把 subagent 的会话复用与恢复(异常中断)。这里的设计包括 planner/implementer/reviewer 的复用，最初每个 subagent 都是新开一个 session 执行工作，然后我发现对于一个任务拆分的多个 changes ，如果每个 planner 都使用新的 session ，在任务启动的时候需要重新调研准备一堆上下文，才能制定编写文档。而如果复用上一个 changes 的 session ，就能够节省很多工作。而对于 implementer-review 循环，复用 session 的好处也是显而易见的。在这个简单的外循环实现之后，对于一个开发任务只需要使用/opsx:auto small-feature xxxx 命令就能够完成从规划到代码提交(或 pr)的流程。如果使用/opsx:auto full-feature xxx 则会先使用带有 grill me 的 office-hours 命令来细化需求。 在使用这个版本的过程中，我很快就发现了问题，一个 auto 命令执行的是一个 change 的循环，而对于一个复杂的任务，通常是需要拆分成多个 changes ，于是又加上了 auto-decompose 命令，leader 会先审查任务然后决定拆分成多个 change ，对每个 change 执行上面的 loops ，此时 leader 就负责控制多个小循环的大循环。 这个版本在运行起来之后，我发现由于 session 的复用，复杂的任务有很小的概率会达到 context 上限，再加上现在的 llm 通常只能在 30%-40% 左右的 context 达到满血状态，因此我添加了自动 handoff 功能，为每个阶段配置不同的 context 上限，比如 planner 配置 40% 的上限，implementer 配置 50% 的上限，在达到上限时，编写 handoff 文档，然后由 leader 派发 subagent 启动新的 session ，阅读 handoff 文档续接任务。(claudcode 自己的 compact 命令感觉已经废了几个月了，压缩后完全拿不到有效信息)
其他还有一些优化项加一起，fork 的版本已经和上游原版完全不一样了，从手动挡升级为了自动挡，因此我为其修改了新的名字: rasen(螺旋)。 螺旋的寓意是靠着 harness 把 loops 向着目标推进，虽然是 loops ，但不是圆，而是螺旋上升。(我的钻头可是突破天际的钻头啊！(
由于我自己日常开发是 python 和 react/nodejs 比较多，这些都是 llm 的舒适区，我自己用着效果都很满意，但我想知道这一套 harness 的极限在哪里。正巧大佬群友在使用 agent 进行一些 C#项目开发时，觉得推进非常困难，每次 subagent 在开始执行任务之前都需要调研，一个文件几百 k 大小，很快就把上下文塞爆，即使他自己拆分了很细的开发计划，依旧很难推进项目。于是我就 fork 了一个版本，交给 rasen 全自动处理(使用 glm-5.2)。在开发出 handoff 功能之前 rasen 可以自己工作 26+个小时推进任务，此时 lead 的上下文也仅占用 40% 左右。(具体可以查看 https://github.com/DumoeDss/ILRuntime/commits/features/object-model-overhaul/ )
ps.最近 gpt5.6 太阳更新后也能一口气工作几十个小时，不过我觉得 rasen 依旧是有优势的（
