过去一个月，我一直在想一个问题。

手里有 Claude Opus 4.6，有 GPT-5.4，有 Codex 和 Claude Code。按理说，模型能力已经足够强了。但每当我想让它们自己在服务器上跑几个小时，去完成一个稍微复杂一点的任务——比如复现一篇论文的 baseline，或者从零搭一个工程项目——它们总是在中途出问题。

要么 context window 用完了，下一轮 agent 完全不知道之前发生了什么，花大量时间重新搞清楚状况；要么做到一半，环顾四周觉得「差不多了」就停下来了，但其实核心功能根本跑不通；要么越跑越偏，最后的产出和最初目标南辕北辙。

带着这个困惑，我注意到了 2026 年初密集出现的一个词：Harness Engineering。

Harness 是什么

Harness 的字面意思是「马具」。想象一下：AI Agent 是一匹动力十足但不太守规矩的马，在一片蛮荒之地——到处是 bug 的代码库、各种环境问题、危险的边界条件——里奔跑。Harness 就是你给这匹马套上的缰绳和马鞍，让它既能跑得快，又不会跑偏或把自己摔下悬崖。

宝玉在推文 [6a] 中梳理了三个阶段的演进：

  1. Prompt Engineering（2023-2024）：怎么跟 AI 说话。优化单次的输入和输出。
  2. Context Engineering（2025）：给 AI 看什么信息。设计系统提示、对话历史、RAG、工具调用的整套信息环境。
  3. Harness Engineering（2026）：构建什么环境让 AI 工作，如何保证它的产出可靠。比 Context Engineering 更进一步——管的不只是输入给模型的信息，还有模型之外的整个执行环境。

另一位作者 George 在宝玉转译的文章 [6b] 中给出了一个更有意思的视角：这个模式在历史上出现过三次。18 世纪瓦特的离心调速器让工人从「拧阀门」变成「设计调速器」；2010 年代 Kubernetes 让工程师从「重启服务」变成「编写声明式规格」；2026 年 Harness Engineering 让开发者从「写代码」变成「设计环境和反馈循环」。三次都是同一个控制论模式：当传感器和执行器足够强大时，反馈回路在更高层面闭合，人的角色从执行变为校准。

从极简到重型：六种方案

我集中读了六篇围绕 Harness Engineering 的代表性文章。它们各自侧重不同的问题，但都在回答同一个核心疑问：怎么让 AI Agent 在长时间运行中保持有效？

按复杂度从简到繁排列，这六种方案可以画出一条清晰的谱系。

一、Karpathy 的 AutoResearch：630 行代码的极简循环

Karpathy 开源的 autoresearch [4] 可能是最简洁的 harness。核心设计只有一句话：人写 prompt（.md 文件），agent 写训练代码（.py 文件），每 5 分钟跑一次完整的 LLM 训练，用 validation loss 判断好坏。

如果这轮 loss 更低了，agent 就把改动 commit 到 git 的 feature branch 上。然后继续下一轮。

简洁到这个程度是有前提的：ML 训练有天然的数值化评估标准。Validation loss 就在那里，不需要人来定义什么叫「好」，不需要额外的 evaluator agent，不需要 Playwright 去测试 UI。agent 跑出一个数字，比上一轮低就是进步。

二、lidangzzz 的 Goal-Driven：一段 prompt 就是整个框架

立党的 goal-driven [5] 比 Karpathy 的方案多了一层：他引入了 master agent 和 subagent 的分离。但令人惊讶的是，整个「框架」就是一段精心设计的 prompt 模板，没有一行代码。

核心逻辑是一个 while 循环：

1
2
3
4
5
6
while (criteria 未达成) {
    subagent 持续工作
    master 每 5 分钟检查一次
    如果 subagent 停了或声称完成 → 验证 criteria
    如果没过 → 重启 subagent 继续
}

最有意思的设计决策：prompt 里明确写着「DO NOT STOP THE AGENTS UNTIL THE USER STOPS THEM MANUALLY FROM OUTSIDE」。这看起来很暴力，但确实有效。他用这套方案让 agent 持续工作 100 多个小时，全自动实现了 SQLite 的 Rust 版本（约 30 小时）和 TypeScript 编译器的 C++ 版本（约 100 小时）。

不过有一个硬性前提：criteria 必须是客观可验证的。「2000 个测试用例全部通过」可以用这套方案；「这个界面好不好看」就不行。

三、Anthropic V1：跨 Session 的接力赛

Anthropic 的第一篇博客 [1] 解决的是一个非常具体的工程问题：context window 用完后，下一轮 agent 怎么接上？

他们观察到两个失败模式。第一，agent 喜欢 one-shot——试图一次做完所有事，context 用到一半还没做完，下一轮 agent 面对一个半成品不知所措。第二，agent 在项目有了一定进展后，容易看看四周觉得「工作完成了」就停下来。

解决方案是两个 agent 的分工：

  • Initializer agent：第一轮运行时，把用户的 high-level 需求展开成 200 多条 feature list（用 JSON 格式，因为模型「更不容易不当修改 JSON」——这是个实践中摸索出来的细节），设置好开发环境，写一个 init.sh 脚本。
  • Coding agent：后续每轮运行时，先读 progress 文件和 git log 搞清状况，然后只做一个 feature，做完 commit，更新进度文件，保证代码处于可合并状态。

