Harness 工程是指围绕模型构建的一切，让 Agent 能够完成真实的工作：指令、工具、状态、验证和范围。Anthropic 测量了什么，Learn Harness Engineering 课程和 MemoHarness 论文补充了什么，有哪些坑，以及 FDE 如何在客户现场搭建一套 harness。
作者：LUKAS HOFFMANN · FDEINTERVIEWS 编辑部 · 更新于 2026 年 10 月 7 日 · 阅读时长 10 分钟
动手练习：RAG 与 Agent 设计问题 ·Agentic 评测与轨迹的概念 ·生产级 AI Agent 课程 ·必知的 FDE 问题
Harness 工程是围绕语言模型构建一切的工作，目的是让 Agent 可靠地完成真实任务：它读取的指令、它可以调用的工具、它在会话之间保存在磁盘上的状态、判断工作是否完成的检查，以及它可以触及的范围限制。 模型决定写什么代码。Harness 决定何时、何地、如何写，以及结果是否算数。这个术语在 2025 年底和 2026 年间传播开来，因为 OpenAI 和 Anthropic 公布了他们如何让编程 Agent 连续运行数小时，而现在有两个开源项目在教授和测试它：walkinglabs 的 Learn Harness Engineering 课程（MIT 许可，截至 2026 年 10 月 7 日约 19,400 个 GitHub star）和 MemoHarness 研究代码，后者试图从 Agent 自身的运行中学习 harness 设置。本文解释这一模式、每个项目的贡献、其中的坑，以及前沿部署工程师如何在客户的代码仓库中搭建 harness。
同样的模型，不同的 harness：证据
最清晰的数据点来自 Anthropic 关于长时间应用开发 harness 设计的工程博客（2026 年 3 月 24 日）。作者给同一个模型同样的单句提示词——一个 2D 复古游戏编辑器——运行了两次。单独运行时，它工作了约 20 分钟，花费约 9 美元，产出的应用其游玩模式无法使用。在一个三 Agent 的 harness（规划器、生成器和评估器）中运行时，它工作了约 6 小时，花费约 200 美元，产出的编辑器可以真正移动角色并游玩一个关卡。
| Solo agent | Planner, generator and evaluator harness | |
|---|---|---|
| 时长 | 约 20 分钟 | 约 6 小时 |
| 成本 | 约 9 美元 | 约 200 美元 |
| 范围 | 模型自行选择构建的内容 | 规划器将提示词扩展为跨越十个冲刺的 16 项功能规格 |
| 核心功能（游玩模式） | 无法使用 | 可用，但物理边缘效果粗糙 |
诚实地读一下：这只是一个提示词和一次对比，而 harness 运行的成本大约高出 22 倍。有用的结论不是“harness 更便宜”，而是模型的上限并不是瓶颈。harness 改变了同样的权重能完成什么，而剩下的差距（一个不清晰的工作流、玩家无法越过的墙）属于产品判断，harness 从未被要求去检查这些。
同一篇帖子还包含了最具可迁移性的经验。把执行工作的 agent 和评判它的 agent 分开是一个强有力的杠杆，因为把一个独立的评测器调教得足够挑剔，远比让生成器对自己的工作保持批判性容易得多。评测器被赋予了一个浏览器工具，可以在打分之前实际点击运行中的应用，而不是对着截图打分。
想自己构建一个吗？面向 FDE 的 Harness 工程带你走完编码和采购 harness 的全过程，包含实战练习、恢复测试和九个项目。从关于 harness 边界的免费课程开始。
Harness 的五个组成部分
Learn Harness Engineering 课程将工作组织为五个子系统。图中将它们展示为围绕模型的一个环。
- 指令告诉 agent 要做什么、先读什么。不是一个巨大的文件：一个简短的入口，映射到 agent 在需要时会打开的更深入的文档。OpenAI 的 harness 工程文章提出了同样的观点，把 AGENTS.md 视为结构化文档目录的目录索引，而不是一本百科全书。
- 工具是 agent 的双手：MCP 服务器、shell、网页抓取、数据库客户端。每个工具都需要明确的范围和清晰的失败信号，因为一个没有报错就失败的工具会让 agent 在毫无依据的情况下空转推理。
- 状态在上下文窗口之外存活：进度日志、功能清单和 git 历史，全部保存在磁盘上，这样下一次会话就能从上一次停止的地方继续。
- 验证是唯一算数的证据：测试、lint、类型检查、冒烟运行，或一个独立的评测 agent。没有验证，agent 不得宣布胜利。
- 范围与会话生命周期让 agent 一次只做一个功能，每次会话以初始化脚本开始，并以一个别人可以合并的状态结束。
在采用这套词汇之前有一个坑：课程本身使用了两个清单。主框架命名为指令、状态、验证、范围与会话生命周期，而它的前沿产品拆解（Claude Code、Codex、Pi 和 DeepSeek）则使用指令、工具、环境、状态和反馈。它们从不同的切面描述同一块地盘。为你的团队选定一个清单并坚持使用。
Harness 在磁盘上是什么样子
Anthropic 早前关于面向长时间运行 agent 的 harness 的文章（2025 年 11 月 26 日）给出了具体版本。第一次会话运行一个带有不同提示词的初始化 agent。它会写入一个
init.sh
、一个进度文件和一个初始 git 提交，并将用户的请求扩展为功能列表。在他们的示例中，该列表超过了 200 个功能，每一个都被标记为失败。之后的每个会话都会运行一个编码 Agent，它读取进度文件和 git 日志，挑选一个失败的功能，实现它，验证它，用描述性的信息提交并更新日志。
repo/ AGENTS.md # about a page: what this is, where to look, how done is decided docs/ # architecture, guardrails, decisions; opened on demand feature_list.json # every feature, each "passing": false until verified progress.md # what the last session did and what is next init.sh # install, start services, run the smoke test
有两种失败模式促成了这种设计，你在客户的代码库中也会看到这两种情况。早期，Agent 试图一次性构建所有内容，结果中途耗尽上下文，留下一个损坏的代码树。后来，一个全新的 Agent 四处查看，看到大量代码，便宣布项目已完成。单功能规则解决了第一个问题；全失败的功能列表解决了第二个问题，因为“完成”成为列表的属性，而不是 Agent 的情绪。
运行本网站的代码库就是这样工作的。它的 AGENTS.md 是一页简短的约束性规则，指向单独的文档，涵盖防护栏、架构、设计决策和内容标准，而构建门禁就是“完成”的定义。跳过门禁的 Agent 会被门禁抓住，而不是被阅读其总结的评审者发现。
学习 Harness 工程：课程
walkinglabs 代码库是一个基于项目的课程：14 讲、8 个项目、翻译成 15 种语言、MIT 许可。它的优势在于每个模块都构建一个可运行的产物，而不是总结观点。一个
harness-creator
技能可以为你的项目搭建上述文件的脚手架。第 13 讲讲循环工程（一个制造 Agent 和一个检查 Agent 基于目标或定时器运行），第 14 讲讲图工程，用于一个循环变成多个共享状态和路由的节点的情况。2026 年 8 月的故障分析将五部分框架应用于四个前沿产品如何构建它们的 harness。
请将其视为对公开材料的结构化综合。它的核心参考是 OpenAI 和 Anthropic 的帖子，其标题数字也来自它们。当 README 说 Anthropic 进行了“受控实验”时，请查看原始来源：那只是一个提示词以两种方式运行，这是有用的证据，但不是受控研究。
MemoHarness：一个从自身运行中学习的 harness
MemoHarness（arXiv 2607.14159，2026 年 7 月，十位作者）提出了一个更尖锐的研究问题。大多数团队为每个任务部署一个固定的 harness。能否改为从执行历史中调整 harness，并针对每个任务进行专门化，且在测试时无需标签？
该论文将 harness 分为六个可编辑的维度：
| 维度 | 控制的内容 | 示例编辑 |
|---|---|---|
| D1 上下文组装 | 什么进入模型输入 | 重构提示词、添加示例、压缩上下文 |
| D2 工具交互 | 工具和检索何时以及如何运行 | 启用检索、设置 top-k、重排证据 |
| D3 生成控制 | 解码设置 | 提高令牌预算、降低温度、采样候选 |
| D4 编排 | 模型调用的序列 | 一次调用变为规划、执行、精炼 |
| D5 记忆管理 | 跨调用持久化的内容 | 保存状态、总结轨迹、丢弃过时的上下文 |
| D6 输出处理 | 将原始输出转化为答案 | 提取、校验 schema、选择回退方案 |
在阶段 A，控制器在带标注的案例上搜索对这些维度的编辑。它首先按任务奖励排序，token 成本仅作为平局时的参考，并将每个案例的诊断结果以及提炼出的全局模式（什么有效、什么失败、它们如何相互作用）存储在双层经验库中。在阶段 B，一个新的无标注案例从冻结的经验库中检索相似的案例和模式，学习到的全局 harness 在执行一次之前针对该案例进行适配，测试时没有标签、反馈或额外的搜索轮次。
README 中的结果图表是值得认真阅读的诚实部分。在 FinanceAgent 上，成功率从 42.5% 上升到搜索迭代第 8 和第 9 轮附近的 65.0% 峰值。在 LiveCodeBench 上，它几乎立即在基础模型的上限附近饱和，随后在约 4 个百分点的区间内波动。因此，harness 搜索在任务需要多步工具使用和判断的地方帮助最大，而在模型本身已接近极限的地方几乎无关紧要。作者明确表示，关于统计稳健性以及哪个组件带来了提升的更广泛结论留待未来工作。
克隆之前的一些实用提示。它在 Harbor 加 Daytona 沙箱环境中运行 Agent，并需要一个模型提供商的密钥。而且截至 2026 年 10 月 7 日，该仓库没有许可证文件。没有许可证，你可以阅读代码并从该方法中学习，但你没有被授予将其复制到客户代码库中的权利。
在实践中运行 harness 的坑
- 评估器默认是宽容的。 用模型来给模型输出打分往往偏于宽松。用一些已打分的示例来校准评估器，给它一种运行产物的方式（浏览器、测试运行器），并尽可能让最终关卡保持确定性。
- Agent 会篡改记分板。 METR 在 2025 年 6 月报告称，前沿模型在获得编码任务时，会试图通过修改测试或评分代码来提高自己的分数。保护功能列表和检查项：Agent 只能通过验证命令更新“通过”标志，对测试文件的更改需要人工审查。
- 静默的工具失败看起来像推理问题。 一个返回反爬虫页面的网页抓取，或一个在超时时返回空列表的 MCP 服务器，会给模型提供看似合理却毫无用处的内容。让工具返回明确的错误，并将工具结果与模型输出一起记录，这样你就能看出是哪一个失败了。
- 上下文在任务完成之前就耗尽了。 长任务要么需要压缩，要么需要干净地重置并把状态保存在磁盘上。Anthropic 的测试框架在早期模型上使用重置，而在后来的模型上可以去掉重置，这也是无论如何都应把状态保存在磁盘上的一个原因：你可以更换模型而不必更换测试框架。
- 成本随可靠性而变化。 9 美元与 200 美元的对比就是可以预期的形态。为每个任务和每个会话设定预算，并按每个已验证功能来衡量成本，而不是按每次运行来衡量。
- 指令会腐化。 第一周写的 AGENTS.md 描述的是第六周已不复存在的仓库。要像对待代码一样对待它：简短、经过评审，并在使其失效的同一变更中更新。
FDE 视角：在客户处搭建测试框架
前沿部署工程师会遇到这样一个具体诉求：“我们买了编码 Agent 的席位，为什么在我们的 monorepo 上输出不可靠？”答案很少是换一个模型。有用的第一周是这样的：
- 第 1 天： 像一个 Agent 那样阅读仓库。一个陌生人能否在五分钟内找到构建命令、测试命令和“完成”的定义？如果不能，就写一份简短的 AGENTS.md 说明这些，并指向已有的文档。
- 第 2 天： 让验证只需一条命令。大多数企业仓库的测试需要数据库、VPN 或密钥。没有可运行检查的测试框架只是一个意见箱。把测试运行容器化，或提供一个 fixture 路径。
- 第 3 天： 添加状态。为当前的工作项准备一个进度文件和一个功能清单，与代码一起提交，以便会话和人员之间可以交接。
- 第 4 天： 限定工具范围。哪些 MCP 服务器、哪些凭据、哪些目录可写。Agent 沙箱和最小权限是客户安全团队最先提出的问题，所以要在他们提问之前就给出答案。
- 第 5 天： 进行度量。从待办事项中选取十个真实任务，分别在有和无测试框架的情况下运行，以测试结果评分，并记录成本。这张表格就是赢得下一阶段的资本。
这如今也是一个面试话题。“你会如何让编码 Agent 在客户的遗留代码库中变得可靠？”这是一个 Agent 系统设计问题，而优秀的回答会先提到验证、持久状态、限定范围的工具和有度量的基线，然后才会提到任何模型。Agentic 评测与轨迹概念介绍了如何为运行打分，FDE Agent 的上下文窗口管理介绍了状态问题，而 Agent 与工作流概念则介绍了什么时候根本不应该把循环交给模型。关于上下文这一半的内容，请参阅为什么上下文工程取代了提示词工程，并在 RAG 与 Agent 和系统设计中练习这些设计问题。
把它变成 offer。练习这个问题所对应的真实问题和概念：
FAQ
Harness 工程是指围绕语言模型设计的一切，使其成为你可以信赖的 Agent：它读取的指令、它可以调用的工具、它在会话之间保留的状态、判断工作是否完成的检查，以及它所能触及范围的限制。模型负责写代码；而 harness 决定何时、何地、如何写，以及结果是否算数。
提示词工程塑造的是单次请求。上下文工程决定每一步进入模型窗口的内容。Harness 工程则是整个控制层：它包括上下文组装，还包括工具访问权限、磁盘上的持久化状态、验证、多个模型调用的编排以及会话生命周期。一个好的提示词无法阻止 Agent 在测试失败时宣称任务完成；而 harness 可以。
两者都有。在 Anthropic 2026 年 3 月的文章中，同一个模型单独运行约 20 分钟、花费 9 美元，产出了一个游戏编辑器，但其游玩模式无法使用；而一个由规划器、生成器和评估器组成的 harness 运行了约 6 小时、花费 200 美元，产出了一个可以游玩的编辑器。这只是同一个提示词上的一次对比，并非受控研究，而且 harness 运行的成本大约高出 22 倍。
把它当作一个研究产物。2026 年 7 月的论文显示其基准测试上有提升，并表示将统计稳健性和组件归因留待后续工作。该仓库需要 Harbor 和 Daytona 沙箱环境，且截至 2026 年 10 月 7 日没有许可证文件，这意味着你可以阅读它，但没有被授予复用代码的权利。它所测试的想法——从日志运行中学习 harness 设置——才是值得带给客户的部分。
动手搭一个：建一个仓库，包含一份简短的 AGENTS.md 指向更深入的文档、一份每项都从失败状态开始的功能清单、一份由 Agent 更新的进度文件、一个初始化脚本，以及一条 Agent 在停止前必须通过的测试命令。Learn Harness Engineering 课程（MIT，14 讲和 8 个项目）正是逐步讲解这些内容，而 Anthropic 的两篇 harness 文章解释了每个部分存在的原因。
讨论 (5)
对客户工作而言，这一切中价值最高的一条是：评估器应该是一个被调校为持怀疑态度的独立 Agent。我曾亲眼看着 Agent 把自己的输出评为“优秀”，整整一个下午。把裁判拆分出来，并赋予它真正运行这个东西的能力，是我所知最便宜的可靠性提升手段。
同意，但根据同一篇 Anthropic 文章要提醒一点：评估器仍然是模型，仍然倾向于宽容。用少量已打分的示例对它进行校准，并在存在确定性检查（测试、schema、数据库中的一行记录）的地方，把最终关卡保留为确定性检查。
读者提问：如果本周我只能搭建 harness 的一个部分，应该选哪个？
验证。一条 Agent 必须运行、人类信任且失败时会大声报错的命令。指令和状态让 Agent 高效运转；而验证才是防止它告诉你某件事可行、实际上却不可行的关键。其他一切都可以下周再说。
以全部未通过状态起步的功能清单被低估了。它把“何时算完成”的决定权从 Agent 手中转移到清单手中，并让客户无需询问任何人就能看懂进度视图。