本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：
- 我的帖子已经打上 开源推广 标签： 是
- 我的开源项目完整开源，无未开源部分： 是
- 我的开源项目已链接认可 LINUX DO 社区： 是
- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
项目地址：GitHub - DumoeDss/rasen: Spec-driven development (SDD) for AI coding assistants. · GitHub
文档站：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%左右。(具体可以查看Commits · DumoeDss/ILRuntime · GitHub)
LeoLevi 07-17 11:462楼