2127018&x-orig-expires=1776247441&x-orig-sign=pwYf72DusL8BIfT3FfyHfsXrWK8%3D)
Anthropic 在 Harness design for long-running application development 里讲得很清楚：做长时间运行的应用开发，关键不只是继续提升模型能力，更重要的是把外层框架，也就是 harness，设计好。
harness 这个词原本就有“系具、挽具、约束与连接装置”的含义，它强调的不是单一能力本身，而是如何把能力放进一个可控制、可重复、可验证的执行系统中。没有这一层，模型即使足够强，也容易在长任务里偏离目标，产生返工，或者停在一种表面完成、但实际上没有满足验收条件的状态。
我自己这段时间用 omx，也就是 oh-my-codex，去实践这件事，最大的感受是：真正有价值的不是把代码生成单独交给模型，而是把需求、架构、计划、执行和验证整理成一个可以反复运行的闭环。你给模型的不是一句模糊的目标，而是一套它必须遵守的工作约定。
Harness 的核心，不是更强的模型，而是更强的流程
如果只给 AI 一个目标，比如“帮我把这个功能做完”，那它很容易一边实现、一边猜需求、一边修改结构，最后再用一段自我评价式的话告诉你已经完成。这种流程在短任务里偶尔能工作，但任务一旦跨文件、跨模块、跨验证环节，质量就会迅速下降。
所以我更认同 harness 的思路：先把模型放进一个明确的执行框架里，再让它开始工作。这个框架至少要回答几件事情。
- 这次到底新增什么功能。
- 什么叫做“做完了”。
- 代码应该落在哪一层，为什么这样设计。
- 中间每一步如何验证。
- 如果最终验证失败，怎样回到子任务继续修正。
这一套东西，本质上是在补齐 AI 开发里经常被省略的软件工程部分。
我用 OMX 落地的一套实践
Specification / 设计阶段
我会先把设计阶段拆成两个问题。
第一个问题是，这次到底要新增什么，以及如何验证。这里我非常建议让有经验的工程师和 AI 一起完成，而且更适合先在 Claude、ChatGPT 这种网页版 AI 里完成。原因很现实：这一步主要是讨论需求边界、验收口径和失败案例，不需要消耗太多工程上下文，放在网页端做通常更省 token。
这一阶段里，最重要的不是“功能描述”，而是“验证标准”。模型必须知道最后要通过哪些条件，最好把它写成刚性的要求，例如：
- 相关单元测试必须全部通过。
- 新增接口必须覆盖正常路径和异常路径。
- 前端改动必须有自动化浏览器验证流程。
- 不允许破坏现有功能，回归检查必须通过。
我自己的经验是，只要验证标准写得不硬，模型就会倾向于提前结束；而只要验证标准足够清楚，它反而会更像一个真正的执行者。
第二个问题是，当前工程应该如何实现这项功能最合理。这个问题已经进入代码库上下文了，所以更适合放到 codex-cli、omx、cursor-cli 或者 Codex 客户端里做。这里我的做法通常是让模型输出一个 Architecture.md，里面至少写清楚三类信息：
- 功能拆解与边界。
- 关键实现路径，涉及哪些模块、文件和数据流。
- 最终验证要求。
Architecture.md 不是强制性的规范文件，它更像是你和模型之间的一份约定。放到传统软件开发里，它可以看作需求拆解与架构设计文档的轻量版本。
Planning / 计划阶段
有了 Architecture.md 之后，我会继续要求模型输出一个 planning.md。这里的重点不是把任务拆得多漂亮，而是每一个计划项都要带一个小的验证条件。
比如后端功能，可以是某个 UT 先补起来；前端功能，可以是某条自动化浏览器流程能先跑通。也正因为这样，我现在会非常明确地要求 AI 在开发里补齐 UT。原因不是为了追求覆盖率数字，而是为了给后续的执行阶段提供一个稳定的停靠点。
一个好计划通常有这些特征：
- 每一步的目标足够小，能独立完成。
- 每一步都有对应的验证方法。
- 前后依赖关系清楚，不会一开始就改动过多模块。
- 做完当前步骤后，能立刻判断是继续还是回退。
如果你愿意进一步工程化，这一步还可以顺手接到 CI/CD，比如自动提测、自动构建、自动部署。但在我看来，那是 harness 成熟后的扩展项，不是第一天就要堆上的东西。
Execution / 执行阶段
执行阶段反而最不神秘，就是要求模型按照 planning.md 一项一项实现，而不是在上下文中自由扩展。
这件事听起来很普通，但它能明显减少两类问题：一类是模型偷偷跳步，另一类是模型改到一半开始重构整个项目。长任务里更常见的问题，不是模型能力不足，而是模型在缺少约束时过早扩展。计划文件的意义，就是把“下一步做什么”这件事固定住。
Verification / 验证阶段
所有实现完成后，不应该只看测试绿不绿，还要回到 Architecture.md，逐条检查设计阶段定义过的验证要求是不是都实现了。
如果没有全部实现，我更推荐继续拆成子任务，重新回到这套流程里，而不是让模型在同一轮会话里凭印象去补。因为一旦进入“看起来差不多”的状态，长任务的质量会掉得很快。
这也是我理解 harness 最重要的一点：验证不是收尾动作，而是下一轮任务分解的入口。
OMX 在这套流程里怎么用
omx 的定位并不是替你定义 harness，而是把多 agent 协作、状态保存、长任务运行和验证闭环这些能力整理成一层更容易上手的脚手架。
按当前命令面，安装通常就是：
npm install -g oh-my-codex
omx setup
omx doctor
平时直接运行 omx，它会启动 Codex CLI，并把 OMX 的工作流能力带进来。
有两个启动参数我觉得值得单独说一下。
--high：把推理强度提高到 high，更适合规划、设计和复杂执行。--madmax：跳过审批与沙箱，是高风险模式，适合你明确知道当前环境和命令副作用时使用。
所以像 omx --madmax --high 这种组合，本质上就是更高推理强度配合更少执行限制的工作方式。效率会提升，但风险也会随之上升，尤其是在会执行脚本、改动较多文件、或者会触发外部副作用的项目里。
在流程起点上，如果你想先把 agent 约定放进项目里，OMX 当前更直接的命令其实是：
omx agents-init
# 或者
omx deepinit
它会为目标目录和直接子目录生成轻量的 AGENTS.md。有些客户端里大家会习惯从 /init 开始，但从 OMX 本身的命令面来说，更准确的是 agents-init / deepinit 这套入口。
至于长任务，我自己最常用的是两个能力。
一个是 omx ralph。它适合长时间、需要持续推进和反复验证的任务。你可以把它理解成一种 persistence mode。它不是让模型一次性冲到底，而是让模型持续围绕目标工作，并把阶段性状态保留在 .omx/ 里。
另一个是 omx team。它适合明显可以拆开的并行任务，比如一个 agent 看架构，一个 agent 补测试，一个 agent 改实现。当前文档里它默认会给 team worker 使用独立 worktree，这一点很重要，因为并行任务一旦共用工作区，就很容易互相覆盖。
在我的实际使用里，比较自然的一种节奏是：
- 先用网页版 AI 把 Specification 整出来。
- 再进
omx让它结合代码库产出Architecture.md。 - 然后继续让它写
planning.md。 - 小任务用单 agent 按计划执行。
- 明显可并行的块再交给
Ralph或Team。 - 最后回到验证要求做总验收。
这比直接要求 AI 完成整个需求更慢一些，但过程更稳定，结果也更容易复核。
我对 OMX 的一些真实看法
omx 很适合拿来做 harness 的初上手实践，因为它已经把很多必要的工程化能力搭好了，比如状态、团队协作、命令入口、技能路由和长任务模式。你不用从零开始搭自己的 agent 编排层，就可以先把这套流程运行起来。
但我更想强调的是，初上手实践并不意味着最终定型。随着你对 harness 的理解越来越深入，你很可能会逐步形成自己的方法论，对流程拆分、验证方式、状态管理和 agent 协作边界都有新的判断。到那个阶段，omx 未必还是你的最终工具选择，它更像是一套帮助你进入这个问题域的现成脚手架。
而且 omx 自身也仍然处在持续迭代中。它今天提供的命令面、技能体系和团队运行方式，能够很好地支持实践，但并不意味着它已经构成了一个固定不变的最终形态。
但它也不是没有代价。
第一，Ralph 和 Team 在长任务里都可能出错，尤其是你把任务做得比较激进、会话中断比较频繁，或者工作区本身状态比较复杂的时候。它有时会进入 shutdown，这时候恢复并不是完全零成本的。
第二，.omx/ 在 team 中断后可能留下不少中间状态和垃圾文件。理论上这些是为了恢复和追踪准备的，但如果保存和清理没有跟上，目录会很快变得臃肿。真正高频使用时，恢复、清理和继续执行会变成额外的维护成本。
第三，token 消耗非常大。这个问题不能只怪 OMX，本质上是长任务、多 agent、长上下文本来就贵。但从实际体验来说，复杂任务跑上两三个，就足以明显吃掉 ChatGPT Plus 里 Codex 的周额度。在我自己的使用里，这已经不是抽象问题，而是很具体的成本问题。
所以我的结论不是“OMX 已经定义了 harness 的标准答案”，而是它很适合作为一套现成脚手架，让你先开始实践自己的 harness。harness 现在本来就还没有固定流程，真正适合自己的方式，往往需要在具体项目中逐步形成。
如果你准备高强度使用这类工作流，我会认真考虑自部署至少 32B 以上的模型，或者把“网页端做需求与设计，CLI 端做代码与验证”当成默认分工。前者是降低成本，后者是把贵的上下文留给真正需要代码库信息的阶段。
企业级场景下的 Harness 实践延伸 —— 鼎道智联的探索
在基于 OMX 完成 harness 基础实践后，我们也在思考如何将这套流程适配到企业级 AI 开发场景中。鼎道智联围绕 DingOS 生态，结合 DingClaw（OpenClaw）、PSUIP协议，在 OMX 实践的基础上尝试做了一系列企业级的适配与延伸：
-
从能力补充来看，DingClaw在多 Agent 并行协作、长任务状态持久化的基础上，增加了企业级场景必需的权限管控、流程审计能力，让 harness 框架不仅能落地，还能符合企业研发的合规要求；PSUIP 则将 harness 流程中的设计、验证环节与企业级产品的交互规范对齐，让 AI 产出的架构设计、验证标准更贴合实际产品交付的要求；AIGUI 则聚焦于降低 harness 流程的使用门槛，通过可视化的交互方式，让非技术背景的产品、测试人员也能参与到验证标准定义、流程节点确认的环节中。
-
从成本与效率层面，DingOS 生态下的私有化部署能力，可有效降低长任务、多 Agent 协作带来的 token 消耗成本，同时结合场景化的上下文裁剪策略，进一步优化企业级场景下的资源投入。此外，针对 OMX 长任务中断后状态恢复、垃圾文件清理的问题，我们也在 DingOS 中做了自动化的状态管理与目录清理机制，减少人工维护成本。
-
整体而言，鼎道智联的探索并非替代 OMX 这类工具，而是在其搭建的 harness 基础流程上，补齐企业级落地的关键能力，让 harness 从 “技术团队的实践工具” 真正变成 “企业级 AI 开发的标准化流程”。
总结
这些就是我现在对 AI 开发比较稳定的判断：不要只追求模型更强，而是要让模型被放进一个更可靠的 harness 里。真正决定长任务成败的，经常不是模型回答得多聪明，而是你有没有提前定义好它该如何被约束、如何被验证，以及失败之后如何回到流程中继续前进。
参考
- Anthropic: Harness design for long-running application development
- oh-my-codex Docs: Documentation
- oh-my-codex Website: oh-my-codex
- Cover image: MD Shakil on Unsplash
