- 我的帖子已经打上 开源推广 标签： 是
- 我的开源项目完整开源，无未开源部分： 是
- 我的开源项目已链接认可 LINUX DO 社区： 是
- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是
start 介绍
这是一个轻量化同时让你的订阅物尽其用的harness 工作流。
github.com
GitHub - DoraemonHugU/oh-my-harness
通过在 GitHub 上创建帐户来为 DoraemonHugU/oh-my-harness 开发做出贡献。
下文称为 OMH
首先OMH是一个依靠Github PR的工作流，他借助了订阅中其他可以使用的额度来节省我们的必要的代码修改的codex额度。
在实际开发中，一个GPT plus订阅 + opencode go套餐就可以完成很不错的项目。
当前阶段我只做了Codex和Opencode支持，正在做其他平台的适配，如果有佬友对这个项目有兴趣，欢迎提交PR。
轻量化的OMH
OMH 只有四个 skill。
核心SKILL:harness
harness 核心循环: 1.收集信息(只读) → 2.制定plan(计划可写) → 3.实现plan(代码可写) → 4.审查实现(只读) → 5.反馈调整(默认可能回到1，2，3甚至4阶段)
辅助 SKILL(常规情况下，开发者不需要了解该三个skill的存在)来自 mattpocock的tdd skill的修改版本: 提供tdd开发策略。
来自 superpowers的systematic-debugging和receving-code-review skill的适配版本: 提供debug能力和接受代码审查的能力。
我的开发理念促生了OMH工作流
当下我们知道harness理念正火。 我对harness的理解就如上面所说的。
我的vibe coding的看法
-
让每个plan目标清晰明确。 一个plan你可以做多个事情，但前提是plan明确清晰，最佳策略还是一次plan一个任务。
这个产生于 PR 开发。 一个PR一般都任务很清晰，同时只做一个事情。
但是我为了提高效率，我一般会将几个小任务打包成一个实现pr，但是每个子任务都很明确。 -
放弃在主分支上直接进行实现。 改用分支(worktrees)进行实现
分支开发的优点:
- 不会影响主分支。 当任务实现我们不认可时，我们可以轻松的回退之前的版本。
- 支持更清晰的并发开发。 例如两个模块是无关的，我们可以一个分支开发A，一个开发B。
-
古人云:
知己知彼百战百胜-
知彼: 任务开始前，先进行信息收集。假设你要开始一件任务，你应该先去收集该任务的信息。 我喜欢主agent自己收集+子代理作为补充。 此时产生的是最纯净的上下文信息。
Q: 为什么是最纯净的上下文信息？ （点击了解更多详细信息） -
知己: 己是agent和我， agent负责写代码。 我们要做的是知道agent和我协作能解决什么问题？ 怎么和他交流？ 他可能会踩什么坑？ 等等。 这依赖我们对于agent的了解。
在我的看法中，要完成一个任务，你首先要做的就是收集足够清晰的信息。 信息不足，未来就会掉坑里。
-
-
更少的上下文腐败 >> 持有更长的上下文
-
多 agent 并发并不一定就更优。 不同目标清晰才是
比如之前的我，喜欢让多个agent讨论辨析，但事实情况好像是三个臭皮匠一讨论好像更臭了。 一个agent听了另一个agent的说法，就盲信了， 不信的话又需要重新的进行验证， 而多agent讨论出来的结果还会倾向于复杂化， 这在一些开发中是很不好的。
但在一些任务中，你应该依赖多agent去不同方向进行审查或者信息搜集，例如一个审查代码bug，一个审查静默失败等。 这样是多agent的合理用法。
-
如果可以，构建你的测试
因为 agent 是个react，只要你能找到问题并能进行反馈，那agent就可以开始进行修复。 考虑合适的工具进行e2e测试。 如果你的项目实现了合适的自我反馈的测试工具，那么agent就可以自动的修复工作。
-
合理分配不同阶段的模型
计划阶段需要强大的模型，实现阶段只需要次旗舰。 审查阶段应该是一个审查偏好的模型(未必是旗舰，因为旗舰模型写代码好，但是审查未必强)
让你的订阅物尽其用(以ChatGPT plus订阅为例)
Q: 我们购买了订阅，但是订阅都包含什么东西？
A:
plus具有抠搜的codex额度，但同时具有慷慨的每周三千次的网页端的5.5 thk模型的调用以及对个人开发而言够用的codex review云端审查(20-50/5h，仅有5h限制，不和codex额度共享。且由gpt 5.3 codex驱动)
Q: 我们的订阅，如果我们用于编程，都花在了什么阶段？
A:
1。 在生成plan之前的讨论是大头(对应harness的收集信息和制定plan阶段)，我们在这个阶段，Agent需要多轮的工具调用和生成回答， 对话导致变长的上下文更加剧的token的消耗。
2。 没有按照harness工程导致的代码质量差，最终导致的返工产生的消耗。
你阐述了你的需求，但未来实现忘掉了你的需求 或者 你没有审查你的impl是否对齐了你的需求
你可能没有遵循
harness循环。
3。 你的review阶段agent的消耗。 review阶段会是一个新的agent，reviewer会冷启动，不会利用你的上下文缓存，导致了你的花费。
4。 你的实现阶段， 这是一个较少的消耗。 因为在具有清晰的plan时，agent的实现将会目标清晰，是项目开发的必要消耗而非浪费。
Q: 基于上述的问题，我们应该怎么节省我们的token并发挥最大效果？
A:
解耦，让harness的不同阶段采用不同的策略。
我们可以看到harness循环， 1和2阶段是一种只读状态。
它无需进行代码修改。那为什么我们要用codex？ 与其我们不舍得使用codex的gpt 5.5 进行探索讨论。 为什么我们不把这个工作放到 GPT web端？ web端慷慨的5.5额度，而我们又不需要本地代码的修改。 而我们只需要该阶段生成任务plan。
3阶段，是一个必要的本地代码修改。在具有清晰的plan后，我们可以选择任何一个agent工具，无论是Codex还是cc接手plan，而且此时你可以选择一个次旗舰模型去实现plan，来实现更低的消耗。
例如我会选择gpt 5.4(他的额度是gpt 5.5的2倍，甚至我可以选择gpt 5.3 codex模型，又或者你可以选择ds模型作为worker，他会带来更低的消耗)
4阶段， 这也是个只读任务。 所以我们不需要用 codex 额度进行review。
Q: 如何使用上一个问题的策略那？
A:
策略: 只读操作不在codex中进行。 只在codex进行必要的编码
在1和2阶段，我们可以使用GPT web端 + github 连接器连接到我们的私有仓库，进行只读操作，然后可以生成PR以及对应的PR的plan。 (不建议直接使用连接器进行修改代码，因为他不能patch修改，只能重写，这样代码质量会很低)。 类似的Grok，notion和claude等也可以使用连接器链接到github仓库用于分析生成plan。
在3阶段，在本地的codex中使用 $harness 接手 pr11任务。 他就会拉取分支并读取plan并进行一次信息确定，然后开始实现任务， 实现后会自动触发云端的codex review。
4审查阶段， 审查的情况就交给云端的codex review，而不需要本地审查的token花费，且审查通常在10分钟内即可返回，此时本地的codex只需要耐心的等待即可。
我的经历和经验，废话太多了我就隐藏了， 未来有时间给佬友们好好分享下我的经验 （点击了解更多详细信息）OMH使用流程:
1。 首先你按照教程，用gpt，claude，grok 的web端链接到github 连接器。并绑定你当前的开发项目。并用 npx @doraemon-hug-u/oh-my-harness 初始化你的仓库。
OMH绑定仓库后
未来你的使用只需要在web端生成pr或者plan。 然后在本地的codex或者opencode调用harness skill并要求接手plan即可。
致谢
感谢 superpowers 和 mattpocock 社区提供的优秀的skill。
结尾
第一次写这个东西，难免写的不好，还望佬友们见谅。
项目问题以及关于我的上述讲述的问题，大家有任何疑问，欢迎佬友们在下面评论，我会逐个解答，并进行完善
如果有佬友对这个项目感兴趣，欢迎并感谢佬友们进行star，再次谢谢大家。
如果你对harness开发有自己的见解，欢迎评论区讨论或者提交PR，我们共同打磨这套工作流。
4 个帖子 - 3 位参与者