经过数周的实际应用，目前单次最长运行时间已达到 25 小时，任务一次通过率稳定在 80% 左右。本文主要分享蒸馏思路，并非 Skill 的具体使用手册。

读这篇文章时我的思考

OpenAI 那篇文章发布于 2 月 11 日，标题为 “Harness engineering: leveraging Codex in an agent-first world”，作者 Ryan Lopopolo。核心数据相当惊人：3 位工程师，5 个月，100 万行代码，零手写，每人每天产出 3.5 个 PR。

说实话，初次读完，最大的感受并非“好厉害”，而是“这不正是我一直想做的事吗”。

在让 Agent 执行长任务时，几个固定痛点会逐渐暴露：Context 重置后不知道上一轮做了什么；运行到一半觉得“差不多了”就停止；遇到模糊之处卡住等待确认。OpenAI 那篇文章清晰阐述了这些问题，并给出了他们的解决方案。

但他们的方案与现有工具链并不完全一致——他们基于 Codex 云端加上自研基础设施，而我这边是本地环境。因此问题变成了：如何将他们文章里的方法论蒸馏成可直接使用的东西？

蒸馏的过程

读文章时，我习惯将内容分为三类：可直接使用的机制、思路可借鉴但实现需要调整的部分、以及当前不考虑的内容。

可直接使用的机制

OpenAI 列举了几种做法，实现逻辑非常清晰，可以直接复用：

首先是“进度文件即上下文”。他们将 execution plans 和 decision logs 存储在仓库中，Context 重置后 Agent 读取这些文件即可恢复状态。这一点非常关键——后来 harness 中的 harness-tasks.json 加上 harness-progress.txt 就是源于这一思路，再结合一个 git log，三件事同时读取，10 秒内即可恢复会话。

其次是“AGENTS.md 当目录，不当百科全书”。他们尝试过“一个大 AGENTS.md”，结果失败了。总结的原因我也都经历过：文件过大挤占有效 Context，规则写太多等于没规则，而且一旦过期，Agent 无法分辨哪些规则仍有效。如今他们的 AGENTS.md 只有 100 行，作为导航地图使用，真正的知识放在 docs/ 目录中。这个机制直接纳入了 harness 的知识架构设计。

最后是“结构测试机械执行架构规则”。文章提到他们用自定义 linter 加结构测试来强制执行分层约束，lint 错误信息本身就包含修复指引。这一设计非常巧妙——Agent 违规时报错，报错信息直接告诉它如何修改，无需 Agent 再去查阅文档。这也成为了 architecture-guardrails 的核心。

思路可借鉴但实现需要调整的部分

先说“可观测性直接给 Agent 用”。OpenAI 的做法是为每个 git worktree 配置一套独立的 Victoria Logs、Metrics 和 Traces，Agent 可以用 LogQL、PromQL、TraceQL 进行查询。这个思路很好：让 Agent 能查询日志和指标，这样才能将“确保启动不超过 800ms”这类 Prompt 变成可执行的任务。

但我的场景更偏向业务流测试，而非性能调优。因此我没有为每个 worktree 安装一套可观测性栈，而是换成了“证据包”的概念：每个业务流测试完成后必须产出 verdict.json、请求响应记录、数据库快照和过滤后的日志，判定依据来自业务不变式，而非“脚本运行完毕”。这成为了 closed-loop-testing 的核心。

然后是“Entropy 管理”。OpenAI 提到 Agent 会复制仓库中的模式——好的坏的全复制，时间久了会产生 drift。他们起初每周花费 20% 的时间手动清理“AI slop”，后来改用 golden principles 加上后台 Agent 定期扫描修复。

我认同这一思路，但后台自动扫描还没有实施。现有方案是将 golden principles 编码成结构测试，在 CI 中运行，再加上 architecture-guardrails 中的 ratchet 策略：遗留违规加入 allowlist，新代码必须通过，逐步蚕食存量问题。

他们能做到但我暂时不考虑的

“放松合并门禁”。文章中提到一段内容：

这种情况在他们的场景（内部工具）或许可行。但我的场景涉及支付、订单等业务，flaky test 阻塞合并是基本卫生要求，并非可以权衡的选项。closed-loop-testing 中明确区分了哪些 check 是 blocking 的，这一块我没有与他们对齐。

