OpenAI 2 月发了篇 Harness Engineering 文章，讲他们用 Codex 搭了一个让 Agent 持续工作的执行环境。我读完觉得里面很多东西是可以蒸馏成 Claude Code Skill 的，花了点时间提炼了四个：harness（持久执行）、closed-loop-testing（闭环测试）、architecture-guardrails（架构约束）、harness-marathon（运行策略）。
用了几周，目前最长单次跑了 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，新代码必须通过，慢慢蚕食存量问题。
他们能做但我不考虑的
放松合并门禁。文章里有一段让我停顿了一下：
The repository operates with minimal blocking merge gates. Test flakes are often addressed with follow-up runs rather than blocking progress indefinitely.
这个在他们的场景（内部工具）可能合理。但我的场景有支付、订单这类业务，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，两边互相 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 的代码在我本地，后续会整理开源。有问题欢迎留言。