> 2025 年中，Andrej Karpathy 提出 Context Engineering 比 Prompt Engineering 更重要。不到一年，2026 年 2 月，一个新概念横空出世——Harness Engineering。以第三人称视角，梳理这一概念的起源、内涵与演进脉络，并以 CLI-Anything 项目为案例，探讨 Harness Engineering 在"让所有软…
2025 年中，Andrej Karpathy 提出 Context Engineering 比 Prompt Engineering 更重要。不到一年，2026 年 2 月，一个新概念横空出世——Harness Engineering。本文以第三人称视角，梳理这一概念的起源、内涵与演进脉络，并以 CLI-Anything 项目为案例，探讨 Harness Engineering 在"让所有软件成为 Agent 原生工具"这一方向上的具体实践。
要理解 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 就是缰绳、马鞍、围栏和道路本身——确保十匹马能同时安全奔跑的整套基础设施。（来源，内容经改写）
这一概念的结晶来自两个几乎同时发生的事件。
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 中选择起步，然后逐步定制？（来源，内容经改写）
综合 OpenAI、LangChain、Firecrawl 等多方定义，Agent Harness 可以被理解为：包裹在 AI 模型周围的软件基础设施，管理模型推理之外的一切——工具执行、记忆存储、状态持久化、错误恢复、约束执行和可观测性。（来源，内容经改写）
如果 LLM 是 CPU，那么 Harness 就是操作系统。
OpenAI 团队的 Harness 组件可以归纳为三个类别（Martin Fowler 的分类）：
（来源，内容经改写）
OpenAI 团队还强调了这一过程的迭代性："当 Agent 遇到困难时，我们将其视为信号：识别缺失的东西——工具、护栏、文档——然后反馈到代码库中，始终由 Codex 自己编写修复。"
三个实验提供了有力证据。
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 可以提炼为五个核心模式：
不依赖 prompt 中的"请一步步思考"，而是在系统层面实现专门的规划阶段，产出机器可读的任务列表。监督者 Agent 分解目标，工作者 Agent 逐个处理任务。任务之间有明确的合约和状态流转。
Agent 在会话之间会丢失所有记忆。解决方案不是对话历史，而是外部持久化的结构化工件（JSON 优于 Markdown，因为 Agent 不容易意外覆盖结构化数据）。每次会话开始时读取、结束时写入。
最常见的失败模式是 Agent 生成输出后自我审视、觉得"看起来不错"就继续了——从不实际测试输出是否有效。解决方案是在执行图中插入强制验证节点，包括 LLM 验证（对照规格检查）和确定性验证（实际运行并检查结果）。
OpenAI 团队使用自定义 linter 来保持架构一致性。关键细节是：linter 的错误信息被设计为同时充当修复指令，直接注入 Agent 的上下文。系统不仅阻止错误，还在工作过程中"教导" Agent。写在文档中的规则仍然允许 Agent 违反；在系统层面执行的规则从根本上阻止违规。
工具描述不仅说明工具做什么，还编码决策标准——何时使用、何时不使用、工作机制。模糊的描述迫使 Agent 自行摸索检索策略；精确的描述让它第一次就选对工具。
（以上五个模式综合自 Harness Engineering in a Nutshell，内容经改写）
理解了 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 的核心模式：
CLI-Anything 将"为一款软件生成 CLI"这个复杂任务分解为 7 个严格有序的阶段：代码分析 → 架构设计 → 实现 → 测试规划 → 测试编写 → 文档 → 发布。每个阶段有明确的输入输出合约，Agent 不能跳过或合并阶段。这正是 Harness Engineering 中"结构化任务分解"模式的体现。
每个生成的 CLI 都内置了会话管理模块，支持项目状态的 JSON 持久化和撤销/重做。Agent 可以在不同会话间恢复工作状态，而非每次从零开始。会话文件采用排他文件锁防止并发写入损坏——这种工程细节正是 Harness 层面的可靠性保障。
CLI-Anything 的 HARNESS.md 方法论文档明确要求"永远不要因为进程退出码为 0 就信任导出成功"。其四层测试体系（单元测试、中间文件结构验证、真实软件后端验证、CLI 子进程测试）本质上就是 Harness Engineering 中的"显式验证节点"——每一层都是一个强制检查点，Agent 无法绕过。
特别值得注意的是"不优雅降级"原则：如果真实软件未安装，测试直接失败而非跳过。这与 OpenAI 团队"约束执行"的理念一脉相承——宁可失败也不允许产出不可信的结果。
由于 CLI 的调用者是 AI Agent（可能受 prompt 注入影响），CLI-Anything 的视频编辑 Harness 对所有传递给渲染子进程的编解码器参数实施了严格的白名单校验。这不是 prompt 层面的"请不要使用危险参数"，而是系统层面的硬性阻断——Agent 无法绕过。
每个生成的 CLI 都附带一个 SKILL.md 文件，包含命令分组、使用示例、Agent 专用指南（JSON 输出、错误处理）。REPL 启动时自动展示该文件的绝对路径。这使得 CLI 对 Agent 完全自描述——Agent 通过读取 SKILL.md 即可理解工具的全部能力和使用方式，无需试错。
CLI-Anything 方法论中最独特的贡献是"渲染鸿沟"（The Rendering Gap）概念：GUI 应用在渲染时才应用特效，如果 CLI 操作了项目文件但渲染环节使用了不理解项目格式的工具，所有特效会被静默丢弃。这是一个纯粹的 Harness 层面问题——模型的推理能力再强也无法解决，必须通过工程化的滤镜转译层和原生渲染器集成来闭环。
Epsilla 的分析文章指出了两个危险的误解：一是认为一个全面的 AGENTS.md 文件就是足够的 Harness；二是认为更强大的模型允许更松散的架构纪律。实践证明恰恰相反——更大的 Agent 自主权要求更严格而非更宽松的运行环境。（来源，内容经改写）
OpenAI 团队自己也发现，早期将所有规则塞进一个巨大的 AGENTS.md 的策略"可预见地失败了"。因为上下文窗口是稀缺资源，庞大的指令文件使 Agent 遗漏重要约束。解决方案是将 AGENTS.md 从"百科全书"变为"地图"——一个指向结构化文档目录的入口点。
CLI-Anything 的做法与此高度一致：它不依赖单一的指令文件，而是将方法论沉淀在 HARNESS.md（SOP 文档）、TEST.md（测试计划与结果）、SKILL.md（Agent 可发现的技能定义）、README.md（安装与使用指南）等多个结构化文档中，每个文档服务于特定目的，Agent 按需读取。
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 决定智能是否能产出一致、可验证、可恢复的工作成果。
两者不是替代关系，而是乘法关系。
Martin Fowler 提出了几个值得思考的前瞻性问题：
（来源，内容经改写）
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 的投入，很可能在未来产生真正的生产力差距。
参考资料：
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
使用加密算法（如AES、TripleDES、Rabbit或RC4）加密和解密文本明文。 在线工具，加密/解密文本在线工具，online
生成新的随机RSA私钥和公钥pem证书。 在线工具，RSA密钥对生成器在线工具，online
基于 Mermaid.js 实时预览流程图、时序图等图表，支持源码编辑与即时渲染。 在线工具，Mermaid 预览与可视化编辑在线工具，online
解析常见 curl 参数并生成 fetch、axios、PHP curl 或 Python requests 示例代码。 在线工具，curl 转代码在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
