2026 年初AI 工程圈被一个词刷屏了——Harness Engineering。它不是又一个换皮概念而是一场正在发生的范式革命。本文将结合OpenAI、Anthropic、HashiCorp 等一线团队的实践带你一次性搞懂Harness 工程到底是什么、它和 Prompt/Context 工程是什么关系、以及为什么说瓶颈不在模型智能而在基础设施。目录一个颠覆认知的事实什么是 Harness EngineeringAI 工程范式的三次进化Agent 常见的四种翻车姿势Harness Engineering 的四大支柱支柱一上下文架构Context Architecture支柱二Agent 专业化Agent Specialization支柱三持久化记忆Persistent Memory支柱四结构化执行Structured Execution四大护栏OpenAI 的百万行代码实践护栏一上下文工程——AGENTS.md 活文档护栏二架构约束——用 Linter 做缰绳护栏三反馈循环——智能体审智能体护栏四熵管理——垃圾回收工程师角色的转变从写代码到设计环境六大行业共识还有哪些未解难题写在最后一个颠覆认知的事实先看两组数据OpenAI 的百万行代码实验3 名工程师5 个月产出约 100 万行代码手写代码 0 行合并 PR 约 1,500 个人均日提 3.5 个 PR——效率提升约 10 倍。LangChain 的 Harness 优化实验底层模型一个参数都没动仅仅优化了外部驾驭环境文档结构、验证回路、追踪系统编码 Agent 在 Terminal Bench 2.0 的得分从 52.8% 飙升至 66.5%全球排名从第 30 位跃升至第 5 位。更有说服力的是 Can.ac 的实验仅改变 Harness 的工具格式编辑接口就在 16 个模型上显著提升了编码基准分数。效果最显著的 Grok Code Fast 1 从 6.7% 跃升至 68.3%——没有修改任何模型权重。五个独立团队得出了同一个结论真正卡住 AI Agent 的不是写代码的能力而是围绕它的结构、工具和反馈机制跟不上。瓶颈在基础设施不在模型智能。这就是 Harness Engineering 要解决的问题。什么是 Harness EngineeringHarness Engineering驾驭工程是围绕 AI 智能体设计和构建约束机制、反馈回路、工作流控制和持续改进循环的系统工程实践。它的核心哲学可以浓缩为八个字人类掌舵智能体执行Human Steer, Agent Execute。“Harness一词来自马具——缰绳、马鞍、嚼子——这是一套引导强大但不可预测的动物的完整装备。驾驭工程不是去削弱 AI 的能力而是为它打造一套黄金缰绳”让它跑得又快又稳。这个概念由 HashiCorp 联合创始人Mitchell Hashimoto在 2026 年 2 月 5 日首次明确提出。他在博客中写道“Harness engineering is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent will not make that mistake again in the future.”这句话的潜台词是Agent 的每一次失败都是环境设计不完善的信号。正确的回应不是换一个更强的模型而是重新设计它运行的环境。六天后OpenAI 在百万行代码实验报告中正式采用这一术语。随后 Martin Fowler 撰文深度分析Ethan Mollick 以此重组了他的 AI 指南框架。一个月内Harness Engineering 成为开发者社区的高频词。AI 工程范式的三次进化要理解 Harness Engineering 为何重要需要先看清我们是怎么一步步走到这里的。范式核心问题优化对象交互模式提示词工程怎么把话说清楚Prompt 的措辞、格式、示例一问一答上下文工程怎么给 AI 喂信息文档、代码片段、历史对话信息注入 → 生成驾驭工程怎么让 Agent 可靠工作约束、反馈回路、控制系统人类掌舵Agent 执行一个好记的类比Prompt Engineering—— 对马喊话的技巧Context Engineering—— 给马看的地图Harness Engineering—— 给马造一条高速公路配上护栏、限速牌和加油站Phil Schmid 的比喻更技术化模型是 CPUHarness 是操作系统——CPU 再强OS 拉胯也白搭。mtrajan 的区分则更直接Context Engineering 管的是给 Agent 看什么Harness Engineering 管的是系统怎么防崩、怎么量化、怎么修。Harness 不优化模型本身而是优化模型运行的环境。它不替代 SDK、脚手架或 Agent 框架而是位于它们之上的驾驭层——解决持久化、确定性重放、成本控制、可观测性、错误恢复这些框架覆盖不到的问题。Agent 常见的四种翻车姿势Anthropic 工程师在长时间运行 Agent 的过程中总结了四种典型的失败模式正是 Harness Engineering 要解决的核心痛点失败模式 1试图一步到位One-shottingAgent 倾向于在一个会话里把所有功能都做完。结果是上下文窗口耗尽留下一堆没有文档的半成品代码下一个会话启动时只能花大量时间猜测之前发生了什么。失败模式 2过早宣布胜利在项目后期当部分功能已经完成后Agent 会环顾四周看到已有进展就直接宣布任务完成——即使还有大量功能未实现。失败模式 3过早标记功能完成在没有明确提示的情况下Agent 写完代码就标记为完成却没有做端到端测试。单元测试或 curl 命令通过了不代表功能真正可用。失败模式 4环境启动困难每次新会话启动时Agent 需要花费大量 token 弄清楚如何运行应用、如何启动开发服务器而不是把时间花在实际开发上。此外Agent 还有一个危险特性它非常擅长模式复制。代码库里有什么模式它就忠实地复制并放大——包括坏模式和架构漂移。不加约束的 Agent 会以惊人的速度积累技术债务。Harness Engineering 的四大支柱综合 OpenAI、Anthropic、Stripe、HashiCorp 等多个团队的实践Harness Engineering 可以归纳为四个核心支柱。支柱一上下文架构Context Architecture核心原则Agent 应当恰好获得当前任务所需的上下文——不多不少。每个团队都独立发现将所有指令塞进一个文件无法扩展。解决方案是分层上下文与渐进式披露。Vasilopoulos 在 2026 年的论文中将上下文形式化为三层层级加载时机内容示例上下文占用Tier 1会话常驻每次会话自动加载AGENTS.md / CLAUDE.md项目结构最小Tier 2按需加载子 Agent 或技能被调用时专业化上下文、领域知识中等Tier 3持久化知识库Agent 主动查询时研究文档、规格说明、历史会话按需Dex Horthy 有个很实用的经验观察上下文填得越满LLM 输出质量越差。以 168K token 的上下文窗口为例大约用到 40% 就开始走下坡路——超过这个阈值Agent 会进入Dumb Zone出现幻觉、循环、格式错误的工具调用和低质量代码。支柱二Agent 专业化Agent Specialization核心原则专注于特定领域、拥有受限工具的 Agent 优于拥有全部权限的通用 Agent。Carlini 在 Anthropic 的 C 编译器项目中将 Agent 专业化为编译器核心、去重、性能优化和文档四类角色。Vasilopoulos 部署了 19 个领域特定 Agent。专业化不仅是组织性的——它本身就是上下文管理策略。每个专家因为携带更少的无关信息所以运行在Smart Zone内。典型的角色分工包括研究 Agent只读探索、规划 Agent分解任务、执行 Agent限权实现、审查 Agent审计标记、调试 Agent修复问题、清理 Agent对抗熵增。支柱三持久化记忆Persistent Memory核心原则进度持久化在文件系统上而非上下文窗口中。每次新 Agent 会话从零开始通过文件系统制品重建上下文。Anthropic 解决这一问题的方案堪称经典初始化 Agent首次会话建立初始环境——init.sh 脚本、claude-progress.txt 进度文件和初始 git 提交。从高级 prompt 生成综合 feature 列表单个 Web 应用可能超过 200 个独立功能每个都有明确的测试步骤全部初始标记为 “failing”。编码 Agent后续每次会话的启动流程标准化——运行 pwd 查看目录 → 读取 git log 和进度文件 → 读取 feature list 选择最高优先级任务 → 启动开发服务器运行基础测试 → 确认一切正常后开始新功能开发 → 结束时提交 git 和进度更新。关键发现使用 JSON 格式追踪 feature 状态比 Markdown 更有效因为 Agent 不太可能不恰当地修改或覆盖结构化数据。支柱四结构化执行Structured Execution核心原则将思考与执行分离。所有团队都施加了刻意的执行序列理解 → 规划 → 执行 → 验证。Cloudflare 的 Boris Tane 将此原则总结为一句话“永远不要让 Agent 在你审查和批准书面计划之前写代码。这种规划与执行的分离是我做的最重要的一件事。”审查计划远比审查代码快。当规格正确时实现自然可靠。当规格有误时可以在 500 行代码生成之前及时纠正。这是驾驭工程中投入产出比最高的实践之一。四大护栏OpenAI 的百万行代码实践OpenAI 三名工程师在 5 个月内用 Codex 构建了约 100 万行代码的产品提炼出五大 Harness 原则。结合其他团队的实践可以归纳为四根护栏护栏一上下文工程——AGENTS.md 活文档AGENTS.md 是一个新兴的开放约定——本质上是给 AI Agent 的 README。它不是一次性编写后遗忘的静态文档而是活的反馈循环每当 Agent 犯错时就更新。Mitchell Hashimoto 的 Ghostty 项目 AGENTS.md 里每一行都对应一个历史 Agent 失败案例。OpenAI 的进阶做法是不维护一个巨大的指令文件而是构建一个小型 AGENTS.md指向更深层的事实源——设计文档、架构图、执行计划、质量评级——全部版本控制并维护在仓库中。甚至有一个专门的Doc-gardening Agent文档园丁代理在后台自动扫描文档与代码之间的不一致发现过时内容就自动提交 PR 修复——Agent 为 Agent 维护文档。护栏二架构约束——用 Linter 做缰绳OpenAI 团队建立了严格的层级依赖模型Types → Config → Repo → Service → Runtime → UI下层不能反向依赖上层。所有架构规则被编码为自定义 Linter 规则违反即 CI 阻止合并——无论代码是人写的还是 AI 写的。有个关键细节Linter 的错误信息本身也是上下文工程。它不只说你违反了规则 X而是解释为什么这个规则存在、正确做法是什么。这样 Agent 读到错误后就能自我理解并修正不需要人类介入。工具在 Agent 工作时同时教会它。护栏三反馈循环——智能体审智能体传统开发中人类工程师负责 Code Review。在驾驭工程中这个工作变成了智能体对智能体的方式Codex 在本地审核自身更改请求额外审查循环往复直到通过。反馈循环中的钩子可以运行预定义的测试套件并在失败时带着错误信息循环回到模型或者提示模型独立评估其代码。如果 AI 写的测试用例通过了带有 Bug 的代码Harness 就会判定测试无效强迫它重新思考测试边界。护栏四熵管理——“垃圾回收”OpenAI 团队最初每周五花 20% 的时间手动清理AI Slop低质量生成物。后来这被自动化为 Codex 运行的后台任务——清理吞吐量与代码生成吞吐量成正比扩展。定期运行后台任务扫描偏差、更新质量等级、发起针对性重构 PR。工程师角色的转变从写代码到设计环境所有团队的实践都指向同一个结论工程师的工作正在从代码的编写者变成环境的建筑师。Greg Brockman 建议每个团队指定一名Agent 队长——负责思考 Agent 如何融入团队工作流。Peter SteinbergerOpenClaw 创作者在一个月内完成了 6,600 次提交同时运行 5-10 个 Agent。这不是一个人写了 6,600 次代码而是一个人驾驭了 5-10 个 Agent 产出了 6,600 次提交。正如 Addy Osmani 所言“AI 编码的兴起并没有取代软件工程的工艺——它抬高了工艺的门槛。”软件开发的未来可能不再是关于我们能写多快多好的代码而是关于我们能设计多聪明、多鲁棒的系统来驾驭 AI 代理的巨大能量。工程师的价值正在从执行者转变为赋能者和系统思考者——从构建产品转向构建能够构建产品的工厂。六大行业共识综合 OpenAI、Anthropic、LangChain、Stripe、HashiCorp、Martin Fowler 等 8 个独立信息源的交叉对比业界在以下六个方面已形成明确共识瓶颈在基础设施不在模型智能——五个独立团队得出相同结论是最核心的共识。文档必须是活的反馈循环——静态文档是坟场动态文档才有价值。让后台 Agent 定期清理过时文档并提交 PR。思考与执行必须分离——复杂任务不可能在单个上下文窗口内完成先规划再执行是所有团队的共同选择。上下文不是越多越好——上下文是稀缺资源约 40% 窗口利用率是甜蜜区间应按需检索、动态注入。约束必须自动化执行——人工 Review 是瓶颈。护栏要编码为 Linter、CI、类型系统让机器来执行而非人。工程师角色在转变——从代码的编写者变成环境的建筑师。最大的工程挑战是设计让 Agent 可靠工作的控制系统。还有哪些未解难题尽管共识已经清晰但 Harness Engineering 领域仍有三大空白区亟待填补棕地项目的 Harness 改造。所有公开的成功案例——OpenAI、Carlini、Anthropic、Stripe、Hashimoto——全部是绿地项目或可控环境。对于十年历史的遗留代码库如何引入 Harness Engineering目前零成功案例、零方法论。功能验证的系统化方案。目前大家擅长的是约束 Agent 不做错事架构约束、Linter、类型检查但验证 Agent 做对了事这个问题远未解决。AI 生成代码的长期可维护性。Greg Brockman 抛出的问题至今无人回答怎么防止功能没问题但维护性很差的代码渗透进代码库Agent 写的代码和人写的代码积累技术债的方式不一样。写在最后Harness Engineering 标志着 AI 辅助开发从让模型写代码到设计让模型可靠工作的系统的范式转变。这不是等更强模型出来就能解决的事——模型越强能给的自主权越大护栏就得越好。Birgitta Böckeler 的总结最为精辟“为了获得更高的 AI 自主性运行时必须受到更严格的约束。增加信任需要的不是更多自由而是更多限制。”就像高速公路上的护栏——正是因为有护栏你才敢踩到 120 码。如果只记一句话瓶颈不在智能而在基础设施。每一次 Agent 的失败都不是换更强模型的理由而是重新设计它运行环境的信号。
