Harness Engineering：继 Context Engineering 之后，AI Agent 时代的新工程范式

qhvssonic

450人浏览 · 2026-03-26 07:45:56

qhvssonic · 2026-03-26 07:45:56 发布

2025 年中，Andrej Karpathy 提出 Context Engineering 比 Prompt Engineering 更重要。不到一年，2026 年 2 月，一个新概念横空出世——Harness Engineering。本文以第三人称视角，梳理这一概念的起源、内涵与演进脉络，并以 CLI-Anything 项目为案例，探讨 Harness Engineering 在"让所有软件成为 Agent 原生工具"这一方向上的具体实践。

一、从 Prompt 到 Context，再到 Harness：三层递进

要理解 Harness Engineering，需要先厘清它与前两个阶段的关系。

2023-2024 年是 Prompt Engineering 的高峰期。彼时人与 AI 的交互以单轮问答为主，通过角色设定、思维链、少样本示例等技巧优化模型输出。核心问题是：“该怎么问？”

2025 年中，随着 Agent 框架的成熟，Andrej Karpathy 指出 Context Engineering 比 Prompt 更重要。核心问题变为：“该让模型看到什么？”——包括 RAG 检索、MCP 工具接入、记忆管理、系统提示词设计等，本质是在推理时为模型构建完整的信息环境。

但当 AI Agent 真正进入生产环境、执行跨步骤的长周期自主任务时，一类新的失败模式浮现了：Agent 忽视团队规范、生成违反架构约束的代码、在并行执行时与自身冲突、随时间推移逐渐降低代码质量。这些问题不是"模型该看到什么"能解决的，而是"系统该阻止什么、度量什么、修复什么"的问题。

2026 年 2 月，这个领域终于有了名字。

阶段	核心问题	设计对象
Prompt Engineering	“该怎么问？”	发送给 LLM 的指令文本
Context Engineering	“该让模型看到什么？”	模型推理时的全部上下文
Harness Engineering	“整个环境该如何设计？”	Agent 外部的约束、反馈与运维系统

用一个比喻来说：如果 Prompt Engineering 是"向右转"的口令，Context Engineering 是地图、路标和可见地形，那么 Harness Engineering 就是缰绳、马鞍、围栏和道路本身——确保十匹马能同时安全奔跑的整套基础设施。（来源，内容经改写）

二、Harness Engineering 的起源

这一概念的结晶来自两个几乎同时发生的事件。

2026 年 2 月 5 日，HashiCorp 联合创始人、Terraform 和 Ghostty 的创造者 Mitchell Hashimoto 在博客中描述了一种实践模式，并赋予其名称：“每当 Agent 犯错，就花时间工程化一个解决方案，使 Agent 永远不再犯同样的错误。” 这不是修改 prompt，而是构建测试套件、验证脚本或 lint 规则，让 Agent 能够自我检查。（来源，内容经改写）

几天后的 2 月 11 日，OpenAI 发布了题为"Harness engineering: leveraging Codex in an agent-first world"的报告。报告披露了一项内部实验：从 2025 年 8 月起，一个最初仅 3 人（后扩展到 7 人）的工程团队，在五个月内使用 Codex Agent 构建了一个真实产品，代码量达到约一百万行，合并了约 1,500 个 PR——全程没有手动编写任何一行代码。团队估计效率约为手动开发的 10 倍。（来源，内容经改写）

Martin Fowler 随后在 Thoughtworks 的技术博客中评论道，OpenAI 的文章全文只提到了一次"harness"这个词，但这个概念恰恰是整篇文章的核心。他进一步提出了一个前瞻性问题：Harness 是否会成为未来的"服务模板"——团队从一组预建的 Harness 中选择起步，然后逐步定制？（来源，内容经改写）

三、Harness 到底是什么？

