【Harness Engineering】怎么都在说 Harness Engineering，什么是 Harness Engineering
- 内容介绍
- 文章标签
- 相关推荐
最近一段时间 Harness Engineering 这个名词在 Agent 圈子里面绝对是 No.1
一个词的发明从来不是莫名其妙的，而是大量的生产实践，经验总结，得出了一定的现象规律，人类再加以命名。
但是一个术语诞生的时候，大家其实对其研究没有那么深厚，又或者因为竞争激烈，很多人在同一个时间对类似的现象都有研究，词语的界限就没有那么明确。
Agent 大家都已经很熟悉了，但在一年之前，拖拉拽的工作流，n8n 其实也被偶尔称作 Agent，现在大家都统一了以工具调用与环境交互的自主决策系统才叫 Agent，固定节点的都统一为工作流了
我总结了近期头部 AI 公司内部的大量实践，以及若干开源项目，希望能够准确定义一下 Agent 中的 Harness Engineering 到底是个啥？
Harness Engineering – 马具工程
我翻找了一些资料，大多数说法都认为 Mitchell Hashimoto（米切尔·桥本）是第一个提出“Harness Engineering”概念的人。
-
他是 HashiCorp 的联合创始人、Terraform 的创作者。2026 年 2 月 5 日，他在个人博客中首次明确命名并系统阐述了这个理念（第 5 步：“Engineer the Harness”）
- 他的核心定义非常简洁：“每当发现 Agent 犯错，就花时间设计一个解决方案，让它永远不再犯同样的错误。”
-
六天后，OpenAI 发布工程报告《Harness Engineering: Leveraging Codex in an Agent-First World》
-
3月24日，Anthropic 也发布针对 Harness Engineering 的研究博客
后面，这个词病毒式传播，大家都说 Claude Code 的 Agent 设计是 Harness Engineering 的典范。
总的来说：
Harness Engineering 是围绕 LLM 模型构建，并优化其持续运行过程的工程实践；它负责定义模型如何获取上下文、如何与工具和环境交互。更具体的内容还可以包括，定义模型如何被任务编排与状态管理、如何验证结果，以及如何长时间运行，从而把模型变成可稳定交付结果的 Agent。
可以从下面三层来理解：
-
通用 harness 层：和具体项目相对弱相关，属于 agent runtime / framework 能复用的部分。比如大多数 agent 都基于终端与环境交互，因此 tool loop 设计考虑了：权限系统、记忆、线程持久化、context compaction、hooks、任务调度、客户端协议。Agent CLI 大多是这一层。（“你在终端环境，你要基于这些工具完成任务”）
-
项目 harness 层：和具体项目 / 产品强相关，但仍然不是业务功能本身。比如 AGENTS.md、仓库知识布局、架构边界、lint 规则、质量标准、依赖选择原则、文档索引、设计参考、技术债追踪。OpenAI 文章的核心创新其实很大一部分都在这层。OpenAI 推荐把仓库变成整个系统的完整历史记录，并且分门别类，让 agent 能读到所有文档，但按照任务执行需要选择性的读取文档（渐进式披露），并基于这些充分的信息执行计划、遵守结构规则。(“做任务的时候要遵循这些规则，先这样再那样”)
-
任务/运行 harness 层：和当前这次具体工作强相关。比如 Anthropic 为了逼迫 Claude 生成特别有创意的好的产品，专门搞了两个模型对抗；为了持续执行，不遗漏任务点，设计了 planner 生成 spec、为了让 Claude 不要草率交付，设计了跨 session 文档交接、以及 QA prompt、Playwright 检查脚本。这一层涉及到具体工作部分了，但它仍然是在定义任务如何被执行与验证，不是任务具体内容本身。(说实话有些过于特定的设计意义不大，偏向于一通操作猛如虎，实际战绩 0/5)
三层由通用到最细枝末节，可以看作是不同切入点，但目的都是为了设计一个系统，给模型划定轨迹路线，让 Agent 执行任务的时候被 “稳稳地接住”
个人观点：
- 通用 Harness 层其实已经在各大模型里面内置了，因为训练的时候已经是这样交互逻辑，大家用的时候已经习以为常了。（难道 Agent 能够不与终端交互，超出计算机范畴，从屏幕出来直接扇你一巴掌？）
- OpenAI 的 Harness 最具参考价值，因为他的作用范围较广，在不同工程项目你都可以借鉴。并且最值得学习的点是：设计强制执行的检查控制 Agent 交付的产物。说白了就是测试或者代码风格检查器，但是其实效果特别好。
- 最后就是针对各个任务，细枝末节的板块你可以奇思妙想搞各种 Agent 搭配，组合，Handoff。但是 Harness Engineering 的目标是朝向 Agent 更高的自动化，更长的全自动工作时长，与人类随时随地过多介入是相悖的。
佬友们智慧与汗水的结晶（相关项目）：
- 【通用 harness 层】Coding CLI 的实践（系列）：深入浅出 Claude Code（一）：从源码理解 CLAUDE.md，重写你的配置
- 【通用 harness 层】Multi-Agent，Human in the loop 非常新颖的实践： 【开源】强烈推荐管理 Codex/CC 的无限画布工具！
- 【通用 harness 层】Coding CLI 的实践（系列）：【长期贴】 Claude-code-workflow(CCW) --使用技巧分享-自认为最工程化的harness workflow
- 【项目 harness 层】SPEC文档，依赖、分层代码检查与CI测试，Playwright端到端：【OpenASE】可以关掉你的 IDE 和终端了。聊几句，提几个工单，睡觉的时候也能交付代码
- 【项目 harness 层】帮助你形成自己的 SPEC： https://linux.do/t/topic/1445627
- 【任务/运行 harness 层】明确任务拆解，Sub-Agent Spawn，一句话，让 codex / claude code 创建成千上万个子agent
由此：harness 是互联网公司重新发明的新词还是有独特的创新之处？
网友解答：--【壹】--：
很好的整理，恰好我今天也在问关于 harness 的问题
--【贰】--：
佬的讲解很详细啊，我感觉就是一种框架之类的吧，现在好像很多agent都遵循这个架构。
--【叁】--：
有相似性，但是差一个 OpenAI 提到的点。Harness Engineering 不是你下载一个 skill 或者软件包就可以实现的，而是需要结合项目具体内容，具体框架，具体语言来补充的哦
--【肆】--：
佬，你是我的佬
--【伍】--：
看看这个佬的帖子，讲得非常详细，非常全面 想开一个 harness engineering 实践的长期帖子，大家一起分享实践经验
--【陆】--：
@grok is this true?
--【柒】--：
前排，佬友的想法很有启发
--【捌】--：
我比较喜欢讲起源故事的环节，这样能争一下谁是正统。
用过那家公司（Terraform）的gitness，好像它的上一代产品名称就是harness。所以故事还能往前走。
--【玖】--：
学习一下
--【拾】--：
学习学习！刚好在实践 Harness Engineering 提高效率
--【拾壹】--：
，我看着标题进来，准备好为人师一把呢
--【拾贰】--：
信码由缰 测试驱动
最近一段时间 Harness Engineering 这个名词在 Agent 圈子里面绝对是 No.1
一个词的发明从来不是莫名其妙的，而是大量的生产实践，经验总结，得出了一定的现象规律，人类再加以命名。
但是一个术语诞生的时候，大家其实对其研究没有那么深厚，又或者因为竞争激烈，很多人在同一个时间对类似的现象都有研究，词语的界限就没有那么明确。
Agent 大家都已经很熟悉了，但在一年之前，拖拉拽的工作流，n8n 其实也被偶尔称作 Agent，现在大家都统一了以工具调用与环境交互的自主决策系统才叫 Agent，固定节点的都统一为工作流了
我总结了近期头部 AI 公司内部的大量实践，以及若干开源项目，希望能够准确定义一下 Agent 中的 Harness Engineering 到底是个啥？
Harness Engineering – 马具工程
我翻找了一些资料，大多数说法都认为 Mitchell Hashimoto（米切尔·桥本）是第一个提出“Harness Engineering”概念的人。
-
他是 HashiCorp 的联合创始人、Terraform 的创作者。2026 年 2 月 5 日，他在个人博客中首次明确命名并系统阐述了这个理念（第 5 步：“Engineer the Harness”）
- 他的核心定义非常简洁：“每当发现 Agent 犯错，就花时间设计一个解决方案，让它永远不再犯同样的错误。”
-
六天后，OpenAI 发布工程报告《Harness Engineering: Leveraging Codex in an Agent-First World》
-
3月24日，Anthropic 也发布针对 Harness Engineering 的研究博客
后面，这个词病毒式传播，大家都说 Claude Code 的 Agent 设计是 Harness Engineering 的典范。
总的来说：
Harness Engineering 是围绕 LLM 模型构建，并优化其持续运行过程的工程实践；它负责定义模型如何获取上下文、如何与工具和环境交互。更具体的内容还可以包括，定义模型如何被任务编排与状态管理、如何验证结果，以及如何长时间运行，从而把模型变成可稳定交付结果的 Agent。
可以从下面三层来理解：
-
通用 harness 层：和具体项目相对弱相关，属于 agent runtime / framework 能复用的部分。比如大多数 agent 都基于终端与环境交互，因此 tool loop 设计考虑了：权限系统、记忆、线程持久化、context compaction、hooks、任务调度、客户端协议。Agent CLI 大多是这一层。（“你在终端环境，你要基于这些工具完成任务”）
-
项目 harness 层：和具体项目 / 产品强相关，但仍然不是业务功能本身。比如 AGENTS.md、仓库知识布局、架构边界、lint 规则、质量标准、依赖选择原则、文档索引、设计参考、技术债追踪。OpenAI 文章的核心创新其实很大一部分都在这层。OpenAI 推荐把仓库变成整个系统的完整历史记录，并且分门别类，让 agent 能读到所有文档，但按照任务执行需要选择性的读取文档（渐进式披露），并基于这些充分的信息执行计划、遵守结构规则。(“做任务的时候要遵循这些规则，先这样再那样”)
-
任务/运行 harness 层：和当前这次具体工作强相关。比如 Anthropic 为了逼迫 Claude 生成特别有创意的好的产品，专门搞了两个模型对抗；为了持续执行，不遗漏任务点，设计了 planner 生成 spec、为了让 Claude 不要草率交付，设计了跨 session 文档交接、以及 QA prompt、Playwright 检查脚本。这一层涉及到具体工作部分了，但它仍然是在定义任务如何被执行与验证，不是任务具体内容本身。(说实话有些过于特定的设计意义不大，偏向于一通操作猛如虎，实际战绩 0/5)
三层由通用到最细枝末节，可以看作是不同切入点，但目的都是为了设计一个系统，给模型划定轨迹路线，让 Agent 执行任务的时候被 “稳稳地接住”
个人观点：
- 通用 Harness 层其实已经在各大模型里面内置了，因为训练的时候已经是这样交互逻辑，大家用的时候已经习以为常了。（难道 Agent 能够不与终端交互，超出计算机范畴，从屏幕出来直接扇你一巴掌？）
- OpenAI 的 Harness 最具参考价值，因为他的作用范围较广，在不同工程项目你都可以借鉴。并且最值得学习的点是：设计强制执行的检查控制 Agent 交付的产物。说白了就是测试或者代码风格检查器，但是其实效果特别好。
- 最后就是针对各个任务，细枝末节的板块你可以奇思妙想搞各种 Agent 搭配，组合，Handoff。但是 Harness Engineering 的目标是朝向 Agent 更高的自动化，更长的全自动工作时长，与人类随时随地过多介入是相悖的。
佬友们智慧与汗水的结晶（相关项目）：
- 【通用 harness 层】Coding CLI 的实践（系列）：深入浅出 Claude Code（一）：从源码理解 CLAUDE.md，重写你的配置
- 【通用 harness 层】Multi-Agent，Human in the loop 非常新颖的实践： 【开源】强烈推荐管理 Codex/CC 的无限画布工具！
- 【通用 harness 层】Coding CLI 的实践（系列）：【长期贴】 Claude-code-workflow(CCW) --使用技巧分享-自认为最工程化的harness workflow
- 【项目 harness 层】SPEC文档，依赖、分层代码检查与CI测试，Playwright端到端：【OpenASE】可以关掉你的 IDE 和终端了。聊几句，提几个工单，睡觉的时候也能交付代码
- 【项目 harness 层】帮助你形成自己的 SPEC： https://linux.do/t/topic/1445627
- 【任务/运行 harness 层】明确任务拆解，Sub-Agent Spawn，一句话，让 codex / claude code 创建成千上万个子agent
由此：harness 是互联网公司重新发明的新词还是有独特的创新之处？
网友解答：--【壹】--：
很好的整理，恰好我今天也在问关于 harness 的问题
--【贰】--：
佬的讲解很详细啊，我感觉就是一种框架之类的吧，现在好像很多agent都遵循这个架构。
--【叁】--：
有相似性，但是差一个 OpenAI 提到的点。Harness Engineering 不是你下载一个 skill 或者软件包就可以实现的，而是需要结合项目具体内容，具体框架，具体语言来补充的哦
--【肆】--：
佬，你是我的佬
--【伍】--：
看看这个佬的帖子，讲得非常详细，非常全面 想开一个 harness engineering 实践的长期帖子，大家一起分享实践经验
--【陆】--：
@grok is this true?
--【柒】--：
前排，佬友的想法很有启发
--【捌】--：
我比较喜欢讲起源故事的环节，这样能争一下谁是正统。
用过那家公司（Terraform）的gitness，好像它的上一代产品名称就是harness。所以故事还能往前走。
--【玖】--：
学习一下
--【拾】--：
学习学习！刚好在实践 Harness Engineering 提高效率
--【拾壹】--：
，我看着标题进来，准备好为人师一把呢
--【拾贰】--：
信码由缰 测试驱动