地址在：https://www.bilibili.com/video/BV1Zk9FBwELs/?spm_id_from=333.337.search-card.all.click
附上总结文稿：

夸克总结的文稿：
 

今天我们来聊一个最近在AI圈特别火，但很多人还没真正弄懂的词，harness engineering. 如果你最近也在做agent或者关注AI应用的落地，或多或少可能都会遇到这样的问题。为什么同样的模型别人做出来的agent可以连续跑很久，成功率很高，到了自己手里就总是差强人意呢？很多人可能会想，是不是模型不够强，是不是体质词没调好，是不是IG没调明白？当然这些都有影响。但是越来越多的团队最后发现，真正决定我们的系统能不能稳定的跑起来，往往不是模型本身，而是模型外面那套运行的系统。这套东西现在有了一个统一的名字就叫harness。

大家好，欢迎来到柯南秘密花园，我是花园老师。为什么想聊这个话题呢？因为年初的时候，有个朋友找我帮他们调一个agent。他们团队之前已经做了很多努，换上了最好的旗舰模型，提示词改了上百版，各种参数也调了不少。但是已经真实的场景效果还是不稳定，有的时候很聪明，有的时候又莫名的跑偏，任务的成功率不到70%。

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

当时这个朋友问我，你到底改了什么呢？说实话，那个时候我没有一个特别准确的词来形容。直到最近harness engineering这个概念越来越火，我才意识到我当时改的这些东西本质上就是harness。所以今天这期视频，我想彻底把这个概念跟大家讲清楚，我们主要分三个部分，harness是怎么一步步演进出来的？一个成熟的harness到底包括哪些部分？OpenAI astrop c这些公司真实到底是怎么做的？

过去两年AI工程其实经历了三次很明显的重心迁移。从prompt engineering、context engineering再到最近的harness engineering。表面上看好像只是换了几个新的名词，但如果你只是把它理解成术语流行史，那就完全低估他们了。这三个词分别对应了现在AI系统发展的三个阶段性问题。模型有没有听懂你在说什么？模型有没有拿到足够而且正确的信息？模型在真实的执行力能不能持续的做对。你会发现这些问题是一层一层往外扩张的。

在大模型刚火起来的时候，大家最直观的感受就是同一个模型你换一种说法，结果可能差很多。比如你说一句帮我总结一下这篇文章，他可能只会给你一个很平的总结。但如果你换一种说法，效果马上就会不一样。所以那个阶段大家都相信一件事情，模型不是不会，而是你没有把问题说明白。于是大家开始疯狂的研究提示词，什么角色设定、风格约束、feel show的示例分布引导输出格式等等等等。

那为什么这些东西有效呢？因为大模型本质上是一个对上下文非常敏感的概率生成系统。你给他什么身份，他很容易沿着那个身份去回答。你给他什么样的样例，它很容易沿着那个范式去补全。你强调什么样的约束，他就很容易把那一部分当成重点。所以提示词工程的本质不是命令模型，而是塑造一个局部的概率空间。这个阶段的最重要的能力不是系统的设计，而是语言的设计。

但提示词工程很快就遇到了天花板。因为很多任务不是你说清楚就行，而是你真的得知道。比如你让模型分析一份公司的内部文档，回答一个产品的最新配置，按照一套非常长的规范去写代码，在多个工具之间完成复杂的任务。这个时候你会发现提示词写的再漂亮也替代不了事实本身。所以提示词擅长的是长期任务约束输出激发模型的已有能力。但是他不擅长凭空弥补缺失的知识管理，大量动态的信息处理长链路任务里的状态。说白了其提示词解决的是表达的问题，不是信息的问题。于是第二阶段开始了当大家还只是做聊天机器人的时候，提示词的作用很大。因为任务短、链路短、状态少，很多问题确实靠把话说明白就可以解决了。