综合 OpenAI、LangChain、Firecrawl 等多方定义，Agent Harness 可以被理解为：包裹在 AI 模型周围的软件基础设施，管理模型推理之外的一切——工具执行、记忆存储、状态持久化、错误恢复、约束执行和可观测性。（来源，内容经改写）

如果 LLM 是 CPU，那么 Harness 就是操作系统。

OpenAI 团队的 Harness 组件可以归纳为三个类别（Martin Fowler 的分类）：

Context Engineering：代码库中持续增强的知识库，加上 Agent 对可观测性数据和浏览器导航等动态上下文的访问。
架构约束：不仅由 LLM Agent 监控，还由确定性的自定义 linter 和结构化测试执行。
“垃圾回收”：定期运行的 Agent，扫描文档不一致或架构约束违规，对抗熵增和衰退。

（来源，内容经改写）

OpenAI 团队还强调了这一过程的迭代性：“当 Agent 遇到困难时，我们将其视为信号：识别缺失的东西——工具、护栏、文档——然后反馈到代码库中，始终由 Codex 自己编写修复。”

四、为什么 Harness 比模型更重要？

三个实验提供了有力证据。

LangChain 在 Terminal Bench 2.0 基准测试中，保持模型固定为 gpt-5.2-codex，仅改进 Harness（系统提示词、工具、中间件），分数从 52.8% 提升到 66.5%，排名从约第 30 名跃升至约第 5 名。模型权重没有变化，变化的只是 Harness。（来源，内容经改写）

安全研究员 Can Boluk 发布的 Hashline 实验中，仅改变 Agent 的编辑格式（为每行附加 2-3 字符的哈希标识），在 16 个 LLM 上测试。Grok Code Fast 1 模型的基准分数从 6.7% 跳升至 68.3%，所有模型的平均输出 token 减少约 20%。模型没变，只是 Harness 变了。（来源，内容经改写）

OpenAI 的百万行代码实验本身也证明了这一点：早期生产力很低，因为环境设置不完善、工具集成薄弱、恢复逻辑缺失。随着 Harness 逐步改进，性能才急剧提升。

LangChain CEO Harrison Chase 在 Sequoia 的播客中总结道：“长周期 Agent 的成功既来自更好的 LLM，也来自 Agent Harness 的巧妙工程——有主见的脚手架、规划工具、压缩策略和文件系统集成。”（来源，内容经改写）

五、Harness Engineering 的核心模式

综合各方实践，Harness Engineering 可以提炼为五个核心模式：

5.1 结构化任务分解

不依赖 prompt 中的"请一步步思考"，而是在系统层面实现专门的规划阶段，产出机器可读的任务列表。监督者 Agent 分解目标，工作者 Agent 逐个处理任务。任务之间有明确的合约和状态流转。

5.2 跨会话状态持久化

Agent 在会话之间会丢失所有记忆。解决方案不是对话历史，而是外部持久化的结构化工件（JSON 优于 Markdown，因为 Agent 不容易意外覆盖结构化数据）。每次会话开始时读取、结束时写入。

5.3 显式验证节点

最常见的失败模式是 Agent 生成输出后自我审视、觉得"看起来不错"就继续了——从不实际测试输出是否有效。解决方案是在执行图中插入强制验证节点，包括 LLM 验证（对照规格检查）和确定性验证（实际运行并检查结果）。

5.4 机械化约束执行

OpenAI 团队使用自定义 linter 来保持架构一致性。关键细节是：linter 的错误信息被设计为同时充当修复指令，直接注入 Agent 的上下文。系统不仅阻止错误，还在工作过程中"教导" Agent。写在文档中的规则仍然允许 Agent 违反；在系统层面执行的规则从根本上阻止违规。

5.5 精确的工具描述

工具描述不仅说明工具做什么，还编码决策标准——何时使用、何时不使用、工作机制。模糊的描述迫使 Agent 自行摸索检索策略；精确的描述让它第一次就选对工具。

（以上五个模式综合自 Harness Engineering in a Nutshell，内容经改写）

