Harness Engineering：Agent 时代，工程师的新战场

关注 AI 的同学大概率对这两个词已经不陌生了：提示词工程（Prompt Engineering）和上下文工程（Context Engineering）。前者教你怎么跟模型说话，后者教你往模型的上下文窗口里塞什么内容。但从 2026 年初开始，一个新的词开始在工程圈里流传——Harness Engineering。

这篇文章想聊聊这个东西到底是什么，它从哪里来，和前两者有什么区别，以及为什么它开始变得重要。

这个词是怎么来的

2026 年 2 月，HashiCorp 联合创始人 Mitchell Hashimoto（Terraform 的创作者）在博客里第一次明确提出了这个说法。他的核心观点很直接：每当发现 Agent 犯了一个错误，就花时间设计一个方案，确保它永远不会再犯同样的错误。

几天后，OpenAI 发布了一篇工程报告，标题叫"Harness engineering: leveraging Codex in an agent-first world"。报告里描述了一个实验：三名工程师用五个月时间，借助 Codex，构建了一个拥有约一百万行代码的内部产品，而且这期间没有一行代码是人工手写的。整个代码库——包括应用逻辑、测试、CI 配置、文档、内部工具——全部由 Agent 生成。效率大约是传统方式的十倍。

这篇报告一出，Harness Engineering 这个词就真正火了。Martin Fowler 随后写了深度分析，Ethan Mollick 也把自己的 AI 指南框架围绕这个概念重新整理了一遍。

"Harness"这个词什么意思

Harness 是马具的意思——缰绳鞍具那一套，把马的力气引导到正确方向上。类比 AI Agent 很贴切：大模型跑得快，但容易跑偏，Harness 就是那套把它拉住、引导它的机制。

Harness Engineering，直译"驾驭工程"，指的是围绕 AI Agent 构建约束机制、反馈回路和持续改进循环的系统工程实践——核心问题是：Agent 有了强大的代码生成能力之后，怎么确保输出可靠、一致、长期可维护。

和提示词工程、上下文工程有什么区别

这三者是嵌套关系，不是替代关系。

提示词工程关注的是单次交互：怎么写一个好 prompt，让模型给出更好的回答。这是最早被广泛讨论的技术，也是大多数人入门 AI 的第一步。它的粒度很小，主要在"这一句话怎么说"这个层面。

上下文工程关注的范围更大一些：给 Agent 看什么信息，怎么组织这些信息，让它在执行任务时有足够的背景。比如怎么管理上下文窗口里的内容，怎么在多轮对话中保持信息的连贯性，怎么让 Agent 知道代码仓库的结构和规范。

Harness Engineering 关注的是整个系统层面：Agent 运行在什么样的环境里，这个环境有哪些约束和反馈机制，当 Agent 出错时系统怎么自动纠正，人类的判断力怎么被编码进系统里持续发挥作用。

有人打了个比方：模型是 CPU，Harness 是操作系统。CPU 再强，操作系统设计得差也白搭。另一种说法更直接：上下文工程管的是"给 Agent 看什么"，Harness Engineering 管的是"系统怎么防崩、怎么量化、怎么修"。

维度	提示词工程	上下文工程	Harness Engineering
关注层级	单次交互	单次任务	整个系统
核心问题	这句话怎么说？	给 Agent 看什么？	系统怎么防崩、怎么修？
操作对象	Prompt 文本	上下文窗口内容	约束机制 + 反馈回路
作用时机	发送请求前	任务执行期间	持续运行
典型产出	更好的回答	更准确的任务执行	可靠、可维护的系统
类比	怎么跟马说话	给马看什么地图	设计缰绳和跑道

为什么需要它

有一个实验数据很能说明问题。Can.ac 团队只改变了 Harness 的工具格式（也就是 Agent 和代码文件交互的接口方式），没有动任何模型权重，结果在 16 个不同模型上都显著提升了编码基准分数。其中效果最明显的 Grok Code Fast 1，从 6.7% 跳到了 68.3%。

这说明什么？在很多情况下，限制 Agent 表现的不是模型本身的能力，而是它运行的环境和约束机制。

OpenAI 的工程团队在报告里说得很坦率：真正卡住他们的不是 Codex 写代码的能力，而是围绕它的结构、工具和反馈机制跟不上。五个独立团队得出了相同的结论：基础设施才是瓶颈，不是智能水平。

Agent 在没有约束的环境里会暴露出几个典型问题：

第一，倾向于一次把所有事情做完，结果做到一半上下文窗口耗尽了，下一个会话启动时面对的是半成品代码，完全不知道之前发生了什么。

第二，在项目后期，看到已经完成了一些功能，就直接宣布任务完成，哪怕还有大量工作没做。

第三，写完代码就标记为完成，根本没做端到端测试。单元测试通过了不代表功能真正可用。

第四，每次新会话启动时，需要花大量精力弄清楚怎么运行这个项目，而不是把时间花在实际开发上。

