正文整理稿

按视频原讲述顺序整理的正文稿。

《最近爆火的 Harness Engineering 到底是个啥？一期讲透！》

来源：YouTube [code秘密花园]
时长：00:18:30
视频ID：3DlXq9nsQOE
链接：https://www.youtube.com/watch?v=3DlXq9nsQOE
说明：以下文字按视频原讲述顺序整理，口语、重复和明显噪声已做轻度收束。

---

从提示词到运行系统的范式迁移

今天我们来聊一个最近在AI圈特别火，但很多人还没真正弄懂的词——Harness Engineering。如果你最近也在做Agent，或者关注AI应用的落地，或多或少都可能遇到这样的问题：为什么同样的模型，别人做出来的Agent可以连续跑很久，成功率很高，到了自己手里就总是差强人意？

很多人可能会想，是不是模型不够强？是不是提示词没调好？是不是上下文（context）没调明白？当然，这些都有影响。但越来越多的团队发现，真正决定我们的系统能不能稳定跑起来的，往往不是模型本身，而是模型外面那套运行的系统。这套东西，现在有了一个统一的名字，就叫Harness。

欢迎来到代码秘密花园，我是欢迎老师。为什么想聊这个话题呢？因为年初的时候，有个朋友找我帮他们调一个Agent。他们团队之前已经做了很多努力，换上了最好的极箭模型，提示词改了上百版，各种参数也调得不少，但真实成绩的效果依然不稳定。有的时候很聪明，有的时候莫名其妙就跑偏，任务的成功率不到70%。

后来我去看了一下，最后改动最大的地方，反而是模型和提示词之外的部分。我的改进点在于任务是怎么拆的，状态是怎么管的，关键步骤要怎么校验，失败之后要怎么恢复。结果新版本上线之后，还是同样的模型，同样的提示词，成功率直接拉到了95%以上。

当时那个朋友问我：“你到底改了什么呢？”说实话，那时候我没有一个特别准确的词来形容。直到最近，Harness and Niren这个概念越来越火，我才意识到，我当时改的这些东西，本质上就是Harness。

今天这期视频，我想彻底把这个概念跟大家讲清楚。我们主要分三个部分：Harness是怎么一步步演进出来的。一个成熟的Harness到底包括哪些部分。以及OpenAI、Anthropic、Lunchin这些公司，真实到底是怎么做的。

过去两年，AI工程其实经历了三次很明显的范式迁移：从Prompt Engineering，到Context Engineering，再到最近的Harness Engineering。表面上看，好像只是换了几个新的名词，但如果你只是把它理解成流行史，那就完全低估它们了。

这三个词分别对应了现在AI系统发展的三个阶段性问题：模型有没有听懂你在说什么？模型有没有拿到足够而且正确的信息？模型在真实的执行里，能不能持续地作对？你会发现，这些问题是一层一层往外扩张的。

在大模型刚活起来的时候，大家最直观的感受就是：同一个模型，你换一种说法，结果可能差很多。比如你说一句“帮我总结一下这篇文章”，他可能只会给你一个很平的总结。但如果你换一种说法，效果马上就会不一样。

那个阶段，大家都相信一件事：模型不是不会，而是你没有把问题说明白。于是大家开始疯狂研究提示词，什么角色设定、约束条件、输出格式、分步引导等等。

那为什么这些东西有效呢？因为大模型本质上是一个对上下文非常敏感的概率生成系统。你给它什么身份，它很容易沿着那个身份去回答。你给它什么样的样例，它很容易沿着那个范式去补全。你强调什么样的约束，它就很容易把那一部分当成重点。

Harness的六大核心构成

提示词工程的本质，不是秘密模型，而是塑造一个局部的概率空间。

那这个阶段最重要的能力，不是系统的设计，而是语言的设计。

但提示词工程很快就遇到了天花板。因为很多任务不是你说清楚就行，而是你真的得知道。比如你让模型分析一份公司的财报文档，回答一个产品的最新配置，按照一套非常长的规范去编写代码，在多个工具之间完成复杂的任务。

这个时候你会发现，提示词写得再漂亮，也替代不了事实本身。提示词擅长的是长期任务约束输出，激发模型的已有能力。但它不擅长填补缺失的支持，管理大量动态的信息，处理长链任务里的状态。

说白了，提示词解决的是表达的问题，而不是信息的问题。

于是第二阶段开始了。当大家还只是做聊天机器人的时候，提示词的作用很大，因为任务短、链路短、状态少，很多问题确实靠把话说明白就可以解决了。

但后来Agent开始火了。模型不只是要回答问题，而是要进入真实的环境里面做事。它要多轮对话、调浏览器、调工具、输入数据、生成报告，还要在多个步骤之间传递中间结果，根据Web反馈不断修正计划。