六、CLI-Anything：Harness Engineering 在软件操控领域的实践

理解了 Harness Engineering 的概念框架后，可以发现香港大学 HKUDS 团队的开源项目 CLI-Anything 恰好是这一思想在"让 Agent 操控真实软件"方向上的具体落地。

CLI-Anything 的核心产物就叫"Harness"——为每款 GUI 软件生成的完整 CLI 适配层。但它的 Harness 概念与 OpenAI 的编码 Agent Harness 有所不同：OpenAI 的 Harness 是让 Agent 写出好代码的环境；CLI-Anything 的 Harness 是让 Agent 操控真实软件的接口。两者共享同一个底层理念：不改变模型，而是工程化模型周围的一切。

以下是 CLI-Anything 的 Harness 设计如何映射到 Harness Engineering 的核心模式：

6.1 结构化任务分解 → 7 阶段流水线

CLI-Anything 将"为一款软件生成 CLI"这个复杂任务分解为 7 个严格有序的阶段：代码分析 → 架构设计 → 实现 → 测试规划 → 测试编写 → 文档 → 发布。每个阶段有明确的输入输出合约，Agent 不能跳过或合并阶段。这正是 Harness Engineering 中"结构化任务分解"模式的体现。

6.2 跨会话状态持久化 → Session 与 Undo/Redo

每个生成的 CLI 都内置了会话管理模块，支持项目状态的 JSON 持久化和撤销/重做。Agent 可以在不同会话间恢复工作状态，而非每次从零开始。会话文件采用排他文件锁防止并发写入损坏——这种工程细节正是 Harness 层面的可靠性保障。

6.3 显式验证节点 → 四层测试体系

CLI-Anything 的 HARNESS.md 方法论文档明确要求"永远不要因为进程退出码为 0 就信任导出成功"。其四层测试体系（单元测试、中间文件结构验证、真实软件后端验证、CLI 子进程测试）本质上就是 Harness Engineering 中的"显式验证节点"——每一层都是一个强制检查点，Agent 无法绕过。

特别值得注意的是"不优雅降级"原则：如果真实软件未安装，测试直接失败而非跳过。这与 OpenAI 团队"约束执行"的理念一脉相承——宁可失败也不允许产出不可信的结果。

6.4 机械化约束执行 → 编解码器白名单与参数校验

由于 CLI 的调用者是 AI Agent（可能受 prompt 注入影响），CLI-Anything 的视频编辑 Harness 对所有传递给渲染子进程的编解码器参数实施了严格的白名单校验。这不是 prompt 层面的"请不要使用危险参数"，而是系统层面的硬性阻断——Agent 无法绕过。

6.5 精确的工具描述 → SKILL.md 自描述

每个生成的 CLI 都附带一个 SKILL.md 文件，包含命令分组、使用示例、Agent 专用指南（JSON 输出、错误处理）。REPL 启动时自动展示该文件的绝对路径。这使得 CLI 对 Agent 完全自描述——Agent 通过读取 SKILL.md 即可理解工具的全部能力和使用方式，无需试错。

6.6 渲染鸿沟 → Harness 层面的闭环保障

CLI-Anything 方法论中最独特的贡献是"渲染鸿沟"（The Rendering Gap）概念：GUI 应用在渲染时才应用特效，如果 CLI 操作了项目文件但渲染环节使用了不理解项目格式的工具，所有特效会被静默丢弃。这是一个纯粹的 Harness 层面问题——模型的推理能力再强也无法解决，必须通过工程化的滤镜转译层和原生渲染器集成来闭环。

七、AGENTS.md 的谬误与 CLI-Anything 的回应

Epsilla 的分析文章指出了两个危险的误解：一是认为一个全面的 AGENTS.md 文件就是足够的 Harness；二是认为更强大的模型允许更松散的架构纪律。实践证明恰恰相反——更大的 Agent 自主权要求更严格而非更宽松的运行环境。（来源，内容经改写）

