[AI]一文看懂Harness 工程— — 为 AI 装上“马具”

近期技术圈都被一个词刷屏——Harness。什么是 Harness？什么是 Coding Harness？为什么大家都在聊它？本篇文章就来为大家简单介绍下Harness概念、来源、核心思想。

1. Harness 是什么？一个比喻就够了

一句话解释就是：Harness = 约束 + 工具 + 文档 + 反馈循环，是围绕 AI 编程 Agent 搭建的整套"运行环境"。

在 2026 年，单纯依靠强大的模型已经无法拉开差距。真正的技术护城河在于 Harness Engineering。通过构建一套严密的约束系统（Harness），我们可以让不可预测的 AI 产出确定性的业务价值。

想象你有一匹力大无穷、跑得飞快的马——但它不认路。你不能靠喊“往左！往右！”让它精准到达目的地。你需要的是：缰绳、马鞍、围栏、路标，甚至路边放个水槽让它补充体力。这套“装备”就是 Harness（字面意思：马具）。

那匹马就是今天的 AI 编程助手（如 OpenAI Codex、Claude Code、Gemini CLI）。它们能写代码，甚至写得很好，但如果没有规划环境、设定边界、提供反馈，它们一样会跑偏。

2. 概念的起源与行业共识

这个概念在 2026 年 2 月 由 HashiCorp 联合创始人 Mitchell Hashimoto 正式提出。他的定义很朴素：

每当 AI Agent 犯一个错误，你就花时间做一个改进，确保它永远不会再犯同样的错。这个持续改进环境的过程，就是 Harness Engineering。

几天后，OpenAI 发表文章《Harness engineering: leveraging Codex in an agent-first world》，披露了他们的实践：3 个工程师，5 个月，用 AI 生成了 100 万行代码，人类没有手写一行。产品已在内部使用，有真实用户。关键是——这并不是因为 AI 模型变聪明了，而是因为他们把 Harness 做好了。

随后，Martin Fowler 等专家也跟进讨论。整个行业的竞争重心，正从“哪家模型更强”悄悄转向“谁的 Harness 更好”。

参考资料：https://openai.com/zh-Hans-CN/index/harness-engineering/

3. 为什么需要 Harness？两个类比帮你建立直觉

1.马与骑手

AI 模型是那匹纯血马，速度极快，但方向由本能决定。Harness 就是缰绳、马鞍、眼罩——它限定马能看到什么、能去哪里，同时把骑手的指令稳定传递下去。工程师是骑手，工作不是替马跑，而是设定方向和边界。

2.赛车与赛道

AI 模型是一台千匹马力的赛车，引擎轰鸣、加速惊人，但它不知道赛道的弯道、刹车点、限速区。Harness 就是赛道护栏、信号灯、维修区规则——它划定了赛车能跑的范围、何时必须减速、哪里可以超车。工程师是赛道设计师 + 赛事监管，不是替赛车踩油门，而是确保它在规则内跑出最快圈速。

一句话总结：Context 管模型能看到什么信息；Harness 管模型在什么环境里运行、能做什么、不能做什么。

4 .Harness Engineering 的核心组件

1. 护栏系统 (Guardrails)——安全边界

这是 Agent 的安全边界。

• 输入过滤：检测并拦截潜在的注入攻击。
• 输出校验：确保生成的内容符合 JSON 格式、不包含敏感词或不合规的代码。
• 权限控制：AI 尝试运行 rm -rf 时，Harness 会在沙盒层将其拦截并报错。

2. 记忆管理 (Memory Management)

AI 模型本身的上下文是有限的。Harness 负责管理长期记忆。

• 动态检索：根据当前任务从向量库提取历史背景。
• 状态持久化：记录任务执行到哪一步了，即便断电重启，Agent 也能从断点恢复。

3. 错误自动恢复 (Error Recovery)

当 AI 运行代码报错时，Harness 会自动捕获报错堆栈，并将其作为反馈输入回 Model，提示其进行修复。这种“自愈”能力是 Harness 的核心价值。

4. 自评估系统 (Self-Evaluation)

在输出给用户之前，由另一个轻量级模型（或同一模型的另一个实例）对结果进行打分。如果不合格，Harness 会要求重新执行。

5. Harness 在 AI 工程四层模型中的位置

很多人会把 Harness 跟提示词工程混为一谈。Harness 不是替代 Prompt 或 Context，而是在更高维度上设计 AI 工作的整个环境。

工程层级	核心职责	关键产出	典型工具/实践	类比（驯马）
Prompt 提示词工程(最上层)	设计单次交互的指令结构，让模型准确理解任务	提示词模板、Few-shot 示例、角色设定	角色扮演、Chain-of-Thought、结构化提示词	对马喊“往右转，步频放慢”
Context 上下文工程	管理模型每次推理时可见的全部 Token，过滤噪音	检索增强（RAG）、文档切片、上下文窗口分配	向量数据库、滑动窗口、动态截断	给马看地图、路标和当前地形
Agent 智能体工程	设计 Agent 的行动循环：规划→调用工具→观察→反思	任务分解、工具调用链、错误恢复策略	ReAct、Plan-and-Execute、多步工具链	决定马先去河边喝水、再用驮包装货、最后回马厩
Harness 工程	搭建 Agent 运行的整个环境：约束、沙箱、验证、协调	架构护栏、CI 拦截、沙箱隔离、多 Agent 调度	AGENTS.md、MCP/Skills、沙箱、自定义 linter、后台 GC	设计缰绳、围栏、道路、并让多匹马同时奔跑不冲撞

