Harness Engineering 介绍
Harness Engineering 那这个是什么意思呢，首先想象你有一匹马，这个马很有力量，但是没有马鞍，缰绳，你也很难去驾驭它，就是这样一个东西，统称为harness，现在我们的大模型现在能力很强，可以说是上知天文下知地理，但是他有能力就不代表着可以给一个好的输出，所以呢，harness 就是是给模型模型外面套一层像马一样的挽具，让模型可以稳定的输出，并且可重复的去驾驭。
了解Harness 之前呢，我们要先了解llm 有哪些缺陷或特性呢？ 1. LLM 是无状态的，对话结束就很容易去忘记。 2. 只能生成文字，无法操控外部世界 3. 上下文窗口的限制，不能无限处理信息。 4. 输出是概率性的，同样的输入，输出的内容是不一样的，他也不能保证哪一次都是正确的。
这些都是大模型的一些特性，harness在大模型的基础上，让它能够去做一些，他之前根本完不成的一些事情。
一个更形象的比喻，我们的模型就像是引擎，我们的harness，就像是外部的这辆车，如果没有查车，方向盘，等这些配置，这辆车也是不能上路的。
讲完harness对这个模型的作用呢，我们再讲一下harness，有几哪个结构
他不是一个具体的工具，而是围绕着这个模型做的几类基础设施的总称
他总共分为4层 1. 记忆层，解决的模型无状态的问题（他不知道你上一轮对话说了什么，你的项目有什么规范，那记忆层呢，用文件系统去做这个持久化，想让他知道的内容的，我们给他写下来，结构化存放，让模型每次都能检索到正确的背景信息，在代码场景里，这就是claude.md/agent.md,这个文件充当的是导航地图的作用，只放一些关键的约束和规则，具体详细的百科全书可以到对应的模块里面去维护） 2. 执行层，解决的是只能生成文字的问题（通过使用一些工具，让模型能够只是从我说一些话，到我能够做一些事情，harness，提供一些沙箱环境，让模型可以大胆的去修改，改完之后有问题呢，还可以去回滚） 3. 反馈层，解决的是输出不可靠的问题（这一层比较关键，有测试呀，有linter呀，有cicd呀，模型跑完代码，跑测试，测试失败了，就让他改，改完之后再跑测试，直到测试通过才进入下一步，反馈的速度呢，从人工review的小时级别，缩小到秒级。这个回路能够闭合的关键是，虽然生成是不确定性的，但是我们验证是确定性的，你生成一个文章质量高不高不要去判断，生成一个图好看不好看不好去评判，但是代码逻辑呢，你知道写100个用例，过了他就是ok的，你知道所以你不用每次都对，只要保证我有足够好的验证手段就够了） 4. 编排层，解决的事复杂任务拆解的问题（主要解决的是，复杂任务的拆解的问题，比如我们一个复杂的主任务，不可能只让一个agent去执行，我们也会拆解成几个并行的子任务，让ai同步执行，这样呢，就能处理远超本次能力上限的工程任务。）
4. 核心实践：OpenAI 的 Codex 极端实验
OpenAI 曾记录过一个极具代表性的实践案例：5 名工程师在 5 个月内交付了 100 万行代码，且其中包含 0 行人类手写代码。
关键成功因素：
- 倒逼机制 (Forcing Function)：全团队禁止直接编写代码，迫使所有人集中精力构建 Harness（基础设施）。
- 角色彻底转型：工程师从 Code Writer 进化为 Environment Designer。其日常工作由写逻辑转变为维护
AGENTS.md、编写自定义 Linter 以及建立可观测性栈。 - 极高吞吐量：平均每人每日交付 3.5 个 PR，且大部分 Code Review 是由 Agent 对 Agent 完成的。
5. 开发者如何构建自己的 Harness？
- 精炼
AGENTS.md索引：- 目录化：根目录文件应少于 100 行，仅作为导航。
- 模块化：将架构、设计和安全约束拆分到
docs/*.md。 - 层级化：支持子目录级的覆盖规则（如
AGENTS.override.md）。
- 闭环反馈回路：
- 接入自动触发的测试、Lint 和验证工具。
- 优化反馈信息的格式，使其更易被 AI 解析和执行。
- 优化工作流习惯：
- 热启动：下班前启动 Agent 进行深度调研或并行探索。
- 职能分离：将模糊需求明确拆分为“规划 (Planning)”和“执行 (Execution)”两个阶段。
- 建立评估体系 (Evals)：
- 超越简单的 CI，建立一套针对 Agent 意向和产出质量的系统化评估工具。
总结
Harness Engineering = 用工程手段“驯服”大模型，将 AI 转化为可靠的产品。
软件工程团队的核心竞争力，正在从“谁的代码写得好”转向“谁能设计出更好的 Agent 运行环境”。