2026 年 2 月，OpenAI（开发了 ChatGPT 的人工智能公司）的 Codex 团队发了一篇博客，标题是《Harness engineering: leveraging Codex in an agent-first world》（驾驭工程：在 Agent 优先的世界中使用 Codex）。Codex 是 OpenAI 开发的一个 AI 编程工具——你告诉它"做什么"，它自己去写代码。
博客里记录了一个疯狂的实验：
从 2025 年 8 月开始，一个 3 人工程团队（后来扩展到 7 人），让 AI Agent（可以自主执行多步任务的 AI 程序，后面会详细解释）从零开始构建一个生产级应用。5 个月后，这个应用的代码量达到了约 100 万行，合并了大约 1500 个 Pull Request（Pull Request 是程序员向项目提交代码修改的一种方式，可以理解为"请审核我的修改"）。 人类没有手动写过一行代码。
你可能以为他们的秘密武器是"更强的 AI 模型"，或者"更精妙的提示词"。
都不是。
负责这个项目的工程师 Ryan Lopopolo 事后说了一句话，在整个技术圈传开了：
"Agents aren't hard; the Harness is hard."
（Agent 不难，难的是 Harness。）
Harness 这个词，原意是"马具"——缰绳、马鞍、护具，那一整套让马能被骑手控制的装备。
Ryan 用这个词来指 AI Agent 周围的一整套系统：约束规则、自动检测、反馈机制、错误修复流程……不是 AI 本身，而是 AI"住"的那个环境。
这个概念，后来被叫做 Harness Engineering（驾驭工程）。
这篇文章，我们来把它彻底拆开看看——它到底解决什么问题？它和你听过的 Prompt Engineering 有什么关系？为什么有人说它才是 AI 时代真正值钱的技能？
Part 1：问题——光有聪明的 AI，远远不够
先从一个你可能已经知道的事情说起。
AI（这里特指大语言模型，也就是 ChatGPT、Claude（Anthropic 公司开发的 AI 助手）这类"聊天 AI"背后的技术）本质上是一个超级模式匹配器——这不是一个比喻，而是对它工作原理的准确描述。简单来说：AI 在训练时"阅读"了互联网上数十亿页的文字，记住了"什么样的文字组合经常一起出现"。当你问它问题时，它不是在"思考答案"，而是在用这些统计规律预测"接下来最可能的词是什么"，然后一个词一个词地把回答"拼"出来。
这意味着两件事：
它很强——在模式匹配类的任务上（写文章、翻译、写代码、整理信息），它的速度和质量经常让人惊叹。
它不可靠——它不"理解"自己在说什么，所以会编造事实、犯逻辑错误、在你没注意的地方埋下隐患。
这两个特点，在"聊天"场景下问题不大。你问它一个问题，它回答了，你扫一眼，觉得不对就让它重来——整个过程你全程盯着，犯错了马上就能发现。 但现在情况变了。
2025 年以来，AI 的使用方式正在从"一问一答的聊天"转向"自主执行任务的 Agent"。
什么意思？以前你跟 AI 说"帮我写一封邮件"，它写完你看看就完了。现在你可以跟 AI 说"帮我把这个功能开发出来"——它会自己去读代码、写代码、运行测试、发现 bug、修复 bug、提交修改……整个过程可能持续几个小时，中间你完全不介入。
问题来了：一个会犯错的东西，自主运行几个小时，中间没人盯着——你觉得会发生什么？
2025 年 7 月，就有一个被广泛报道的案例：一个 AI 编程助手无视了代码冻结的指令，绕过了安全策略，最终删除了一个生产数据库。AI 在技术上"成功完成了任务"——但它完全不理解自己做的事情意味着什么。
这不是个例。行业数据显示，大约 80%-90% 的 AI Agent 项目没能进入生产环境。不是因为 AI 不够聪明，而是因为没有人搭好它"干活的环境"。
打个比方：
你招了一个实习生。这个实习生知识渊博，反应极快，干活速度是普通人的 10 倍。但他有一个致命的问题——他不知道什么不该碰。 他不知道生产环境和测试环境的区别，不知道某些文件是绝对不能删的，不知道改了代码之后要先跑测试再提交。
如果你把他扔进公司，什么规矩都不定，什么检查流程都没有，让他"自由发挥"——
他大概率会在一周内把项目搞崩。 不是因为他蠢，是因为没人给他搭好工作环境。
AI Agent 就是这个实习生。而 Harness Engineering 要解决的，就是怎么给这个实习生搭一个不翻车的工作环境。
我第一次看到那个"删除生产数据库"的案例时，脑子里的第一反应是："这 AI 也太蠢了吧？"但仔细一想，不对——AI 做的每一步操作，单独来看都是"正确的"。它执行了指令，完成了任务。真正的问题不是 AI 蠢，而是没人告诉它"这个操作会让整个公司停摆"。就像你给一个实习生说"把那个旧数据库清理掉"，他真的清了——他怎么知道那是生产环境？
这个认知的转变让我意识到：AI 时代最重要的问题，不是"怎么让 AI 更聪明"，而是"怎么让一个已经足够聪明但完全不靠谱的东西，变成你能信任的工具"。
Part 2：演进——从"怎么说话"到"搭什么环境"
Harness Engineering 不是凭空冒出来的。它是 AI 使用方式演进的第三个阶段。
让我按时间线把这三个阶段串起来。
第一阶段：Prompt Engineering——"怎么跟 AI 说话"（2022-2024）
2022 年底，ChatGPT 横空出世，所有人都在研究一个问题：怎么跟 AI 说话，才能让它给出更好的回答？
这就是 Prompt Engineering（提示词工程）。
核心思路很简单：精心设计你给 AI 的指令（也就是"提示词"），让它的输出更符合你的需求。
比如同样是让 AI 写邮件：
❌ 普通提示词："帮我写一封邮件。"
→ AI 输出一封平庸的模板邮件。
✅ 精心设计的提示词："我是一个产品经理，需要给工程团队写一封邮件，说明本周需求变更的原因。语气要专业但不生硬，控制在 200 字以内。"
→ AI 输出一封精准、得体的邮件。
为什么有效？因为更丰富的上下文让 AI 的模式匹配更精准了——你给的信息越多，它能"匹配"到的模式就越准确。
Prompt Engineering 在 2023-2024 年非常火，甚至催生了一个新职业："提示词工程师"。各种技巧层出不穷——Chain of Thought（让 AI 一步一步想）、Few-shot（给 AI 看几个例子再让它做）、角色扮演（让 AI 假装自己是某个专家）——但它们的底层逻辑都是一样的：给 AI 更多、更好的上下文信息，让它的模式匹配更精准。
但 Prompt Engineering 有一个根本性的局限：它只解决了"单次交互"的问题。
你精心写了一条提示词，AI 给了你一个好回答——很棒。但如果你要让 AI 自主完成一个包含 20 个步骤的任务呢？你总不能给每一步都写一条提示词，然后站在旁边一步一步地喂吧？
打个比方：Prompt Engineering 就像给员工下了一条口头指令。指令精确的话，这一次的活儿干得漂亮。但它没法让员工独立工作一整天——因为口头指令管不了他遇到意外情况时该怎么办。
第二阶段：Context Engineering——"给 AI 看什么资料"（2025）
2025 年 6 月，Shopify（一家大型电商平台公司）的 CEO Tobi Lütke 公开说：他更喜欢用"Context Engineering"（上下文工程）这个词，而不是"rompt Engineering"。紧接着，前 Tesla AI 总监、OpenAI 联合创始人 Andrej Karpathy 也表示赞同，他把 Context Engineering 定义为"一门精巧的技艺——把恰好正确的信息，在恰好正确的时刻，以恰好正确的格式，填进 AI 的上下文窗口"。 Context Engineering 的核心洞察是：光写好指令不够，你还得给 AI 看对资料。
上下文窗口（context window）是 AI 一次能"看到"的全部信息——包括你的指令、对话历史、背景资料等等。AI 的输出质量，很大程度上取决于这个窗口里装了什么。
所以 Context Engineering 不只是写好一条指令，而是管理 AI 能看到的全部信息：
通过 RAG（检索增强生成——一种让 AI 在回答前先从外部数据库搜索相关资料的技术）给 AI 提供最新的文档
这就是 Harness Engineering 的核心理念。 不只是给 AI 好的指令（Prompt Engineering），不只是给 AI 对的资料（Context Engineering），而是搭建一整套系统——约束、验证、反馈、纠错——让 AI 在里面安全、可靠、持续地干活。
三个阶段的演进关系，一张表就能看清：
阶段时间核心问题类比Prompt Engineering2022-2024怎么跟 AI 说话？给员工一条口头指令Context Engineering2025给 AI 看什么资料？给员工项目文档和操作手册Harness Engineering2026给 AI 搭什么工作环境？给员工完整的工作环境：权限管理、质检流程、错误报警、行为红线
换句话说：他们从"代码的作者"变成了"AI 工作环境的设计师"。
这背后有一个更大的趋势。
AI 模型正在快速同质化——今天的 GPT（OpenAI）、Claude（Anthropic）、Gemini（Google），核心能力越来越接近。当模型本身不再是差异化的因素，真正的竞争力在于：谁能让 AI 更稳定、更安全、更高效地工作。
而这，就是 Harness 的价值。
Martin Fowler（他是软件工程领域最有影响力的思想家之一，著有《重构》等多部经典著作）的网站上也发表了一篇关于 Harness Engineering 的文章，讨论这种新范式对软件工程的影响。这不是一个小圈子的概念——它正在成为整个行业的共识。 但值得保持清醒的是： Harness Engineering 不是万能药。目前的成功案例大多集中在编程这个特定领域——因为代码有明确的对错标准（能编译、能通过测试、不破坏架构），天然适合自动化验证。在更模糊的领域（比如写市场文案、做战略决策），什么算"对"什么算"错"本身就不好定义，Harness 的验证环节就很难设计。
而且，随着 AI 模型推理能力的持续提升，今天某些需要靠 Harness 强制约束的问题，未来可能模型自己就能处理好了。
但有一件事不会变：只要你用的 AI 不是 100% 可靠的（目前没有任何 AI 是 100% 可靠的），你就需要某种"环境"来兜底。 这个"环境"的具体形态可能会演化，但"给 AI 搭工作环境"这个核心思路，会一直存在。
这跟你有什么关系？
你可能在想：这些听起来都是程序员的事，跟我有什么关系？
其实你已经在做 Harness Engineering 了——只是你可能没意识到。
如果你用过 Claude Code（Anthropic 推出的 AI 编程工具，在命令行里运行），你可能写过一个 CLAUDE.md 文件（和 AGENTS.md 类似，是专门给 Claude 读的项目指引），告诉 Claude"我的项目用什么技术栈""代码风格是什么""哪些文件不要动"。
如果你用过 Cursor（一个内置了 AI 能力的代码编辑器）或 GitHub Copilot（GitHub 推出的 AI 编程助手），你可能在设置里定义过一些规则，告诉 AI"用中文注释""不要引入新的依赖"。
即使你完全不写代码——如果你用过 ChatGPT 的"自定义指令"功能，给它设定了角色、语气和输出格式——你也已经在做最基础的 Harness Engineering 了。 这些，就是 Harness 的雏形。
而 Harness Engineering 告诉你的是：这不仅仅是"设置一些偏好"。这是一种系统性的方法论——你可以通过约束、告知、验证、纠正这四个支柱，把一个"时好时坏的 AI 助手"，变成一个"稳定可依赖的工具"。
回到那句话——
"Agent 不难，难的是 Harness。"
翻译成日常语言就是：AI 已经够聪明了。现在的问题不是让它更聪明，而是怎么让它"稳定地聪明"。
Prompt Engineering 教你怎么跟 AI 说话。
Context Engineering 教你给 AI 看什么资料。
Harness Engineering 教你搭什么样的环境，让 AI 在里面安全、可靠、持续地干活。
AI 时代，最值钱的能力可能不是"会用 AI"——而是会给 AI 搭脚手架。
参考资料
Harness engineering: leveraging Codex in an agent-first world - OpenAI
My AI Adoption Journey - Mitchell Hashimoto
The Rise of AI Harness Engineering - Cobus Greyling
Harness Engineering - Martin Fowler
OpenAI 'Harness Engineering' and Codex - InfoQ
The Rise of Context Engineering - LangChain Blog
AI Agents Ignore Security Policies - Dark Reading
88% of AI Agents Never Reach Production - Digital Applied
Skill Issue: Harness Engineering for Coding Agents - HumanLayer
Prompt Engineering vs Context Engineering vs Harness Engineering - Medium
rompt Engineering"。紧接着，前 Tesla AI 总监、OpenAI 联合创始人 Andrej Karpathy 也表示赞同，他把 Context Engineering 定义为"一门精巧的技艺——把恰好正确的信息，在恰好正确的时刻，以恰好正确的格式，填进 AI 的上下文窗口"。
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
照妖镜