┌──────────────────────────────────────────┐
│              🏗️ 提示词工程                 │
│         （单次指令的措辞与结构设计）          │
│       类比：对马说“往右转，慢一点”           │
└────────────────────┬─────────────────────┘
                     │
                     │ 运行在...
                     ▼
┌──────────────────────────────────────────┐
│              📄 上下文工程                 │
│     （模型每次推理时能看到的全部 Token 管理） │
│       类比：给马看地图、路标、当前地形        │
└────────────────────┬─────────────────────┘
                     │
                     │ 运行在...
                     ▼
┌──────────────────────────────────────────┐
│              🤖 智能体工程                 │
│   （规划、工具调用、反思、多步行动循环设计）    │
│ 类比：设计马的行走策略——先去哪、用什么工具     │
└────────────────────┬─────────────────────┘
                     │
                     │ 运行在...
                     ▼
┌──────────────────────────────────────────┐
│              🐎 Harness 工程              │
│（执行环境、约束规则、沙箱、验证闭环、多Agent协调）│
│ 类比：设计缰绳、围栏、道路，让10匹马同时安全奔跑│
└──────────────────────────────────────────┘

6. Coding Harness 又是什么？

如果 Harness 是通用概念，Coding Harness 就是在"写代码"这个场景下的具体实现。

你可以把 Coding Harness 理解为：一套让 AI 编程 Agent 稳定、高效、可控地写代码的基础设施。它通常包括以下几个部分：

核心模块	官方案例	关键数据	新人可复用的做法
上下文管理	OpenAI 的 AGENTS.md	88 个文件，3.5 PR/人/天	用 AGENTS.md 模板，任务→文件映射表
架构约束	OpenAI 依赖方向规则	CI 自动拦截违规	自定义 linter + CI 检查脚本
反馈循环	LangChain 自我验证	52.8% → 66.5%	Plan→Verify→Fix 循环 + 执行轨迹追踪
垃圾回收	OpenAI 后台 Agent	自动 PR 修复	定期扫描过期文档 + 检测架构偏移

1. 上下文管理——让 AI 看到该看的东西

AI 只能理解它"看到"的内容。写在 Slack 群聊里、存在某人脑子里的架构决策，AI 根本不知道。所以需要把知识整理成结构化文档（比如 AGENTS.md），放进代码仓库，让 AI 随时查阅。OpenAI 的团队最终维护了 88 个 AGENTS.md 文件，每个子系统一个。

参考资料：https://github.com/openai/openai-agents-python/blob/main/AGENTS.md

2. 架构约束——画一条线，AI 不许越界

比如规定代码依赖只能按固定方向流动（类型 → 配置 → 服务 → 运行时 → 界面），然后用自动化工具强制检查。AI 写出违规代码？直接被拦住。

参考资料：https://github.com/sverweij/dependency-cruiser/blob/main/.dependency-cruiser.mjs

3. 反馈循环——让 AI 自己知道对不对

给 AI 配上测试套件、Lint 检查、截图对比等工具，让它写完代码后能自己验证结果。验证不通过？自动重试。这比人盯着看高效得多。

参考资料：https://blog.langchain.com/improving-deep-agents-with-harness-engineering/

4. “垃圾回收” ——对抗熵增

AI 写的代码量大、速度快，但也容易产生技术债务。OpenAI 的做法是让后台 Agent 定期扫描文档是否过期、架构是否偏移，然后自动提交修复。

参考资料：https://martinfowler.com/articles/harness-engineering.html

7. 总结

Harness 工程的核心思想可以归纳为一句话：不要试图驯服 AI，而是设计一个让 AI 无法犯错的环境。

从 Mitchell Hashimoto 的朴素定义，到 OpenAI 的百万行代码实践，再到 LangChain 的实验数据——所有证据都指向同一个结论：模型是商品，Harness 才是护城河。

这里分享三个有意思的观点：

1. 为删除而构建：模型进化的速度永远快过手写控制逻辑。今天的核心代码，明天一句提示词就能替代。Manus 用同一个底层模型重写了 4 次 Harness，每次重写都带来可靠性跃升。保持模块化，随时准备断舍离。
2. 少即是多：给 AI 的工具越多，它越迷茫。Vercel 删除 80% 的工具之后，Agent 不再绕圈，速度和准确率双双提升。最好的 Harness 优化，往往是做减法。
3. Harness 是你最值钱的资产：底层模型随时可以通过 API 切换；但 Harness 里积累的执行轨迹、失败记录和修复路径，无法复制。Manus 不训练自己的模型，只做 Harness——2025 年 12 月被 Meta 高价收购。