但后来agent开始火了，模型不只是要回答问题，而是要进到真实的环境里面做事情，还要多轮对话，调浏览器、写代码、数据库这些工具还要在多个步骤之间传递中间结果，还要根据外部的反馈不断修订计划。那这个时候问题就变了，系统面对的已经不是一次回答，对不对？而是整条链路的任务能不能跑通。比如如果你不是简单的问一句，帮我总结一下这篇文章，而是让他做一个更真实的任务，比如说帮我分析这份需求文档，找出潜在风险，结合历史的评审意见给出改进建议，再生成一版发给产品经理的反馈稿。你会发现这已经完全不是一句提示词就能解决的问题了。他至少要拿到当前的需求文档，历史的评审记录、相关规范，当前目标已经分析出来，中间结论输出的对象是谁，语气应该怎么调等等等等。所以context engineering的核心就变成一句话，模型未必是知道的，系统必须在合适的时机把正确的信息送进去。

这里的context也不只是几段背景的资料，在工程的意义上它代表了所有影响模型当前决策的信息的总和。包括用户的输入历史对话、检索结果、工具返回到当前任务的状态，中间产物系统规则、安全约束或者其他agent的传过来的结构化的结果。所以你会看到prompt其实只是context的一部分。也正因为如此，这套上下文的供给机制是非常重要的那说到context engineering，我觉得IG也算是一个比较典型的实践。IG的价值是很直接的，模型参数里面没有知识，怎么在运行时补进去呢？做法大家都知道，先检索再把相关的内容塞到上下文。但是真正成熟的context engineering关注的肯定不只是检索，它关注的是整条完整的链路。比如文档怎么切块，结果怎么排序，长文怎么压缩，历史对话什么时候要保留，什么时候要摘要，工具返回要不要全部暴露给模型？多个agent的之间到底传原文摘要还是结构化字段呢？

包括最近很火的agent skills，我觉得本质上也是上下文工程的高级实践。因为它解决了一个特别现实的问题。如果你把十几个不同的工具，工具的说明，所有的参数定义全部一上来就三个模型。理论上模型会知道的更多，但是实践往往会更糟糕，为什么呢？因为上下文的端口是非常稀缺的资源，信息一多注意力就会涣散。所以skill采用的是一个非常典型的思路，叫渐进式披露。不是一开始就把能力全部给模型看，而是只给他看最少量的原信息。等他真正的要触发某些能力的时候，再把那部分的SOP详细的参考信息脚本动态的加进来。这个思路其实非常重要。因为他告诉我们上下文的优化不只是给的更多，而是按需给、分层给，在正确的时机给。

但是上下文工程其实也不只是终点。因为后来大家又发现了一个更麻烦的问题，就算信息给对了，模型也不一定能稳定的执行的正确。他可能计划做的很好，但是执行跑偏了。第二个工具，但理解错了返回结果在一个很长的链路里已经慢慢偏航了，但是系统却没有发现。这个时候我们发现提示词和上下文其实主要的解决都在输入侧的问题。提示词优化意图的表达，上下文优化的是信息的供给。但是复杂的任务里还有一个更难的问题，当模型开始连续行动的时候，谁来监督它、约束它和纠偏它呢？

这个时候第三阶段来了。Alice这个词原本的意思是将绳码距约束装置的意思放到AI系统里面。其实就是在提醒我们一件非常朴素的事情。当模型从回答问题走向执行任务，系统不只要能够负责微信息，还要能够驾驭整个过程，这个就是harness engineering的出发点。如果前两代工程关注的是怎么让模型更会响，那harness更关注的就是怎么让模型别跑偏、跑得稳，出了错还能拉回来。

这里我用一个比较通俗的例子来解释这三个概念。假设你要派一个新人去完成一次很重要的客户拜访的工作。Prompt engineering就是你要告诉他先把任务讲清楚。比如见面先寒暄，再介绍方案，再问需求，最后确认下一步。这个就是prompt重点是把话说明白。那context engineering是啥呢？