“Agent-to-Agent review”。OpenAI 实现了 “humans may review pull requests, but aren't required to”，review 主要在 Agent 之间完成。我也实现了这一点，但方式不同：harness 交给 Codex 负责开发和写 PR，Claude Code 做 review，两者互相审查。Codex 写代码质量高，Claude Code review 速度快，这种分工效果比单一 Agent 自我 review 好不少。

四个 Skill 的由来

蒸馏完成后，需要解决的问题自然地分成了几个层次：

让 Agent 能持续运行，运行中断后能恢复——这是执行引擎问题，对应 harness。

让业务流测试有证据，判定来自不变式而非脚本退出码——这是验证问题，对应 closed-loop-testing。

让架构规则机械化执行，不依赖 Agent 自觉——这是约束问题，对应 architecture-guardrails。

让 Prompt 写完 Agent 就不会停——这是运行策略问题，对应 harness-marathon。

最后一个 harness-marathon 是我额外添加的，OpenAI 文章中并没有对应内容。它本质上是一套分析框架：Agent 停下来只有三个原因——工作耗尽了、遇到不确定的地方卡住了、Context 退化了。逐个攻克这三个原因，Agent 就能运行很长时间。

几周下来的运行情况

目前 harness 的单次最长运行记录是 25 小时。这并非特意为了刷记录而跑，而是一个较大的 Go 服务重构任务，子任务拆了 40 多个，跑完总共花了这么久。

任务一次通过率大约在 80%。剩余 20% 中，一半是需要人工介入的真实设计分歧，另一半是 Prompt 写得不清晰导致 Agent 理解偏差。后者可以继续优化，前者本来就应该由人来处理。

几个真实感受：

进度文件救了好几次。晚上跑着跑着 session 挂掉很正常，第二天打开继续跑。harness-progress.txt 里有完整的操作日志，Agent 读完就知道上次干到哪了。没有这个文件时，Agent 要花很长时间重新理解项目状态，还不一定理解对。

马拉松三定律中，Law 2 最容易被忽略。“Zero decision points”——提前将所有外部依赖写进 Prompt。说起来简单，但每次 Agent 中途停下，回头查基本都是漏写了某个依赖：测试数据路径、API key、某个已知 bug 的处理方式。这种停顿最浪费时间，也最容易避免。

Doom Loop 检测触发的频率比预想的高。在 harness 中我加了一个机制：同一个文件编辑超过 6 次报警，超过 12 次强提醒。每次触发，基本就是 Agent 在绕圈，当前思路走不通。这个机制 OpenAI 文章里没提，是我自己加的，实测非常有用。

V1/V2/V3 分阶段比一把梭稳很多。closed-loop-testing 将业务流测试分成三阶段：V1 测试内部可控路径，V2 加入外部回调，V3 产出完整证据包。以前直接跑 E2E，经常因为外部服务不稳定全部失败，需要重来。分阶段之后，V1 的成功率接近 100%，V2 如果外部挂了可以切换到 replay 模式，不影响整体进度。

Codex 开发加 Claude Code review 的组合比预期好。最初用单一 Agent 跑 harness 时，自我 review 的质量有限——Agent 写完代码再自己 review，容易忽略自己刚犯的错误。现在的方法是 harness 跑在 Codex 上负责开发和提交 PR，Claude Code 接手做 review，发现问题再推回去修改。两个 Agent 的训练方式不同，review 的盲区也不重叠，互相补充后 PR 质量明显提升。这与 OpenAI 所说的 agent-to-agent review 是同一思路，只是用了两个不同的模型来实现。

蒸馏思路的本质

回过头来看，将一篇技术文章蒸馏成可用工具，核心是问三个问题：

这个做法解决的是什么问题？不是“他们做了什么”，而是“为什么要这么做”。OpenAI 将 execution plans 存入仓库，本质上是在解决“Context 重置后状态恢复”的问题。把问题搞清楚，才知道换一种实现方式后是否同样解决了问题。

我的场景中这个问题存在吗？OpenAI 的可观测性方案针对的是性能调优场景，我的场景更多是业务流验证，问题存在但形式不同，因此实现也不同。

有没有更简单的实现能解决同一个问题？不是所有机制都值得完整实现。OpenAI 的 doc-gardening Agent 是一个后台定期扫描修复文档的 Agent，我的场景中结构测试加人工偶尔检查就足够了，没必要搭建那个 Agent。等不够用了再加。

这三个问题问下来，从一篇文章里能提炼的东西其实不多，但提炼出来的都是实用的。

Skill 的代码在本地，后续会整理开源。欢迎留言交流。