Harness Engineering 介绍
如果用一句话概括2025-2026年AI工程领域最深刻的变革，那就是“从管理提示词，转向管理整个运行环境”。这一新范式被称作Harness Engineering（驾驭工程）。简单来说，就是将AI置于一个预设且可控的框架内，让它在人类划定的边界里高效产出——不是依赖实时盯防和纠正，而是依靠系统约束、即时反馈和闭环控制逻辑。这才是让AI从“玩具”真正蜕变为“工具”的核心所在。
1. 定义与起源
这一概念源于一位关键人物：HashiCorp联合创始人Mitchell Hashimoto。他在2026年初正式提出Harness Engineering。这个词的中文翻译颇为精妙，“马具/驾驭工程”——并非要“控制”AI的每一步，而是为其配备一套精密的缰绳和鞍具，使其既能自由驰骋，又不至于偏离轨道太远。
这个比喻的精髓在于：真正的驾驭绝非死板的控制。优秀的工程师不会试图手工限定AI的每一个动作，而是构建一套框架、引导机制和约束集合。在这样的环境中，AI的能力得以在可预测、可靠的前提下充分释放。
从行业演进看，这标志着软件工程核心竞争力的又一次重大转移。早期的提示词工程（Prompt Engineering）解决的是“如何表达”的问题；到2025年，上下文工程（Context Engineering）关注的是“AI知道什么”；而如今，Harness Engineering回答的是：AI在什么样的环境中工作？
2. 演进逻辑：从 Prompt 到 Harness
这一演进路径清晰可见：不同阶段的核心关注点截然不同，如下表所示：
| 阶段 | 核心关注点 | 隐喻 | 解决的问题 |
|---|---|---|---|
| Prompt Engineering（2023） | 说什么 | 指令 | 如何通过提示词让AI完成单次输出。 |
| Context Engineering（2025） | 知道什么 | 信息 | 如何通过RAG和动态上下文让AI获取所需信息。 |
| Harness Engineering（2026） | 在什么环境做事 | 环境/闭环 | 如何构建约束、反馈与控制系统，使Agent可靠执行任务。 |
简而言之，这是一场从“管好输入”，到“管好信息”，再到“管好环境”的全面升级。
3. Harness Engineering 的三大支柱
根据Thoughtworks专家Birgitta Böckeler等业界人士的总结，实现这一范式需要从三个维度同步发力：
维度一：上下文工程（Context 2.0）
这已不再是简单的“填满上下文窗口”。核心在于确保Agent在正确时机，获取粒度恰到好处的信息。
- 渐进式披露（Progressive Disclosure）：避免将整个仓库的文档一股脑儿塞给AI。将隐性知识转化为结构化信息体系。例如通过层级目录
docs/ARCHITECTURE.md引导AI按需获取，而非盲目堆砌。 - 运行时数据接入：让AI像调用API一样查询日志、指标和环境信息。使用LogQL、PromQL等工具进行动态查询，而非依赖静态快照。
- 直接感知环境：通过CDP等协议使Agent直接操控浏览器，原生复现Bug或验证UI。至此，AI拥有了“手”和“眼”。
维度二：架构约束（Architectural Constraints）
这一维度解决的是“如何让AI写出高质量代码”。关键在于将通常依赖人工判断的“代码品味”（如命名规范、依赖原则、边界控制）转化为可强制执行的规则，确保AI“只在边界内行事”。
- AI友好型Linter：传统Linter的错误信息面向人类，常需查阅大量文档。Harness时代的Linter，错误消息中直接包含修复建议和示例代码，便于Agent自主理解并完成闭环修复。
- 双轨审计机制：引入专门的“审计Agent”，对主开发Agent的每次代码提交进行实时审查和拦截。这相当于让AI之间相互进行Code Review，极大提升效率与可靠性。
维度三：熵管理与反馈回路（Entropy Management）
软件系统天然会腐化，AI生成的代码尤其容易留下“烂摊子”。这一维度旨在防止系统随时间推移变得不可维护。
- 反熵Agent（Anti-Entropy）：安排一个专门Agent定期扫描代码库，自动清理过期文档、识别并修复漂移模式、移除无用依赖。它如同代码库的保洁员，常年运转。
- 实时演进：通过持续监控和自动化验证，对系统缺陷进行实时反馈与修复。这不仅维持系统健康，也持续驱动Agent自身的迭代。
4. 核心实践：OpenAI的Codex极端实验
如果前述内容略显抽象，那么OpenAI内部记录的一个实践案例足以令人震撼：5名工程师，在5个月内，交付了100万行代码，且这100万行代码中——0行是人类手写的。
这不是科幻小说，而是真实发生的实验。其成功依赖几个关键因素：
- 倒逼机制（Forcing Function）：整个团队直接禁止手动写代码。这迫使所有人的精力集中在一件事上——全力构建支撑Agent运行的基础设施（即Harness）。既然不能写，就必须把环境做到极致。
- 角色彻底转型：工程师的职责不再是写代码，而是成为环境设计师。日常工作从撰写业务逻辑，变为维护
AGENTS.md、编写自定义Linter规则、建立完整的可观测性体系。相当于从“运动员”转变为“教练员+场馆设计者”。 - 极高吞吐量：平均每人每天交付3.5个Pull Request，且大部分Code Review由Agent之间相互完成。这个速度远超人类团队能达到的水平。
5. 开发者如何构建自己的 Harness？
理论讲解完毕，回到实操层面。如果团队想要构建自己的Harness，该从哪里入手？
- 精炼
AGENTS.md索引
- 目录化：根目录下的该文件最好不超过100行。它应扮演“导航员”的角色。
- 模块化：架构、设计原则和安全约束等内容，拆分到
docs/目录下各自独立的文件中，例如docs/ARCHITECTURE.md或docs/SECURITY.md。 - 层级化：支持子目录级别的覆盖规则。例如针对特定模块，可在
modules/payment/AGENTS.override.md中定义更特殊的规则。
- 闭环反馈回路
- 接入自动触发的测试、Lint和安全扫描工具，确保每次代码变更都经过检查。
- 更重要的是，优化这些反馈信息的格式——使其更易于AI解析和理解。好的反馈不是一堆乱码，而是清晰的“问题+位置+修复建议”。
- 优化工作流习惯
- 热启动：下班前启动一个Agent进行深度调研或并行探索，第二天回看结果。这才是真正的“24小时持续迭代”。
- 职能分离：将模糊需求明确拆分为“规划（Planning）”和“执行（Execution）”两个阶段。先让Agent理解问题、设计方案，再生成代码。这能大幅减少无用功。
- 建立评估体系（Evals）
- 不要满足于CI通过就算合格。需要建立一套系统化的评估工具，专门衡量Agent的“意图”是否达成、生成代码的质量是否达标。这套体系，才是判断Harness是否有效的准绳。
总结
归根结底一句话：Harness Engineering = 用工程手段“驯服”大模型，将AI从不可预测的“艺术家”转变为可靠的“产品组件”。
软件工程团队的核心竞争力正在经历一次不可逆转的转移。它不再是“谁的代码写得漂亮”，而是“谁能设计出更好的Agent运行环境”。那些最早理解并实践这一转变的团队，将在未来的AI时代占据绝对的先手。这，才是真正的胜负手。