你要告诉他把资料要准备齐全，比如说这个客户的背景，过往的沟通记录，产品的报价，竞品的情况，这次会议的目标，这些都是context，重点是信息要给对。如果这个会真的很重要，你还会继续做很多事情，比如说让他带着chat list去让他在关键的节点实时汇报会后核实纪要和录音，如果发现偏差马上纠正，最后按照明确的标准去验收结果。这些就是harness重点，已经不是说清楚和资料齐不齐了，而是有没有一套持续观测、持续纠偏，最终验收结果的机制。所以这三者也不是替代的关系，而是包含的关系。

Prompt是对指令的工程化，context是对输入环境的工程化，harness就是对整个运行系统的工程化，它们的边界是一层比一层大的。LangChain的工程师给harness下了一个很典型的定义，agent等于model加harness，那harness就等于agent减model。翻译成人话就是在一个agent系统里面，除了模型本身以外，几乎所有能决定它能不能稳定交付的东西都可以算进harness。如果拆开来看，我自己会把一个成熟的。

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

第一层通常包括三件事情。首先角色的目标和定义，模型要知道自己是谁，任务是什么，成功的标准是什么。第二，信息的裁剪和选择，上下文不是越多越好，而是越相关越好。

第三结构化的组织，固定的规则放在哪儿？当前的任务放在哪儿？任务运行的状态放在哪儿？外部的证据又放在哪儿？最好分层清楚。因为信息一旦乱掉，模型就很容易漏重点、忘约甚至自我污染。

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

但是harness在这里做的不是简单的把工具挂上去，而是也要解决三个问题。第一，给他什么工具，工具太能力不够，工具太多模型又会乱用。第二，什么时候该调用工具，本来不需要查的时候别乱查，该查证的时候也别硬答。第三，工具结果怎么重新喂回模型，搜索回来的几十条结果不应该原封不动的塞回去，而是要提炼筛选，保持和任务的相关性。第三层执行编排。

这一层解决的核心问题就是模型下一步该做什么。很多A的问题不是某一步不会，而是不会把所有的步骤给串起来。它会搜索，也会总结，也会写代码，但整个过程想到哪做到哪儿，最后交付出来一堆半成品。所以一个完整的任务通常需要有这样的轨道。首先理解目标，然后判断信息够不够，不够继续补，基于结果继续分析，然后生成输出，检查输出不满足要求就重新修正或者重试。这个时候你会发现这已经非常接近人在工作了。区别在于人靠经验，agent靠harness这套环境。

第四层，记忆和状态。没有状态的agent每一轮都会像失忆一样，他不知道自己刚做了啥，也不知道哪些结论已经确认了，哪些问题还没解决。所以harness还必须要管理状态。

这里我们要至少让他分清三类东西。首先当前任务的状态，绘画中的中间结果，长期的记忆和用户偏好。这三类如果混在一起，系统会越来越乱。看清楚之后，agent才会像一个稳定的协作者。

第五层，评估和观测，这个就是很多团队最容易忽视的一很多系统其实不是生成不出来，而是生成完了之后根本不知道自己做的好不好。如果没有独立的评估和观测的能力，agent就会长期停留在自我感觉良好的状态。这一层通常包括输出和验收环境的验证，自动的测试日志和指标错误的归因等等。也就是说系统不仅是要会做，还要知道自己有没有真的能够做对。

第六层，约束校验失败和恢复。最后一层往往才是真正决定这个系统能不能上线的关键环节。因为在真实的环境里面，失败不是例外，而是常态。可能搜索不准，可能是API超时，也可能文档格式混乱，或者模型误解了任务。如果没有恢复的机制，agent每次出错就只能从头再来。所以一个成熟的harness一定要包括三件事情，约束，哪些能做哪些不能做。校验，比如输出之前，输出之后要怎么检查？恢复失败之后，咱们重视切入镜回滚到稳定的状态。