这个时候问题就变了。系统面对的已经不是一次回答对不对，而是整条链路的任务能不能跑通。

比如，如果你不是简单地说“帮我总结一下这篇文章”，而是让它做一个更真实的任务，比如说“帮我分析这份需求文档，找出潜在风险，结合历史评审意见，给出修改建议，再生成一版发给产品经理的返稿”，你会发现，这已经完全不是一句提示词就能解决的问题了。

它至少要拿到当前的需求文档、历史的评审记录，先回顾当前目标，分析出中间结论，输出的对象是谁，语气应该怎么调，等等等等。

所以Context Engineering的核心，就变成一句话：模型未必是知道的，系统必须在合适的时机把正确的信息送进去。

这里的context也不只是几段背景资料。在工程的意义上，它代表了所有影响模型当前决策的信息的总和，包括用户的输入、历史对话、检索结果、工具返回、当前任务的状态、中间产物、系统规则、安全约束，以及其他Agent传过来的结果。

你会看到，prompt其实只是context的一部分。也正因为如此，针对上下文的攻击机制是非常重要的。

说到context engineering，我觉得IG也算是一个比较典型的实践。IG的价值是很直接的：模型参数里没有指示，怎么在运行时补进去呢？做法大家都知道：先检索，再把相关的内容塞到上下文。

但真正成熟的context engineering，关注的肯定不只是检索。它关注的是整体完整的链路，比如文档怎么切块，结果怎么排序，上下文怎么压缩，历史对话什么时候要保留，什么时候要摘除，工具返回要不要全部暴露给模型，多个Agent之间到底传原文还是结果摘要。

包括最近很火的Agent Skills，我觉得本质上也是上下文工程的高级实践。因为它解决了一个特别现实的问题：如果你把十几个不同的工具、工具的说明、所有的参数定义，全部一上来就塞给模型，理论上模型会知道得更多，但实践往往会更糟糕。

因为上下文的窗口是非常稀缺的资源。信息一多，注意力就分散。所以Skill采用的是一个非常典型的思路，叫渐进式披露：不是一开始就把能力全部给模型看，而是只给它看最少量的原始信息，等它真正要触发某些能力的时候，再把那部分的SOP、详细的参考信息、脚本，动态地加进来。

这个思路非常重要，因为它告诉我们：上下文的优化，不只是给得更多，而是按需给、分层给、在正确的时间给。

但上下文工程其实也不只是终点。因为后来大家又发现了一个更麻烦的问题：就算信息给对了，模型也不一定能稳定地执行正确。它可能计划做得很好，但执行跑偏了，调错了工具，误解了返回结果，在一个很长的链路里慢慢偏行了，但系统却没有发现。

这个时候我们发现，提示词和上下文主要解决的都是输入端的问题：提示词优化意图的表达，上下文优化的是信息的供给。但在复杂的任务里，还有一个更难的问题：当模型开始连续行动的时候，谁来监督它、约束它、纠偏它呢？

这个时候，第三阶段来了。

Harness这个词，原本的意思是缰绳、马具、约束装置。放到AI系统里，就是在提醒我们一件非常普遍的事情：当模型从回答问题走向执行任务，系统不仅要有能力驾驭它，还要能够驾驭整个过程。

这就是Harness and Niren的出发点。如果说前两代工程关注的是“怎么让模型更会想”，那Harness更关注的就是“怎么让模型别跑偏、跑得稳，出了错还能拉回来”。

这里我用一个比较通俗的例子来解释这三个概念。假设你要派一个新人去完成一次很重要的客户拜访工作。

Prompt Engineering就是你要告诉他：先把任务讲清楚，比如见面先自我介绍，再介绍方案，再问需求，最后推动下一步。这其实就是prompt，重点是把话说明白。

Context Engineering是啥？你要告诉他：把资料准备齐全，比如客户的背景、过往的沟通记录、产品的报价、竞品的情况，这次会议的目标。这些都是context的重点，是把信息给对。

但如果这个会议真的很重要，你还会继续做很多事情：让他带着checklist去，让他在关键节点做汇报，会后何时整理录音，如果发现偏差马上纠正，最后按照明确的标准去验收结果。这些就是Harness。

重点已经不是说清楚和资料齐不齐全，而是有没有一套持续观测、持续纠偏、最终验收结果的机制。

这三者也不是替代关系，而是包含关系：prompt是对指令的工程化，context是对输入环境的工程化，Harness就是对整个运行系统的工程化。它们的边界是一层比一层大的。

Lunchin的工程师给Harness下了一个很典型的定义：agent等于model加harness。Harness就等于agent minus model。

翻译成人话就是：在一个Agent的系统里面，除了模型本身以外，几乎所有能决定它能不能稳定交付的东西，都可以算作Harness。

那如果拆开来看呢？我自己会把一个成熟的Harness Engineering分成六层。

一线公司的实战洞察