这些问题靠更好的 prompt 很难根本解决，需要在系统层面设计对应的机制。

Harness Engineering 主要做什么

综合 OpenAI、Anthropic 等团队的实践，Harness Engineering 大概围绕几个核心方向展开。

上下文的分层管理

不是把所有信息堆在一个地方，而是按需加载。OpenAI 的做法是维护一个简短的 AGENTS.md 文件（大约 100 行），作为入口，指向更深层的设计文档、架构说明、执行计划等。这些文档分层组织，Agent 从一个小而稳定的切入点开始，被引导去找更深层的信息，而不是一开始就被淹没。

有个值得注意的经验：上下文窗口不是填得越满越好。有研究者发现，上下文用到大约 40% 就开始走下坡路，超过这个比例，模型输出质量会明显下降——幻觉增多、格式出错、代码质量降低。给 Agent 塞一堆工具、冗长文档和累积的对话历史，不会让它更聪明，反而会让它变笨。

把约束机械化

文档记录是不够的。OpenAI 的原话是：如果约束不能被机械化地执行，Agent 就会偏离。

他们为代码仓库定义了严格的分层架构，每个业务域的代码只能按照固定方向依赖（Types → Config → Repo → Service → Runtime → UI），任何违反这个方向的代码都会被自定义 Linter 自动检测并阻止。这些 Linter 还有一个细节设计：错误消息不只是标记违规，还直接告诉 Agent 怎么修复。工具在 Agent 工作的同时"教会"它。

这种方式在传统团队里可能显得过于死板，但对 Agent 来说，约束越清晰，它反而能跑得越快，不会因为不知道边界在哪里而不断试错。

把代码仓库当作唯一事实源

Agent 在运行时无法访问的内容，对它来说就不存在。存在 Slack 讨论里的架构决策、写在 Google Docs 里的产品规范、只活在工程师脑子里的隐性知识——这些对 Agent 来说全是盲区。

OpenAI 的团队花了大量时间把团队知识迁移到代码仓库里，以版本控制的 Markdown 文档形式存放。他们甚至专门跑一个后台 Agent，定期扫描那些已经过时的文档，发起清理用的 Pull Request——由 Agent 为 Agent 维护文档。

反馈回路和可观测性

让 Agent 能够直接"看到"系统的运行状态。OpenAI 把 Chrome DevTools 接入了 Agent 的工作流，让 Codex 能够捕获 DOM 快照和截图，能够查询日志和指标。这样一来，"把启动时间降到 800 毫秒以下"这样的目标就变成了可度量、可验证的东西，Agent 可以自己跑应用、自己验证修复是否有效。

他们看到过单次 Codex 运行在单个任务上持续工作超过六个小时的情况，通常是在人类睡觉的时候。

熵管理

Agent 生成的代码积累技术债的方式和人写的代码不太一样。LLM 生成的代码经常重新实现已有的功能，会复现代码仓库里已有的模式——包括那些不好的模式。

OpenAI 最开始是每周五花 20% 的时间手动清理"AI 残渣"，后来意识到这不可扩展，改成了定期运行的后台 Agent，自动扫描偏差、更新质量评级、发起重构 Pull Request。大多数清理 PR 可以在一分钟内完成审查并自动合并。

工程师的角色在变

这件事背后有一个更大的变化：工程师在做什么这件事本身在发生改变。

当 Agent 承担了大量代码生成的工作，工程师的主要工作就不再是写代码了，而是设计 Agent 能够高效工作的环境。当 Agent 卡住时，问题不是"再努力一点"，而是"它缺少什么样的能力，怎么让 Agent 自己去构建这个能力"。

OpenAI 的工程师描述了一种工作方式：他们几乎完全通过 prompt 与系统交互，描述任务，运行 Agent，允许它打开 Pull Request，再对结果进行审查。人类的时间和注意力成了真正稀缺的资源，所有的设计都在围绕怎么最大化利用这个资源。

规划变得比以前更重要。Cloudflare 的一位工程师总结了一条原则：永远不要让 Agent 在你审查和批准书面计划之前写代码。先把计划做对，实现才会可靠；计划有误，500 行代码生成出来之后再改就麻烦多了。

还有什么没解决

这个领域还很新，有三个核心问题暂时没有答案：遗留代码库怎么改造（现有成功案例全是从零开始）、功能正确性怎么验证（防错容易，验对难）、AI 生成代码的长期技术债怎么治理（积累规律和人写的代码不同）。

小结

Harness Engineering 代表的是一种视角转变：从"怎么让模型写出更好的代码"，到"怎么设计一个让模型可以可靠工作的系统"。这不是等更强的模型出来就能解决的问题——模型越强，能给的自主权越大，围绕它的约束和反馈机制反而需要越完善。

如果只记一句话：瓶颈不在智能，而在基础设施。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传优快云，朋友们如果需要可以微信扫描下方优快云官方认证二维码免费领取【保证100%免费】