用 OMX 实践 Harness：把长任务开发变成可执行流程

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 协作、状态保存、长任务运行和验证闭环这些能力整理成一层更容易上手的脚手架。按当前命令面安装通常就是npminstall-goh-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 生态结合 DingClawOpenClaw、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 developmentoh-my-codex Docs: Documentationoh-my-codex Website: oh-my-codexCover image: MD Shakil on Unsplash