从概念到实操都讲清楚！AI圈都在聊的Harness Engineering是什么？

一、全文速览图

最近AI圈造词的速度是真快，快到好多人已经追不上了。说真的，我是不急的，一个技术来了，也不差那一时半会去应用，能成为经典的东西不怕过时，还记得早期的提示词教程吗？当时大家到处找提示词模版，回头看那些模版根本不重要，懂怎么把意图表达清楚才重要。所以时间要花在刀刃上。

这不最近又有一个新概念叫Harness Engineering，说是特别的火，我群里已经聊的很high了，然后发现连我腾讯的同事最近也都在用这个新理念搞全自动化开发流程。

我研究了一圈下来发现，理解起来也不复杂。今天就把我的研究心得跟大家汇报下，从概念到实操，说清楚到底是咋回事。

二、Harness到底是什么？

Harness这个词，本来的意思是缰绳、马鞍那一整套控制马的装备。马是模型，跑得快，但自己不知道该往哪跑。咱们就是骑马的人，提供方向。Engineering就是工程的意思，没啥好说的。

说白了，Harness Engineering意思是给模型说清楚怎么把活干好。任务怎么拆、工具怎么用、做完了怎么验证、失败了怎么恢复、什么时候该把控制权交回给人，这些都是它要管的事。

咱们回头看看，过去两年AI其实经历了三次进化。

大模型刚火的时候，大家研究提示词怎么写，角色设定、风格约束、few-shot示例，这叫提示词工程（Prompt Engineering），关注的是怎么把任务说清楚。

后来发现光说清楚不够，模型得真的知道相关信息，于是有了上下文工程（Context Engineering），关注的是怎么把信息给对。

再后来发现信息给对了，模型也不一定能稳定执行。它可能计划做得很好但执行跑偏了，在很长的链路里慢慢偏航了系统却没发现。这就是Harness Engineering的出发点，关注的是怎么让模型在真实执行中持续做对。

三者是包含关系，Harness包含Context，Context包含Prompt。

用nano banana画的图

举个例子。假设你让一个设计师去完成一套 App的视觉改版。Prompt就是把需求讲清楚，风格走轻盈路线、主色品牌蓝。Context就是把资料备齐，包括竞品截图、设计规范、上一版评审意见之类的约束。

Harness是你在他交付前设好的一整套机制，每完成一个核心页面就拉你过一遍，交付前必须真机跑一遍，发现偏离设计语言的地方立刻纠正。这个对于做真实落地项目，就非常关键。

三、为什么现在突然火了

现在模型已经很强了，但光强没用。Anthropic（就是做出claude的公司）说得很具体，即使是最强的模型，只给一个“做一个网站"这样的提示词，依然生成不了能落地的应用。

还有一个很直观的数学问题。假设每一步成功率95%，连续20步之后端到端完成率只剩36%。这就是为什么Agent95%的时间都正常，但真实任务上还有三分之一失败率。说实话，这个问题是最让我烦的，用AI只要有叠加的错误率，有幻觉，就必须自己去检查，最后发现效率不一定有自己做的高。

再加上GPT、Claude、Gemini在核心能力上差距在缩小。模型决定了天花板，但Harness决定了地板。当模型本身不再是差异化因素，围绕模型的系统设计就成了新的竞争壁垒。

四、一个成熟的Harness长什么样

综合几家头部公司的实践，它的机制大概管这么几件事。

OpenAI早期犯过一个错误，把所有规范塞进一个巨大的AGENTS.md文件，结果Agent更糊涂了。上下文窗口是稀缺资源，塞太满等于什么都没说。后来改成目录页式的结构，只保留核心索引，详细内容按需加载。所以，让AI做东西必须要能做好上下文管理。

Vercel的经验很反直觉。他们最初给Agent配了全套工具库，结果效果很差，Agent做冗余调用、执行不必要的步骤。后来移除了80%的工具，反而更好。约束Agent的解决空间，反而能提升表现。跟我们觉得工具越多越好的直觉完全相反。所以，过程中应该要用哪些工具很重要。

模型独立的评估也很重要。Anthropic发现让模型评估自己的工作时，它会倾向于自信地表扬自己，即使质量明显不行。这不是哪个模型的问题，是自评估的系统性缺陷。工程化一个独立的评估器，远比教会生成器自我批评要容易。

还有一个很关键的能力，失败了能恢复。搜索不准、API超时、模型误解了任务，如果没有恢复机制，Agent每次出错就只能从头再来。解决办法是用外部文件记录进度，让Agent每次启动前先重建上下文。

五、Agent指挥Agent为什么更好？

理解了Harness就理解了多Agent。当你认真去搭建这些能力时会发现，一个Agent根本搞不定所有事。写代码的和验收的最好不是同一个Agent，做计划的和执行的也应该分开。

我们看下几家头部公司都是怎么弄的？

Anthropic从双Agent演进到三Agent架构。Planner负责把需求拆成可测试的功能清单，Generator负责逐步实现，Evaluator负责像QA一样真实测试，不只看代码，而是真的去操作页面、检查交互。最关键的发现是生成和评估必须分离，让干活的人自己打分，结果一定偏乐观。