说完概念，我们来看最有参考价值的部分，一线公司的真实实践。因为harness这个词最近之所以突然火起来，不是大家在空谈这个方法论，而是很多公司都已经把它做进了产品和工程体系里面了。比如lang ten在底层模型完全不变的情况下，只通过改造和迭代harness就把他自家的智能体验从一个榜单上的排名直接从30开外杀到了前五。OpenAI依靠一个只有几名人类工程师的团队，用agent从零构建了一个超百万行代码的生产级应用。百分之百的代码都是由agent编写的，耗时只有纯人工开发的10分之1。Anthropic也构建了一个可以完全自主编码的系统，只凭一句自然语言的需求就能在无需人类干预的情况下连续运行几个小时，最后做出完整的游戏，完整的数字音频工作站。

我们先看看anthropic的实践，首先他们在长城自主的任务上总结了两个特别典型的问题。第一个问题，我自己把它翻译成上下文焦虑。时间一长上下文越来越满，模型就是模型，就开始丢细节，丢重点。甚至还会出现一种很有意思的现象，他好像知道自己快装不下了，于是开始着急的去收尾。

很多系统面对这种问题都会做context complication，也就是把前面的历史上下文压缩一下再继续跑。但anthropic发现对于一些模型来说，这还是不够的。因为压缩只是变短了不代表那种负担感真的消失了。所以他们做了一件更激进的事情叫context reject。不是在原上下文里面继续压，而是换了一个非常干净的新的agent把工作交接给他。这个思路很像什么呢？特别像工程里面遇到内存泄露之后，不是继续清缓存，而是直接重启整个进程再恢复状态。这个其实就是一种非常典型的harness设计。

Anthropic解决的第二个问题就是自评失真的问题。首先模型自己干活，再让他自己给自己打分，往往会是会乐观的那尤其是在设计体验产品完整度这一类没有标准答案的问题上，偏差是更明显的。所以他们采用了一个非常关键的思路，把干活的人和验收的人分开。他们是这样拆分的，planner负责把模糊的需求扩展成完整的规格，generator负责逐步的去实现。Evaluator负责像QA一样去真实的测试。更关键的是这个evaluator它不只是会看代码，而是会真实的操作页面，看具体的交互，检查实际的结果。也就是说这不是一个抽象审查，它是一个带具体环境的验证。这个事情非常重要，因为它背后是一个很明确的工程原则，生产验收必须分离。只要评估者足够独立，系统就能形成一个真正的有效循环，生成检查、修复再检查的这样的一个循环。

OPAI在这方面给我的感觉是他们重新定义了工程师在agent时代的工作。他们做了一个非常有意思的思路，人类在这个环境里面不需要写一行的代码，人类只需要去负责设计环境。具体来说说，工程师的工作变成了三件事情。首先把产品目标拆解成agent能理解的小任务。Agent失败的时候，不是让他更努力一点，而是问环境里面缺了什么能力。最后建立反馈的链路，让agent真正的能够看到自己的工作结果。这句话我是非常认同的当agent出了问题的时候，修复方案几乎从来不是要更努力一点，而是确定它缺了什么样的结构性的能力。这个其实也是典型的harness思维。

OMA还有一个特别典型的实践，也是渐进式披露。他们早期犯过一个很多团队都会犯的错误，写了一个巨大的agent DRND，把所有的规范框架约定全部塞进去了，结果agent更糊涂了，因为上下文窗口是一个稀缺的资源，塞的太满其实等于什么都没说。那后来他们怎么改的呢？把agent点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是很重要的那当任务开始依赖外部知识去运行信息的时候，context就很关键了当模型真的进入了长链路可执行、低容错的真实场景里面，harness几乎就是不可避免的这也是为什么同样的模型在不同的产品里面表现差距。会这么大了。因为真正决定上限的可能是模型，但是真正决定能不能落地，能不能稳定交付的就是harness。到了这个阶段，我们也看清了一个现实，AI落地的核心挑战正在从让模型看起来更聪明转向让模型在真实世界里稳定的工作。如果你最近也在做agent，我觉得这件事情非常值得你趁早想明白。好啊，本期教程的内容就是这么多。如果本期教程对你有所帮助，希望得到一个免费的三连和关注，感谢大家，我们下期见。

（内容由AI生成）