模型只是起点真正决定AI应用能否落地的是驾驭它的那套“控制系统”最近这两个月如果你关注AI开发相关的内容有一个词你绝对绕不开——Harness EngineerHannes Engineer或者更常见的Harness Engineer即“马具工程师”。这个词在AI圈传播得非常快但很多人提到它时其实说不清楚它到底是什么它与之前的概念有什么本质区别以及——为什么它会在2026年变得如此重要。今天这篇文章我们就来认真地讲一下Harness Engineer的来龙去脉。一个背景更正Harness意为“马具、挽具”引申为“驾驭、控制工具的一套系统”。圈内流行的公式Agent Model Harness正是此意模型是一匹有力的马而 Harness 则是驾驭它的那套完整装备缰绳、马鞍、指令、护栏。所以下文我们统一使用Harness Engineer或“马具工程师”。范式跃迁三代AI工程的血泪史要理解 Harness Engineer得先把它放到整个行业演进的脉络里看。过去三年AI工程领域经历了三次范式跃迁。每一次跃迁都是前一代方法撞到了规模的天花板然后被更完整的框架所取代。第一代Prompt Engineer提示词工程师时间跨度约2022年 - 2024年ChatGPT 横空出世后所有人都兴奋地玩了起来。慢慢地大家发现同样问一个问题有人得到的答案一塌糊涂有人却能拿到精准有用的结果。于是“如何和AI对话”变成了一门学问。核心做法调整措辞加上角色设定“你是一位资深架构师……”引导模型“一步步思考”Chain-of-Thought提供几个参考示例Few-shot这些技巧确实有用但它们的天花板也很明显只适合“问一个问题得一个答案”的简单场景。一旦任务变复杂比如“写一段完整可上线的代码”或者“调研竞品并形成一份报告”精心设计的 Prompt 就撑不住了。模型不知道背景信息记不住长上下文也无法访问外部数据——巧妇难为无米之炊。第二代Context Engineer上下文工程师时间跨度约2025年中开始普及2025年全球最具权威的IT研究公司 Gartner 直接宣布Prompt Engineer 已经过时Context Engineer 才是现在的主角。核心洞察是影响模型输出质量的不是你“怎么问”更重要的是模型在回答之前“看到了什么”。说白了上下文窗口里的所有内容——系统提示词、从知识库检索到的相关文档、工具调用的结果、对话历史保留多少——这些加在一起才是模型真正“看到”的东西。在RAG和Agent普及之后工程师们意识到AI应用的核心竞争力之一就是Context的组装能力。什么时候该检索记忆怎么管工具结果如何整合但是Context Engineer 也有自己的天花板它解决了“模型知道什么”的问题却没有解决“模型做完一件事之后怎么验证对错、怎么纠错、怎么在生产环境长期稳定运行”的问题。第三代Harness Engineer马具工程师时间2026年初爆发今年二月底OpenAI 的一篇工程师博客引爆了行业。文章里讲了一个案例他们的团队3-7人花了5个月时间用 Cursor 生成了近100万行生产级代码提交了1500个PR。团队扩展到7人后吞吐量达到每个工程师每天提交3.5个PR。你可能对这个数字没有概念——一个普通工程师认认真真做一个PR可能就要半天到一天。他们居然能做到一个人每天3.5个。后来有人把这个思路提炼成一个公式在圈内广为流传Agent Model Harness这个等式说清楚了一件事Agent 不只是模型本身。模型是那匹有力的马但马不知道往哪跑——Harness 就是驾驭它的那套完整装备。具体来说Harness 包括工具与权限Agent 能调用什么、不能碰什么护栏规范与文档告诉它该做什么、怎么做反馈机制验证它做对没做错可观测性出错了人能发现、能追溯Harness Engineer 最核心的心法可以概括为一句话每当你发现 Agent 犯了一个错误你应该花时间设计出一个解决方案让 Agent永远不再犯同样的错误。但遗憾的是大多数团队根本做不到这一点。一个扎心的数字88%Harness Engineer 被提出后行业里经常被引用一个数字88%的AI项目最后都没能真正跑上线。你可能觉得这个数字有点夸张。模型已经这么强了为什么失败率还这么高原因肯定不是模型不够好而是大家只关注“选什么模型”、“怎么写Prompt”却没有建立完整的Harness。Agent 在做简单任务时没有 Harness 也能跑。但当你让它自主运行几百步操作时人工审查就成了瓶颈。你不可能盯着每一个输出。缺少自主验证的系统就会失控——一个错误没有被发现后面的所有操作都基于错误的前提往下走结果一塌糊涂甚至无法追溯。最直接的切入口agent.mdHarness Engineer 要真正落实到具体操作上有一个东西特别值得单独拎出来——它是Harness里面门槛最低的切入口。2025年8月OpenAI、谷歌、Cognition、Factory 等公司联合发布了一个开放标准专门为AI编程Agent设计的约束文件就叫agent.md。你可以把它理解成项目的员工手册但是读者不是人类工程师而是AI Agent。在agent.md里面你可以规定代码风格、命名规范哪些文件不能碰测试要求提交前的检查项发生错误之后怎么办优化这个.md文件。下次Agent再遇到类似场景就不会犯同样的错了。这恰好呼应了上面那句心法让Agent永远不再犯同样的错误。认知升级从模型能力到组织能力Harness Engineer 这个范式的转移表面上看只是换了一套工具和方法但它背后是一次深刻的认知升级。过去三年整个行业的注意力几乎都在模型本身上更大的参数、更强的推理、更长的上下文、更低的幻觉率。潜台词也很简单只要模型足够聪明所有问题都能解决。但 Harness Engineer 给出了一个完全不同的答案方向模型够不够聪明只是起点。AI系统能不能稳定可靠地跑起来关键看你有没有给它设计一套合格的控制系统。它最颠覆的地方在于它把瓶颈从“模型的能力”转移到了“人类的组织能力”上。一个 Harness 写得好不好本质上是看这个团队的集体智慧有没有被清晰地写进系统里你的agent.md里写了什么测试覆盖了哪些场景验证流水线检测了哪些维度这些东西都是团队以前踩过的坑、达成的共识、积累下来的判断。在Harness的时代它们会以一种全新的方式继续发挥作用。换句话来说以前隐藏在工程师脑子里那些默会的知识——这个模块要不要动这个改法会不会破坏框架这个接口是遗留债务——以前要靠Code Review、靠传帮带、靠老员工提醒。现在你只要把这些东西显式地写出来变成Harness的一部分。这个过程本身就很有价值它逼迫你把团队里那些从来没有被说清楚过的判断和规范终于整理清楚了。工程师的角色从对话者到系统设计者还有一个大家一直担心的问题AI到底会不会把工程师的判断也替代掉Harness Engineer 反而告诉我们工程师的判断不会消失只会被放大。因为有了Harness这个中间层你一次做出的判断就变成了对所有Agent行为的长期约束力。以前是工程师每次亲自盯着、亲自把关。 现在是工程师先把自己的经验变成规则、设计好再让这些规则替你把关。前者是靠人盯后者是靠系统。所以从这个角度来看Harness Engineer 其实是把软件工程里面最古老的那个洞察换了一种更贴切AI时代的说法重新讲了一遍一个好的系统不依赖“好的人”而是依赖“好的结构”。那么在Harness Engineer的时代工程师的角色变成了什么时代工程师的核心工作Prompt Engineer学会和AI对话Context Engineer学会组装上下文Harness Engineer设计控制系统具体来说Harness Engineer的工作变成了拆解目标构建Harness的各个组件让Agent执行验证结果根据错误改进HarnessOpenAI那个团队能做到每人每天3.5个PR不是因为他们写得特别快而是因为他们把精力放在了设计和维护Harness上让Agent帮他们去写。总结从 Prompt Engineer → Context Engineer → Harness Engineer每一次跃迁背后的逻辑都是一样的前一代方法撞上规模的天花板后就需要一套更完整的框架来承接下一个阶段的复杂性。Harness Engineer 现在还处于很早期很多工具和最佳实践还在形成当中。但这个方向已经非常清楚了模型本身只是起点真正让Agent稳定可靠地跑起来的是驾驭它的那套控制系统——Harness而设计这套控制系统的人可能就是你