第一层，是我们重新站在Harness的视角去看Context。模型能不能稳定发挥，很多时候不仅取决于它聪不聪明，而取决于它看到了什么。所以Harness的第一职责，就是让模型能够在正确的信息边界内思考。

这一层通常包括三件事情：首先，角色的目标和定义——模型要知道自己是谁，任务是什么，成功标准是什么。其次，信息的检索和选择——上下文不是越多越好，而是越相关越好。第三，结构化的组织——固定的规则放在哪儿，待办任务放在哪儿，任务运行的状态放在哪儿，外部的证据又放在哪儿？最好分层清楚。因为信息一旦乱掉，模型就很容易漏重点、忘约束，甚至自我污染。

第二层，工具系统。没有工具，大模型本质上还是一个文本处理器，会解释、会总结，但它接触不到真实世界。一旦连上工具，模型才可以真正做事，比如查网页、读文档、写代码、调API等等。

但Harness在这里做的，不只是简单地把工具挂上去，而是要解决三个问题：第一，给它什么工具？工具太少，能力不够。工具太多，模型又会乱用。第二，什么时候该调用工具？本来不需要查的时候别乱查，该查证的时候也别硬答。第三，工具结果怎么重新呈现给模型？几十条返回结果，不应该原封不动地塞回去，而要提炼、筛选，保持与任务的相关性。

第三层，执行编排。这一层解决的核心问题是：模型下一步该做什么？

很多AZ的问题，不是某一步不会，而是不会把所有步骤串起来。它会搜索，也会总结，也会写代码，但整个过程想到哪做到哪，最后交付一堆半成品。

一个完整的任务，通常需要有这样的轨道：首先理解目标，然后判断信息够不够，不够就继续补充。接着生成结果，继续分析。输出，检查输出。如果不满足要求，就重新修正或重试。

这个时候你会发现，这已经非常接近人在工作了。区别在于，人靠经验，Agent靠Harness这套环境。

第四层，记忆和状态。没有状态的Agent，每一轮都会像失忆一样，不知道自己刚做了什么，也不知道哪些结论已经确认了，哪些问题还没解决。

所以Harness还必须管理状态。这里我们要至少让它分清三类东西：当前任务的状态、中间结果、长期的记忆和用户偏好。这三类如果混在一起，系统会越来越乱。看清楚之后，Agent才会像一个稳定的协作者。

第五层，评估和观测。这一层往往是很多团队最容易忽视的部分。很多系统其实不是生成不出来，而是生成完了之后，根本不知道自己做得好不好。

如果没有独立的评估和观测能力，Agent就会长期停留在自我感觉良好的状态。这一层通常包括输出和验收、环境的验证、自动测试、日志和指标、错误的归因等等。

也就是说，系统不仅是要运作，还要知道自己有没有真的作对。

第六层，约束、校验、失败和恢复。最后一层往往才是真正决定这个系统能不能上线的关键环节。因为在真实环境里，失败不是例外，而是常态。可能搜索不准，可能API超时，也可能文档混乱，或者模型误解了任务。

如果没有恢复机制，Agent每次出错就只能从头再来。一个成熟的Harness，一定要包括三件事：约束哪些能做，哪些不能做。校验，比如输出之前、输出之后要怎么检查。恢复，失败之后怎么回滚，切换到稳定状态。

接下来，我们来看最有参考价值的部分：一线公司的真实实践。因为Harness这个词最近之所以突然火起来，不是大家在空谈方法论，而是很多公司都已经把它做进了产品和工程体系里。

比如，Lunchin在底层模型完全不变的情况下，只通过改造和部署Harness，就把它自家的智能体业务，从一个排名30开外的水平，直接杀到了前五。

OpenAI依靠一个只有几名人类工程师的团队，用Agent从零构建了一个超百万行代码的生产级应用，100%的代码都是由Agent编写的，耗时只有纯人工开发的十分之一。

Anthropic也构建了一个可以完全自主编码的系统，仅凭一句自然语言的需求，就能在无需人类干预的情况下，连续运行几个小时，最后做出完整的游戏、完整的数字音频工作站。

我们先看看Anthropic的实践。首先，他们在长期自主任务上总结了两个特别典型的问题。

第一个问题，我自己把它翻译成“上下文膨胀”。时间一长，上下文越来越满，模型就开始丢细节、丢重点，甚至会出现一种很有意思的现象：它好像知道自己快装不下了，于是开始着急地收尾。

很多系统面对这种问题，都会做context compression，也就是把前面的历史上下文压缩一下再继续跑。但Anthropic发现，对一些模型来说，这还是不够。因为压缩只是变短了，不代表那种负担感真的消失了。

他们做了一件更积极的事：叫context reflect。不是在原上下文里继续压缩，而是换了一个非常干净的新Agent，把工作交接给它。这个思路很像什么呢？特别像工程里遇到内存泄漏之后，不是继续缓存，而是直接重启整个进程，恢复状态。

