Harness 工程是设计约束、反馈回路和文档以引导 AI 智能体的新兴学科。相比模型本身，Harness 才是关键护城河。OpenAI 通过 Harness 实现了零人工编写 100 万行代码。核心支柱包括上下文工程、架构约束和熵管理。实施分为个人、团队和生产级三个层级。工程师角色从写代码转向设计 AI 运行环境，需注重系统思维与可剥离性设计。
OpenAI 的 Codex 团队刚刚构建了一个拥有超过 100 万行代码的生产级应用程序，其中没有一行代码是由人手编写的。工程师们没有写代码。他们设计了让 AI 能够可靠地编写代码的系统。这个系统——包含约束、反馈回路、文档、Linter 和生命周期管理——就是业界现在所称的 。
Harness 工程是设计这些系统的新兴学科。它正在改变软件工程师的定义。
术语'Harness'源自马具——缰绳、马鞍、马嚼子——这是一整套用于引导强大但不可预测的动物走向正确方向的设备。这个隐喻是刻意的：
如果没有 Harness，AI 智能体就像是一匹在旷野中奔跑的纯种马。速度惊人，令人印象深刻，但对完成任务毫无用处。
Harness 工程是设计和实施以下系统的过程：
Martin Fowler 将其描述为 '我们可以用来约束 AI 智能体的工具和实践' —— 但它不仅仅关乎安全。一个好的 Harness 能让智能体更有能力，而不仅仅是受控。
这是 AI 行业正面临的一个令人不安的事实：底层模型的重要性远不如其周围的系统。
LangChain 明确证明了这一点。他们的编程智能体在 Terminal Bench 2.0 上的表现从 52.8% 提升到了 66.5% —— 排名从 前 30 跃升至前 5 —— 而他们没有对模型做任何改动。他们只改变了 Harness：
| 变更项 | 采取的行动 | 影响 |
|---|---|---|
| 自验证循环 | 增加了完成前的检查清单中间件 | 在提交前捕获错误 |
| 上下文工程 | 在启动时映射目录结构 | 智能体从一开始就理解代码库 |
| 循环检测 | 追踪重复的文件编辑 | 防止'死循环' |
| 推理三明治结构 | 高推理用于规划/验证，中等推理用于实现 | 在时间预算内获得更好的质量 |
相同的模型。不同的 Harness。截然不同的结果。
OpenAI 的实验是迄今为止最有力的证据：
工程师的工作是什么？设计 Harness。指定意图。提供反馈。而不是写代码。
OpenAI 的框架将 Harness 工程分为三个核心类别：
上下文工程旨在确保智能体在正确的时间获得正确的信息。
静态上下文：
AGENTS.md 或 CLAUDE.md 文件动态上下文：
关键原则： 从智能体的角度来看，任何它无法在上下文中访问的内容都不存在。存在于 Google Docs、Slack 频道或人们头脑中的知识对系统是不可见的。代码库必须是唯一的真理来源。
这是 Harness 工程与传统 AI 提示词（Prompting）区别最大的地方。你不是告诉智能体'写出好的代码'，而是通过机械手段强制规定好代码的模样。
依赖分层：
Types → Config → Repo → Service → Runtime → UI
每一层只能从其左侧的层导入。这不仅是一个建议——它是由结构化测试和 CI 校验强制执行的。
约束执行工具：
为什么约束能提高产出： 矛盾的是，限制解决方案空间会让智能体生产力更高，而不是更低。当智能体可以生成任何东西时，它会浪费 Token 去探索死路。当 Harness 定义了清晰的边界时，智能体能更快地收敛到正确的解决方案。
这是最容易被忽视的组件。随着时间的推移，AI 生成的代码库会积累熵——文档与现实脱节、命名约定发生偏离、死代码堆积。
Harness 工程通过定期清理智能体来解决这个问题：
这些智能体按计划运行（每天、每周或由特定事件触发），保持代码库对人类审查者和未来的 AI 智能体都是健康的。
OpenAI 用于 Harness 工程的团队结构：
| 角色 | 传统模式 | Harness 工程模式 |
|---|---|---|
| 编写代码 | 主要工作 | 从不 |
| 设计架构 | 工作的一部分 | 主要工作 |
| 编写文档 | 事后补救 | 关键基础设施 |
| 评审 PR | 代码评审 | 评审智能体产出 + Harness 有效性 |
| 调试 | 阅读代码 | 分析智能体行为模式 |
| 测试 | 编写测试 | 设计智能体执行的测试策略 |
Stripe 的内部编程智能体（被称为 Minions）现在每周产生超过 1,000 个合并的 Pull Request：
在步骤 1 和步骤 5 之间没有开发人员交互。Harness 处理了一切——测试执行、CI 校验、风格合规性以及文档更新。
LangChain 将其 Harness 结构化为可组合的中间件层：
智能体请求 → LocalContextMiddleware (映射代码库) → LoopDetectionMiddleware (防止重复) → ReasoningSandwichMiddleware (优化计算) → PreCompletionChecklistMiddleware (执行校验) → 智能体响应
每个中间件层增加了一项特定能力，而无需修改核心智能体逻辑。这种模块化方法使得 Harness 可测试且可进化。
如果你在个人项目中使用 Claude Code、Cursor 或 Codex：
设置内容：
CLAUDE.md 或 .cursorrules 文件设置时间： 1-2 小时 影响： 防止最常见的智能体错误
适用于 3-10 名共享代码库的开发人员：
在 1 级基础上增加：
AGENTS.md设置时间： 1-2 天 影响： 整个团队的智能体行为保持一致
适用于运行数十个并发智能体的组织：
在 2 级基础上增加：
设置时间： 1-2 周 影响： 智能体作为自主贡献者运行
'如果你对控制流过度工程化，下一次模型更新就会让你的系统崩溃。'
模型改进非常快。2024 年需要复杂流水线的能力，现在只需一个上下文窗口提示词即可处理。构建你的 Harness 时要保持 可剥离性（Rippable） —— 当模型变得足够聪明而不再需要时，你应该能够移除那些'聪明'的逻辑。
Harness 需要随模型一起进化。当新模型版本提高了推理能力时，你的推理优化中间件可能会适得其反。每次重大模型更新后，都要检查并更新 Harness 组件。
最具影响力的 Harness 改进往往是最简单的：更好的文档。如果你的 AGENTS.md 模糊不清，智能体的产出也会模糊不清。投入精力编写精确的、机器可读的文档，将其作为智能体的真理来源。
没有反馈的 Harness 是笼子，而不是引导。智能体需要知道它什么时候成功，什么时候失败。内置：
如果你的架构决策只存在于人们的头脑中，或者存在于智能体无法访问的 Confluence 页面上，那么 Harness 就会出现缺口。智能体需要的一切都必须在代码库中。
| 概念 | 范畴 | 重点 |
|---|---|---|
| 提示工程 | 单次交互 | 编写有效的提示词 |
| 上下文工程 | 模型上下文窗口 | 模型看到什么信息 |
| Harness 工程 | 整个智能体系统 | 环境、约束、反馈、生命周期 |
| 智能体工程 | 智能体架构 | 内部智能体设计和路由 |
| 平台工程 | 基础设施 | 部署、扩展、运营 |
Harness 工程包含上下文工程，并借鉴了提示工程，但它运行在更高的维度——它关乎使智能体可靠的完整系统，而不仅仅是单次交互的输入。
Harness 工程代表了软件工程师职责的一次真正演变：
| 以前 | 以后 |
|---|---|
| 编写代码 | 设计 AI 编写代码的环境 |
| 调试代码 | 调试智能体行为 |
| 评审代码 | 评审智能体产出 + Harness 有效性 |
| 编写测试 | 设计测试策略 |
| 维护文档 | 将文档构建为机器可读的基础设施 |
这并不意味着工程师的技术含量降低了。如果说有什么不同的话，那就是 Harness 工程需要更深层次的架构思考——你正在设计即使没有你持续干预也必须运行的系统。
根据我们在构建 AI 驱动产品时的观察：
我们一直在使用多种智能体系统（Claude Code、Codex、Cursor）构建 AI 驱动的 Web 应用程序。对我们影响最大的模式包括：
AGENTS.md 和 Pre-commit 钩子比复杂的中间件更有影响力。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
生成新的随机RSA私钥和公钥pem证书。 在线工具，RSA密钥对生成器在线工具，online
基于 Mermaid.js 实时预览流程图、时序图等图表，支持源码编辑与即时渲染。 在线工具，Mermaid 预览与可视化编辑在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML转Markdown 互为补充。 在线工具，Markdown转HTML在线工具，online
将 HTML 片段转为 GitHub Flavored Markdown，支持标题、列表、链接、代码块与表格等；浏览器内处理，可链接预填。 在线工具，HTML转Markdown在线工具，online