关键洞见是：每个 session 结束时，代码库必须处于 clean state——就像你下班前把桌面收拾干净，明天来的同事能直接开始干活。

四、Anthropic V2：品味也可以打分

Anthropic 的第二篇博客 [2] 在 V1 基础上做了大幅升级，引入了 GAN 启发的三 agent 架构：Planner（展开需求）、Generator（逐个实现）、Evaluator（交互式测试 + 打分）。

这篇文章解决的核心问题不再是「能不能完成」，而是「完成的质量好不好」。作者发现，让 agent 评价自己的产出时，它倾向于自信地赞美自己的工作——哪怕在人眼里明显平庸。把「做事的」和「评判的」拆成两个 agent 是解决这个问题的关键杠杆。

更有意思的是 evaluator 的校准过程。作者定义了四个维度——设计质量、原创性、工艺、功能性——刻意给前两者更高权重，因为模型默认在工艺和功能上就不错，但在设计和原创性上经常产出「AI slop」。

这篇文章还有一个坦诚的观察：harness 的每个组件都编码了一个关于模型不能做什么的假设，这些假设值得持续压力测试。他们从 V1 升级到 V2 时砍掉了 sprint 机制，因为 Opus 4.6 原生就能处理长任务，不再需要人为分解。harness 设计是动态的，随着模型进步要不断精简。

五、OpenAI：百万行代码的长期治理

OpenAI 的博客 [3] 是六篇里覆盖面最广、规模最大的。他们的团队（3 人起步，后扩至 7 人）做了一个极端实验：5 个月，0 行手写代码，完全由 Codex agent 生成了一个有真实用户的内部产品。百万行代码，约 1500 个 PR，平均每人每天 3.5 个。

跟前面几种方案相比，OpenAI 要回答的问题更进一步：agent 跑完了一个任务，那代码库的长期可维护性怎么办？

他们的核心贡献是一套以仓库为中心的知识管理体系。早期试过一个大 AGENTS.md 文件塞进所有指令，失败了——context 是稀缺资源，什么都「重要」等于什么都不重要。最终方案是 progressive disclosure：AGENTS.md 只有约 100 行，充当目录；详细知识分散在 docs/ 下的结构化文档中，agent 按需查阅。

另一个独到的贡献是对 entropy 的处理。他们发现 agent 会复制代码库中已有的模式，包括不好的模式，导致质量漂移。最初每周五花 20% 时间手动清理「AI slop」，后来改成了自动化：将品质标准编码为 golden principles，定期跑后台 agent 扫描偏差并自动开 PR 修复。就像垃圾回收——持续小增量偿还技术债。

六、dotey 的理论框架

宝玉的两篇推文 [6a][6b] 不是一手的工程实践，但提供了把前面五种方案串起来的理论视角。三阶段演进和控制论类比前面已经提到了。他转译的文章里有一句话特别精准：

「智能体失败，大多时候不是因为能力不够，而是因为它需要的知识——什么叫好、架构鼓励哪些模式、回避哪些模式——锁在你脑子里，你从没把它外化出来。」

让判断力变得机器可读——这句话是对整个 Harness Engineering 的高度概括。

六篇文章的共识

读完这六篇文章，有几个结论跳了出来。

做事和评估一定要分开。 这是最强的共识。Anthropic [2] 用 generator-evaluator 分离；lidangzzz [5] 用 master-subagent 分离；OpenAI [3] 用 agent-to-agent review。大家不约而同地发现：让同一个 agent 既干活又判断质量，它会倾向于高估自己的产出。

Agent 过早放弃是最常见的失败模式。 Anthropic [1] 叫它「premature declaration of completion」，Anthropic [2] 叫它「context anxiety」，lidangzzz [5] 整个框架的存在理由就是对抗这个问题。解法各不相同，但问题一样。

所有状态都通过文件系统外化。 没有任何方案依赖 agent 的「记忆」。progress 文件、git commit、plan 文档、feedback 文件——全部写在磁盘上。Agent 的 context 是短暂的，文件是持久的。

关键的分歧

反馈信号的性质决定了 harness 的复杂度。 Karpathy 有 validation loss，lidangzzz 有通过/不通过的测试用例，所以它们的 harness 可以极简。Anthropic [2] 要评估设计品味，OpenAI [3] 要维护架构一致性，所以需要更复杂的评估机制。

简洁和系统工程之间的张力。 lidangzzz 的一段 prompt 实现了编译器；OpenAI 的一整套 repo 工程体系维护了百万行产品。两者都是正确的，因为面对的问题不同。简单任务上重型 harness 是浪费；复杂任务上极简方案撑不住。选择取决于任务的可验证性 x 运行时长这两个变量。

这篇文章没有覆盖的

有几个问题在六篇文章中都没被充分讨论：成本效率（100+ 小时的 token 消耗到底花多少钱？）、失败案例（各方倾向于展示成功，harness 的边界在哪里？）、非编程领域的 harness（能推广到科学研究或写作吗？）以及自动构建 harness 的元工具——根据任务的难度和可验证性，自动决定该用哪种方案。这最后一个可能是下一步的研究方向。

下一篇文章，我会讲自己动手搭 harness 的过程——从参照 OpenAI 的文档系统（跑了 1 小时）到参照 Anthropic 的三 Agent 架构（跑了 10 小时），两轮迭代中踩过的坑和学到的东西。

参考文献