OpenAI 团队自己也发现，早期将所有规则塞进一个巨大的 AGENTS.md 的策略"可预见地失败了"。因为上下文窗口是稀缺资源，庞大的指令文件使 Agent 遗漏重要约束。解决方案是将 AGENTS.md 从"百科全书"变为"地图"——一个指向结构化文档目录的入口点。

CLI-Anything 的做法与此高度一致：它不依赖单一的指令文件，而是将方法论沉淀在 HARNESS.md（SOP 文档）、TEST.md（测试计划与结果）、SKILL.md（Agent 可发现的技能定义）、README.md（安装与使用指南）等多个结构化文档中，每个文档服务于特定目的，Agent 按需读取。

八、Big Model vs Big Harness：一场正在进行的辩论

Latent Space 的 swyx 提出了一个尖锐的问题：Harness Engineering 是真实的吗？

"Big Model"阵营认为更好的模型会让 Harness 过时。Claude Code 的 Boris Cherny 说："所有秘密都在模型里——这是最薄的包装层。"OpenAI 的 Noam Brown 认为：“那些脚手架会被推理模型的能力提升所取代。”

"Big Harness"阵营则反驳：Harness 就是产品本身。每个生产级 Agent 最终都会收敛到相同的核心循环，可靠系统与脆弱系统之间的差异完全在于包裹这个循环的东西。Cursor 500 亿美元的估值很难仅仅归功于模型。

（来源，内容经改写）

CLI-Anything 的实践为这场辩论提供了一个有趣的数据点：它的 HARNESS.md 方法论文档明确列出了"依赖强大的基础模型"作为已知局限——需要 Claude Opus 4.6 或 GPT-5.4 级别的模型才能可靠生成 CLI。这说明模型能力确实是基础。但同时，同一个模型在有 HARNESS.md 方法论指导和没有方法论指导的情况下，产出质量天差地别。模型提供智能，Harness 决定智能是否能产出一致、可验证、可恢复的工作成果。

两者不是替代关系，而是乘法关系。

九、Harness Engineering 的未来

Martin Fowler 提出了几个值得思考的前瞻性问题：

Harness 是否会成为新的"服务模板"？团队从预建的 Harness 中选择起步，然后逐步定制。
为了获得更多 AI 自主权，运行时是否必须被约束？更多信任和可靠性需要约束解空间：特定的架构模式、强制的边界、标准化的结构。
是否会出现"AI 前"和"AI 后"两个世界？为旧代码库改装 Harness 是否值得？

（来源，内容经改写）

CLI-Anything 的 CLI-Hub 注册中心和社区贡献模式，某种程度上已经在回答第一个问题：它正在构建一个可复用的 Harness 库，社区为不同软件贡献 Harness，其他团队直接 pip install 使用。这与 Martin Fowler 设想的"Harness 即服务模板"方向高度吻合。

十、结语

Harness Engineering 不是又一个营销术语。它是 AI Agent 从 demo 走向生产过程中，工程师角色转变的真实写照——从"写代码的人"变为"设计 Agent 运行环境的人"。

正如 OpenAI 团队所说："我们现在最困难的挑战集中在设计环境、反馈循环和控制系统上。“这与 Chad Fowler 提出的"重新定位严谨性”（Relocating Rigor）不谋而合：严谨性没有消失，它被前置到了系统的核心设计中。

CLI-Anything 项目则展示了 Harness Engineering 在一个特定但极具价值的方向上的应用：不是让 Agent 写代码，而是让 Agent 操控真实的专业软件。它的 HARNESS.md 方法论、四层测试体系、渲染鸿沟解决方案和防御性后端设计，为"如何工程化 Agent 与外部世界的接口"提供了一套经过 20 余款软件实战验证的参考答案。

模型质量在快速趋同。而 Harness 是每个团队必须自己构建的资产。对 Harness 的投入，很可能在未来产生真正的生产力差距。

参考资料：