这其实就是一种非常典型的Harness设计。

Anthropic解决的第二个问题，是自评偏差。首先让模型自己干活，再让它自己给自己打分，往往结果会偏乐观，尤其是在设计、体验、产品完整度这类没有标准答案的问题上，偏差更明显。

他们采用了一个非常关键的思路：把干活的人和验收的人分开。他们是这样分工的：Planner负责把模糊的需求转化为完整的规格，Executor负责逐步实现，Evaluator负责像QA一样去真实测试。

更关键的是，这个Evaluator不只是看代码，而是会真实操作页面，检查具体的交互，验证实际结果。也就是说，这不是一个抽象的审查，而是一个带具体环境的验证。

Harness的本质与未来意义

这件事非常重要，因为它背后是一个明确的工程原则：生产验收必须分离。只要评估者足够独立，系统就能形成一个真正有效的循环——生成、检查、修复、再检查。

再看OpenAI在这方面的感觉，是他们重新定义了工程师在Agent时代的工作。他们有一个非常有意思的思路：人类在这个环境里不需要写一行代码。

人类只需要负责设计环境。具体来说，工程师的工作变成三件事：第一，把产品目标拆解成Agent能力阶的小任务。第二，Agent失败的时候，不是让它更努力一点，而是问：环境里缺了什么能力？第三，建立反馈链路，让Agent真正能够看到自己的工作结果。

这句话我是非常认同的。当Agent出了问题，修复方案几乎从来不是要它更努力一点，而是确定它缺了什么样的结构性能力。这其实也是典型的Harness思维。

我们还有一个特别典型的事件，也是见于“渐进式披露”。他们早期犯过一个很多团队都会犯的错误：写了一个巨大的Agent 4.md，把所有的规范、框架、约定全部塞进去了。结果Agent更糊涂了，因为上下文窗口是稀缺资源，塞得太满，其实等于什么都没说。

后来他们怎么改的？把Agent 4.md变成一个目录页，页面只保留核心索引，更详细的内容则拆到架构文档、设计文档、执行计划、执行评分、安全规则等具体文档里去了。Agent先看目录，需要的时候再钻进去。

这个时候我们会发现，这和我们前面说的Skills，本质上是一个道理：不是一次性全给，而是按需暴露。

还有一点实践是：OpenAI不只是让Agent写代码，还让Agent看见整个应用。因为产业速度一旦上来，静态的“写”其实就不再是重点，而是“验”了。

人类根本是验不过来的。他们让Agent自己去验。首先，接浏览器，能截图、点页面。能模拟用户的真实操作。接入日志系统和指标系统，让Agent能查LOG、查监控。

最后，每个任务都在独立隔离的环境中运行，互不影响。结果就是，Agent不再是“写完代码就说写完了”，而是真正可以跑起来看结果，发现Bug、修Bug、再验证。

这其实就是Harness里非常完整的一套：工具系统、执行编排、评估和观测、约束和恢复。

还有一点需要注意的是，OpenAI不只会靠人类在最后的Code Review环节去兜底质量。因为Agent的提交速度太快，人类是盯不过来的。他们把很多资深工程师的经验，直接写成了系统规则。

比如模块怎么分层，哪一层不能依赖哪一层，什么情况下必须拦截，发现问题之后应该怎么修。重点是，这些规则不只是负责报错，而是会把“怎么修”也一起返回给Agent，进入下一轮的迭代。

你会发现，这已经不是传统意义上的代码规范了，而是一套可持续运行的自动智力系统。这也是Harness的典型形态。

最后我们总结一下：Prompt Engineering解决的是怎么把任务讲清楚。Context Engineering解决的是怎么把信息都给对。Harness Engineering解决的是怎么让模型在真实执行中持续作对。

所以Harness不是在取代Prompt，也不是在取代Context，它是在更大的系统边界上，把前两者都包含进来。

当任务还是简单的单轮生成时，Prompt很重要。当任务开始依赖Web支持去运行信息时，Context就很关键了。当模型真的进入了长链路、可执行、低容错的真实场景，Harness几乎就是不可避免的。

这就是为什么同样的模型，在不同的产品里表现差距会这么大。因为真正决定上线的可能是模型，但真正决定能不能落地、能不能稳定交付的，是Harness。

到了这个阶段，我们也看清了一个现实：AI落地的核心挑战，正在从“让模型看起来更聪明”，转向“让模型在真实世界里稳定工作”。

如果你最近也在做Agent，我觉得这件事情非常值得你趁早想明白。

本期教程的内容就是这么多。如果本期对你有所帮助，希望得到一个免费的三连和关注。感谢大家，我们下期见。

---

本文由 AI 基于转写整理，仅供复查参考。