Google DeepMind做数学研究的Agent也是三件套，Generator提出解法，Verifier检查逻辑缺陷，Reviser修复问题。两家公司不约而同用到了同一个设计模式。背后的道理很实在，干活的人和验收的人必须分开，你懂得。

OpenAI更激进，让几个人的团队用Agent从零构建了超百万行代码的产品，100%由Agent编写。人类不写代码，只负责设计环境。Agent失败时不是让它更努力，而是问环境里缺了什么能力，然后让Agent自己编写修复代码，形成自我改进的闭环。

但这里提醒一个容易误会的地方。一人公司不等于多Agent本身，真正的一人公司等于多Agent加Harness。没有Harness，你只是请了几个AI角色来帮忙。有了Harness，才是真正在搭一个能稳定运转的AI团队。

六、那普通人怎么上手？

理论讲完了，下面讲怎么做。不需要写代码，打开claude.ai就能开始。核心思路就是前面说的Planner-Generator-Evaluator三角色。

最简单的方法，直接在对话里模拟多Agent。每次新开一个对话窗口分阶段扮演，避免相互干扰，尽量做到客观公正。

比如我要写一篇公众号文章。新建一个对话，跟它说：你现在是一个内容策划专家。我想写一篇关于AI的公众号文章，目标读者是设计师。请帮我分析选题角度，给出3个可选方向，每个方向列出核心论点和文章结构。

选定方向后，再打开一个新的窗口，切换角色：就按方向二来。你现在是一个内容撰稿人，根据上面的分析逐段撰写完整文章，语言通俗、逻辑清晰。

文章写完后，再开一个新窗口，切换做评审：你现在是一个挑剔的编辑。审阅上面这篇文章：开头能不能抓住注意力？逻辑有没有跳跃？案例有没有说服力？有没有废话可以删？逐条给修改建议。

最后根据评审意见修改，输出终稿。同样一个Claude，分角色执行的效果比直接说"帮我写篇文章"好很多，因为评审者和生成者立场不同，不会自己夸自己。

七、Harness的价值远不止多开几个窗口

如果你觉得Harness就是多开几个对话做角色扮演，那还是把这件事想小了。真正改变效率的是背后那套思维方式，尤其是对于真正落在项目里时。

从一次性甩需求，变成分步骤推进。大多数人用AI的习惯是一次性把所有要求堆上去，结果前面理解偏了后面越跑越远。Harness的思路是反过来的，把大任务拆成几个步骤，每一步完成后检查一下再推进。每一步都有一个人为的检查点，这个习惯一旦建立，AI输出的可用率会有质的变化。其实就跟咱们在工作中做项目的思路是差不多的，我发现其实AI进化的路径就是不断模仿人实际的工作模式来的。

把踩过的坑变成规则沉淀下来。这可能是Harness对普通人最有价值的一件事。每次AI犯了一个让你不满意的错，就把它写成一条明确的规则存到文档里，下次对话贴进去。
如果你用Claude，最推荐的方式是用Projects功能来记录这些错误。打开claude.ai，点开Projects。

创建一个项目，

创建好后，在右边有一个" Instructions"的选项，点开后，把你攒的规则贴在这里，包括你项目中的PRD文档，设计规范之类的都可以丢到这里来作为它的约束和检查条件。

以后每次在这个项目里新开对话，Claude都会自动读取这些规则，不用你每次手动贴。你可以理解为这就是你给这个AI团队写的工作手册。

如果你想更进一步，可以把规则写成一个Skill文件。比如我自己有一个语音笔记整理的Skill，里面写好了所有格式要求和风格偏好，每次让Claude整理语音记录时它就自动按这套规则来。相当于你不只是写了工作手册，还训练出了一个专门干这件事的熟练工。

我自己现在就是每天用豆包输入法口述写日记，然后把文本复制发给claude，就能自动帮我优化好了，非常高效。

时间一长，这份文档就是你私人定制的Harness，AI的输出质量会越来越稳定。不这么做的话，你每次跟AI的协作都是从零开始，同样的错反复犯，效率永远上不去。

让AI自己验证自己的输出。比如写完一段文案之后追一句"现在用一个挑剔的读者视角重新审视你刚才写的内容，列出你觉得最弱的三个地方"。不追问的话，就是前面说的自我感觉良好的陷阱，AI写完就说写完了，半成品直接交付了，通常还要求我们仔细核对，容易搞错。

最后再说下

Harness不是越复杂越好。Anthropic发现他们早期设计的上下文重置机制，换了更强的模型后反而成了累赘。Harness必须跟模型能力匹配。

总结起来，核心就三句话：Prompt Engineering解决怎么把任务讲清楚，Context Engineering解决怎么把信息给对，Harness Engineering解决怎么让模型在真实执行中持续做对。

天花板高不高你我很难左右，但地板稳不稳，完全取决于你怎么搭这套系统。AI圈的概念会继续冒，但底层逻辑就一个，不能只盯着模型有多聪明，多想想怎么让它稳定地落地。

想动手试的话，不需要写代码，现在就能开始。

下一篇再写下，如何运用Harness思想创建一个Agent团队，让他们相互监督，共同产出，形成一人公司，保持关注吧。