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[1]，作者 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。等不够用了再加。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】