{
  "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见",
  "segments": [
    {
      "start": 0.0,
      "end": 2.48,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 2.48,
      "end": 4.4,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 4.4,
      "end": 5.56,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 5.56,
      "end": 7.2,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 7.2,
      "end": 9.08,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 9.08,
      "end": 10.88,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 10.88,
      "end": 11.84,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 11.84,
      "end": 13.0,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 13.0,
      "end": 14.24,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 14.24,
      "end": 15.2,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 15.2,
      "end": 17.44,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 17.44,
      "end": 19.36,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 19.36,
      "end": 20.48,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 20.48,
      "end": 21.8,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 21.8,
      "end": 23.44,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 23.44,
      "end": 26.12,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 26.12,
      "end": 28.92,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 28.92,
      "end": 30.72,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 30.72,
      "end": 33.08,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 33.08,
      "end": 34.04,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 34.04,
      "end": 35.96,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 35.96,
      "end": 36.96,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 36.96,
      "end": 37.4,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 37.4,
      "end": 38.64,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 38.64,
      "end": 39.48,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 39.48,
      "end": 40.88,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 40.88,
      "end": 42.0,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 42.0,
      "end": 43.68,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 43.68,
      "end": 45.48,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 45.48,
      "end": 47.4,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 47.4,
      "end": 48.8,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 48.8,
      "end": 50.2,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 50.2,
      "end": 51.76,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 51.76,
      "end": 53.0,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 53.0,
      "end": 54.04,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 54.04,
      "end": 55.48,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 55.48,
      "end": 57.2,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 57.2,
      "end": 57.84,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 57.84,
      "end": 59.28,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 59.28,
      "end": 60.72,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 60.72,
      "end": 61.68,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 61.68,
      "end": 62.72,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 62.72,
      "end": 63.52,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 63.52,
      "end": 65.0,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 65.0,
      "end": 66.32,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 66.32,
      "end": 67.76,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 67.76,
      "end": 69.32,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 69.32,
      "end": 70.76,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 70.76,
      "end": 71.8,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 71.8,
      "end": 72.8,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 72.8,
      "end": 74.8,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 74.8,
      "end": 75.96,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 75.96,
      "end": 77.44,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 77.44,
      "end": 77.96,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 77.96,
      "end": 78.64,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 78.64,
      "end": 81.2,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 81.2,
      "end": 81.84,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 81.84,
      "end": 84.28,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 84.28,
      "end": 85.04,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 85.04,
      "end": 86.44,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 86.44,
      "end": 88.36,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 88.36,
      "end": 89.52,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 89.52,
      "end": 92.36,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 92.36,
      "end": 93.56,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 93.56,
      "end": 95.64,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 95.64,
      "end": 96.76,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 96.76,
      "end": 98.28,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 98.28,
      "end": 98.84,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 98.84,
      "end": 100.04,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 100.04,
      "end": 101.48,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 101.48,
      "end": 102.32,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 102.32,
      "end": 105.64,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 105.64,
      "end": 107.12,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 107.12,
      "end": 108.4,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 108.4,
      "end": 110.32,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 110.32,
      "end": 110.96,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 110.96,
      "end": 112.76,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 112.76,
      "end": 114.32,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 114.32,
      "end": 116.64,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 116.64,
      "end": 121.24,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 121.24,
      "end": 123.48,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 123.48,
      "end": 126.48,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 126.48,
      "end": 129.32,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 129.32,
      "end": 134.78,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 134.78,
      "end": 136.78,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 136.78,
      "end": 139.22,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 139.22,
      "end": 140.1,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 140.1,
      "end": 141.3,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 141.3,
      "end": 143.74,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 143.74,
      "end": 145.86,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 145.86,
      "end": 147.1,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 147.1,
      "end": 148.46,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 148.46,
      "end": 149.26,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 149.26,
      "end": 150.86,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 150.86,
      "end": 151.98,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 151.98,
      "end": 154.1,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 154.1,
      "end": 156.82,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 156.82,
      "end": 157.78,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 157.78,
      "end": 158.54,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 158.54,
      "end": 159.46,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 159.46,
      "end": 160.18,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 160.18,
      "end": 161.5,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 161.5,
      "end": 163.1,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 163.1,
      "end": 165.74,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 165.74,
      "end": 168.1,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 168.1,
      "end": 168.9,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 168.9,
      "end": 171.14,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 171.14,
      "end": 172.3,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 172.3,
      "end": 174.42,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 174.42,
      "end": 175.66,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 175.66,
      "end": 177.9,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 177.9,
      "end": 180.98,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 180.98,
      "end": 183.66,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 183.66,
      "end": 185.18,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 185.18,
      "end": 186.14,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 186.14,
      "end": 187.7,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 187.7,
      "end": 190.38,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 190.38,
      "end": 192.66,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 192.66,
      "end": 194.18,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 194.18,
      "end": 196.78,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 196.78,
      "end": 198.54,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 198.54,
      "end": 200.54,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 200.54,
      "end": 202.9,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 202.9,
      "end": 204.14,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 204.14,
      "end": 205.5,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 205.5,
      "end": 207.54,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 207.54,
      "end": 209.34,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 209.34,
      "end": 210.94,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 210.94,
      "end": 212.78,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 212.78,
      "end": 213.98,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 213.98,
      "end": 215.62,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 215.62,
      "end": 217.06,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 217.06,
      "end": 218.9,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 218.9,
      "end": 219.7,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 219.7,
      "end": 221.62,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 221.62,
      "end": 222.9,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 222.9,
      "end": 224.5,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 226.48,
      "end": 228.88,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 228.88,
      "end": 229.96,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 229.96,
      "end": 231.6,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 231.6,
      "end": 234.64,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 234.64,
      "end": 236.36,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 236.36,
      "end": 238.0,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 238.0,
      "end": 240.24,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 240.24,
      "end": 242.36,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 242.36,
      "end": 243.56,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 243.56,
      "end": 245.72,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 245.72,
      "end": 247.68,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 247.68,
      "end": 249.08,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 249.08,
      "end": 251.4,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 251.4,
      "end": 253.68,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 253.68,
      "end": 255.28,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 255.28,
      "end": 256.76,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 256.76,
      "end": 258.76,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 258.76,
      "end": 259.68,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 259.68,
      "end": 261.72,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 261.72,
      "end": 262.92,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 262.92,
      "end": 263.84,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 263.84,
      "end": 264.64,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 264.64,
      "end": 266.04,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 266.04,
      "end": 266.6,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 266.6,
      "end": 269.28,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 269.28,
      "end": 271.2,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 271.2,
      "end": 272.04,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 272.04,
      "end": 273.4,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 273.4,
      "end": 275.0,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 275.0,
      "end": 276.0,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 276.0,
      "end": 276.96,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 276.96,
      "end": 277.8,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 277.8,
      "end": 278.44,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 278.44,
      "end": 280.96,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 280.96,
      "end": 282.44,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 282.44,
      "end": 285.84,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 285.84,
      "end": 289.04,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 289.04,
      "end": 290.12,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 290.12,
      "end": 294.44,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 294.44,
      "end": 295.4,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 295.4,
      "end": 295.92,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 295.92,
      "end": 296.84,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 296.84,
      "end": 297.52,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 297.52,
      "end": 298.56,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 298.56,
      "end": 299.32,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 299.32,
      "end": 299.96,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 300.0,
      "end": 303.28,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 303.28,
      "end": 304.24,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 304.24,
      "end": 306.56,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 306.56,
      "end": 307.68,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 307.68,
      "end": 310.76,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 310.76,
      "end": 312.52,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 312.52,
      "end": 315.64,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 315.64,
      "end": 317.4,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 317.4,
      "end": 318.92,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 318.92,
      "end": 320.84,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 320.84,
      "end": 321.84,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 321.84,
      "end": 324.4,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 324.4,
      "end": 326.76,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 326.76,
      "end": 328.48,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 328.48,
      "end": 330.52,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 330.52,
      "end": 331.8,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 331.8,
      "end": 332.92,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 332.92,
      "end": 334.0,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 334.0,
      "end": 335.44,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 335.44,
      "end": 336.68,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 336.68,
      "end": 338.6,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 338.6,
      "end": 339.56,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 339.56,
      "end": 342.12,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 342.12,
      "end": 344.28,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 344.28,
      "end": 347.12,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 347.12,
      "end": 349.36,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 349.36,
      "end": 351.24,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 351.24,
      "end": 353.04,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 353.04,
      "end": 354.88,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 354.88,
      "end": 356.64,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 356.64,
      "end": 358.44,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 358.44,
      "end": 359.14,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 359.14,
      "end": 361.84000000000003,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 361.84000000000003,
      "end": 362.54,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 362.54,
      "end": 363.54,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 363.54,
      "end": 366.34000000000003,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 366.34000000000003,
      "end": 367.44,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 367.44,
      "end": 369.94,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 369.94,
      "end": 371.94,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 371.94,
      "end": 374.04,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 374.04,
      "end": 375.74,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 375.74,
      "end": 376.58,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 376.58,
      "end": 377.84000000000003,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 377.84000000000003,
      "end": 378.64,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 378.64,
      "end": 379.54,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 379.54,
      "end": 380.54,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 380.54,
      "end": 382.94,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 382.94,
      "end": 384.64,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 384.64,
      "end": 386.24,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 386.24,
      "end": 389.32,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 389.32,
      "end": 392.08,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 392.08,
      "end": 393.32,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 393.32,
      "end": 396.08,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 396.08,
      "end": 397.6,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 397.6,
      "end": 398.92,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 398.92,
      "end": 399.76,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 399.76,
      "end": 401.04,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 401.04,
      "end": 402.92,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 402.92,
      "end": 404.48,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 404.48,
      "end": 405.76,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 405.76,
      "end": 408.0,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 408.0,
      "end": 409.48,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 409.48,
      "end": 410.8,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 410.8,
      "end": 412.64,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 412.64,
      "end": 414.0,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 414.0,
      "end": 415.48,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 415.48,
      "end": 417.48,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 417.48,
      "end": 420.48,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 420.48,
      "end": 422.48,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 422.48,
      "end": 426.01,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 426.01,
      "end": 427.01,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 427.01,
      "end": 429.01,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 429.01,
      "end": 430.01,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 430.01,
      "end": 432.01,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 432.01,
      "end": 435.01,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 435.01,
      "end": 437.01,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 437.01,
      "end": 439.01,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 439.01,
      "end": 441.01,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 441.01,
      "end": 443.01,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 443.01,
      "end": 445.01,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 445.01,
      "end": 447.01,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 447.01,
      "end": 450.61,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 450.61,
      "end": 454.21000000000004,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 454.21000000000004,
      "end": 458.05,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 458.05,
      "end": 461.73,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 461.73,
      "end": 465.09000000000003,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 465.09000000000003,
      "end": 468.05,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 468.05,
      "end": 469.89,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 469.89,
      "end": 471.97,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 471.97,
      "end": 476.28999999999996,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 476.28999999999996,
      "end": 477.49,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 477.49,
      "end": 479.49,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 479.49,
      "end": 481.09000000000003,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 481.09000000000003,
      "end": 482.89,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 482.89,
      "end": 484.69,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 484.69,
      "end": 486.49,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 486.49,
      "end": 488.89,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 488.89,
      "end": 490.28999999999996,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 490.28999999999996,
      "end": 492.09000000000003,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 492.09000000000003,
      "end": 494.89,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 494.89,
      "end": 496.28999999999996,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 496.28999999999996,
      "end": 499.09000000000003,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 499.09000000000003,
      "end": 500.99,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 500.99,
      "end": 503.78999999999996,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 503.78999999999996,
      "end": 505.89,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 505.89,
      "end": 506.85,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 506.85,
      "end": 508.61,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 508.61,
      "end": 511.33000000000004,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 511.33000000000004,
      "end": 514.45,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 514.45,
      "end": 519.5699999999999,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 519.5699999999999,
      "end": 522.85,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 522.85,
      "end": 524.9300000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 524.9300000000001,
      "end": 526.9300000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 526.9300000000001,
      "end": 528.37,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 528.37,
      "end": 529.89,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 529.89,
      "end": 531.49,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 531.49,
      "end": 535.17,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 535.17,
      "end": 536.9300000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 536.9300000000001,
      "end": 538.13,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 538.13,
      "end": 541.81,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 541.81,
      "end": 542.45,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 542.45,
      "end": 545.49,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 545.49,
      "end": 547.01,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 547.01,
      "end": 548.9300000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 548.9300000000001,
      "end": 550.53,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 550.53,
      "end": 551.81,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 551.81,
      "end": 555.01,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 555.01,
      "end": 557.0899999999999,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 557.0899999999999,
      "end": 557.5699999999999,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 557.5699999999999,
      "end": 559.01,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 559.01,
      "end": 560.53,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 560.53,
      "end": 561.25,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 561.25,
      "end": 562.37,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 562.37,
      "end": 562.69,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 562.69,
      "end": 564.21,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 564.21,
      "end": 565.4100000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 565.4100000000001,
      "end": 566.85,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 566.85,
      "end": 567.37,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 567.37,
      "end": 568.45,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 568.45,
      "end": 569.5699999999999,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 569.5699999999999,
      "end": 570.73,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 570.73,
      "end": 572.05,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 572.05,
      "end": 573.1700000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 573.1700000000001,
      "end": 574.49,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 574.49,
      "end": 575.97,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 575.97,
      "end": 577.61,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 577.61,
      "end": 579.21,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 579.21,
      "end": 579.73,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 579.73,
      "end": 580.4100000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 580.4100000000001,
      "end": 581.01,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 581.01,
      "end": 583.37,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 583.37,
      "end": 584.65,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 584.65,
      "end": 586.61,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 586.61,
      "end": 587.65,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 587.65,
      "end": 589.25,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 589.25,
      "end": 592.0899999999999,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 592.0899999999999,
      "end": 593.89,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 593.89,
      "end": 596.45,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 596.45,
      "end": 597.97,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 597.97,
      "end": 599.4100000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 599.4100000000001,
      "end": 600.05,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 600.0,
      "end": 602.4,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 602.4,
      "end": 604.2,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 604.2,
      "end": 606.2,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 606.2,
      "end": 607.8,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 607.8,
      "end": 610.5,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 610.5,
      "end": 611.8,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 611.8,
      "end": 613.3,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 613.3,
      "end": 616.0,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 616.0,
      "end": 617.6,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 617.6,
      "end": 619.2,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 619.2,
      "end": 621.4,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 621.4,
      "end": 622.7,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 622.7,
      "end": 623.7,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 623.7,
      "end": 625.8,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 625.8,
      "end": 627.9,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 627.9,
      "end": 629.54,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 629.54,
      "end": 631.1,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 631.1,
      "end": 632.38,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 632.38,
      "end": 634.18,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 634.18,
      "end": 635.22,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 635.22,
      "end": 636.54,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 636.54,
      "end": 637.5,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 637.5,
      "end": 638.98,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 638.98,
      "end": 640.1,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 640.1,
      "end": 641.18,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 641.18,
      "end": 643.7,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 643.7,
      "end": 644.9,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 644.9,
      "end": 647.38,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 647.38,
      "end": 648.98,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 648.98,
      "end": 650.94,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 650.94,
      "end": 652.54,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 652.54,
      "end": 653.66,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 653.66,
      "end": 655.06,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 655.06,
      "end": 656.34,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 656.34,
      "end": 657.62,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 657.62,
      "end": 658.9,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 658.9,
      "end": 661.22,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 661.22,
      "end": 664.02,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 664.02,
      "end": 665.7,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 665.7,
      "end": 667.14,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 667.14,
      "end": 668.66,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 668.66,
      "end": 670.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 670.1800000000001,
      "end": 671.38,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 671.38,
      "end": 672.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 672.1800000000001,
      "end": 674.5,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 674.5,
      "end": 676.26,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 676.26,
      "end": 678.98,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 678.98,
      "end": 680.8199999999999,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 680.8199999999999,
      "end": 682.1,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 682.1,
      "end": 683.7,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 683.7,
      "end": 686.5,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 686.5,
      "end": 689.86,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 689.86,
      "end": 692.26,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 692.26,
      "end": 693.14,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 693.14,
      "end": 694.02,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 694.02,
      "end": 694.98,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 694.98,
      "end": 696.02,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 696.02,
      "end": 698.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 698.1800000000001,
      "end": 700.42,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 700.42,
      "end": 702.1,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 702.1,
      "end": 703.22,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 703.22,
      "end": 706.1,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 706.1,
      "end": 708.26,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 708.26,
      "end": 709.86,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 709.86,
      "end": 710.9,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 710.9,
      "end": 711.86,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 711.86,
      "end": 712.9,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 712.9,
      "end": 714.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 714.1800000000001,
      "end": 715.58,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 715.58,
      "end": 717.1,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 717.1,
      "end": 718.5,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 718.5,
      "end": 721.06,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 721.06,
      "end": 722.54,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 722.54,
      "end": 723.98,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 723.98,
      "end": 726.34,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 726.34,
      "end": 727.78,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 727.78,
      "end": 729.3,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 729.3,
      "end": 731.26,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 731.26,
      "end": 735.34,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 735.34,
      "end": 737.8199999999999,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 737.8199999999999,
      "end": 739.7,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 739.7,
      "end": 740.74,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 740.74,
      "end": 742.42,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 742.42,
      "end": 744.26,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 744.26,
      "end": 746.58,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 746.58,
      "end": 748.14,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 748.14,
      "end": 750.7,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 750.7,
      "end": 752.58,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 752.58,
      "end": 754.14,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 754.14,
      "end": 755.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 755.1800000000001,
      "end": 757.1,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 757.1,
      "end": 759.66,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 759.66,
      "end": 761.3,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 761.3,
      "end": 763.74,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 763.74,
      "end": 766.06,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 766.06,
      "end": 768.3,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 768.3,
      "end": 770.22,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 770.22,
      "end": 772.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 772.1800000000001,
      "end": 775.5,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 775.5,
      "end": 777.22,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 777.22,
      "end": 778.86,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 778.86,
      "end": 780.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 780.1800000000001,
      "end": 782.22,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 782.42,
      "end": 784.58,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 784.58,
      "end": 786.38,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 786.38,
      "end": 788.9,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 788.9,
      "end": 790.78,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 790.78,
      "end": 793.54,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 793.54,
      "end": 795.7,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 795.7,
      "end": 797.3,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 797.3,
      "end": 799.02,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 799.02,
      "end": 800.38,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 800.38,
      "end": 802.38,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 802.38,
      "end": 805.38,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 805.38,
      "end": 807.58,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 807.58,
      "end": 808.6800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 808.6800000000001,
      "end": 810.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 810.1800000000001,
      "end": 812.48,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 812.48,
      "end": 814.58,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 814.58,
      "end": 816.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 816.1800000000001,
      "end": 818.48,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 818.48,
      "end": 820.58,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 820.58,
      "end": 821.98,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 821.98,
      "end": 823.08,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 823.08,
      "end": 825.38,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 825.38,
      "end": 826.78,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 826.78,
      "end": 829.78,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 829.78,
      "end": 832.98,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 832.98,
      "end": 834.78,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 834.78,
      "end": 836.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 836.1800000000001,
      "end": 837.58,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 837.58,
      "end": 838.98,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 838.98,
      "end": 840.58,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 840.58,
      "end": 843.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 843.1800000000001,
      "end": 844.58,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 844.58,
      "end": 846.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 846.1800000000001,
      "end": 848.78,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 848.78,
      "end": 850.58,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 850.58,
      "end": 851.58,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 851.58,
      "end": 854.78,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 854.78,
      "end": 857.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 857.1800000000001,
      "end": 859.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 859.1800000000001,
      "end": 860.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 860.1800000000001,
      "end": 861.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 861.1800000000001,
      "end": 862.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 862.1800000000001,
      "end": 863.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 863.1800000000001,
      "end": 865.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 865.1800000000001,
      "end": 866.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 866.1800000000001,
      "end": 867.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 867.1800000000001,
      "end": 868.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 868.1800000000001,
      "end": 869.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 869.1800000000001,
      "end": 871.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 871.1800000000001,
      "end": 873.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 873.1800000000001,
      "end": 874.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 874.1800000000001,
      "end": 876.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 876.1800000000001,
      "end": 878.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 878.1800000000001,
      "end": 880.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 880.1800000000001,
      "end": 881.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 881.1800000000001,
      "end": 883.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 883.1800000000001,
      "end": 884.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 884.1800000000001,
      "end": 886.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 886.1800000000001,
      "end": 887.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 887.1800000000001,
      "end": 888.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 888.1800000000001,
      "end": 892.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 892.1800000000001,
      "end": 894.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 894.1800000000001,
      "end": 897.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 897.1800000000001,
      "end": 899.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 899.1800000000001,
      "end": 900.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 900.0,
      "end": 902.0,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 902.0,
      "end": 905.5,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 905.5,
      "end": 908.0,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 908.0,
      "end": 910.0,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 910.0,
      "end": 914.0,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 914.0,
      "end": 916.0,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 916.0,
      "end": 918.0,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 918.0,
      "end": 920.0,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 920.0,
      "end": 923.0,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 923.0,
      "end": 926.0,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 926.0,
      "end": 928.0,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 928.0,
      "end": 929.32,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 929.32,
      "end": 932.0,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 932.0,
      "end": 934.12,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 934.12,
      "end": 937.28,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 937.28,
      "end": 937.84,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 937.84,
      "end": 939.04,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 939.04,
      "end": 941.4,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 941.4,
      "end": 942.16,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 942.16,
      "end": 943.48,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 943.48,
      "end": 944.84,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 944.84,
      "end": 947.36,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 947.36,
      "end": 949.2,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 949.2,
      "end": 950.16,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 950.16,
      "end": 951.16,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 951.16,
      "end": 951.72,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 951.72,
      "end": 952.36,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 952.36,
      "end": 952.92,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 952.92,
      "end": 953.68,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 953.68,
      "end": 955.68,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 955.68,
      "end": 958.08,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 958.08,
      "end": 959.28,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 959.28,
      "end": 961.28,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 961.28,
      "end": 962.88,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 962.88,
      "end": 964.28,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 964.28,
      "end": 965.58,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 965.58,
      "end": 966.48,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 966.48,
      "end": 968.6800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 968.6800000000001,
      "end": 971.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 971.1800000000001,
      "end": 972.88,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 972.88,
      "end": 975.58,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 975.58,
      "end": 977.58,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 977.58,
      "end": 979.38,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 979.38,
      "end": 979.98,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 979.98,
      "end": 982.28,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 982.28,
      "end": 984.28,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 984.28,
      "end": 987.28,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 987.28,
      "end": 988.98,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 988.98,
      "end": 991.58,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 991.58,
      "end": 992.28,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 992.28,
      "end": 994.58,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 994.58,
      "end": 995.38,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 995.38,
      "end": 997.28,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 997.28,
      "end": 998.98,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 998.98,
      "end": 1002.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1002.1800000000001,
      "end": 1003.48,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1003.48,
      "end": 1005.6800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1005.6800000000001,
      "end": 1006.98,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1006.98,
      "end": 1011.58,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1011.58,
      "end": 1013.1800000000001,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1013.1800000000001,
      "end": 1014.66,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1014.66,
      "end": 1016.98,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1016.98,
      "end": 1018.5,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1018.5,
      "end": 1019.58,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1019.58,
      "end": 1020.7,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1020.7,
      "end": 1021.94,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1021.94,
      "end": 1023.46,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1023.46,
      "end": 1026.06,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1026.06,
      "end": 1028.82,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1028.82,
      "end": 1030.38,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1030.38,
      "end": 1031.38,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1031.38,
      "end": 1033.7,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1033.7,
      "end": 1036.62,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1036.62,
      "end": 1039.1,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1039.1,
      "end": 1040.78,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1041.58,
      "end": 1044.54,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1044.54,
      "end": 1047.9,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1047.9,
      "end": 1052.9,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1052.9,
      "end": 1057.02,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1057.02,
      "end": 1060.9,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1060.9,
      "end": 1063.7,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1063.7,
      "end": 1065.06,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1065.06,
      "end": 1067.82,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1067.82,
      "end": 1069.34,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1069.34,
      "end": 1073.98,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1073.98,
      "end": 1076.1,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1076.1,
      "end": 1080.66,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1080.66,
      "end": 1082.5,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1082.5,
      "end": 1083.98,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1083.98,
      "end": 1085.94,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1085.94,
      "end": 1090.06,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1090.06,
      "end": 1092.78,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1092.78,
      "end": 1096.46,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1096.46,
      "end": 1098.38,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1098.38,
      "end": 1101.3,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1101.3,
      "end": 1104.3,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1104.3,
      "end": 1105.94,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1105.94,
      "end": 1108.22,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    },
    {
      "start": 1108.22,
      "end": 1110.02,
      "text": "今天我们来聊一个最近在AI圈特别火 但很多人还没真正弄懂的词 Harness Engineering 如果你最近也在做Agent 或者关注AI应用的落地 或多或少可能都会遇到这样的问题 为什么同样的模型 别人做出来的Agent 可以连续跑很久 成为率很高 到了自己手里就总是差强人意 很多人可能会想是不是模型不够强 是不是提示词没调好 是不是IG没调明白 当然这些都有影响 但是越来越多的团队最后发现 真正决定我们的系统能不能稳定的跑起来 往往不是模型本身 而是模型外面那套运行的系统 那这套东西呢 现在有了一个统一的名字 就叫Harness 大家好 欢迎来到克特命花园 我是欢迎老师 为什么想聊这个话题呢 因为年初的时候 有个朋友找我帮他们调一个Agent 他们团队之前已经做了很多努力 换上了最好的极箭模型 提示词改了上百版 各种参数也调得不少 但是已经真实的成绩 效果还是不稳定 有的时候很聪明 有的时候用莫名的跑偏 任务的成功率不到70% 那后来呢 我去帮他们看了一下 最后的改动最大的地方 反而不是模型 也不是提示词 我的改进点呢 在于任务是怎么拆的 状态是怎么管的 关键的步骤要怎么教验 失败之后要怎么恢复 结果新版本上下之后呢 还是同样的模型 同样的提示词 成功率拉到了95%以上 那当时这个朋友问我 你到底改了什么呢 说实话 那个时候 我没有一个特别准确的词来形容 直到最近 Harnes and Niren这个概念越来越火 我才意识到 我当时改的这些东西 本质上就是Harness 所以今天这期视频呢 我想彻底把这个概念跟大家讲清楚 我们主要分三个部分 Harness是怎么一步步演进出来的 一个成熟的Harness 到底包括哪些部分 OpenAI AstroBIG这些公司 真实到底是怎么做的 过去两年呢 AI工程其实经历了三次很明显的众议迁移 从Prompt Engineering Context Engineering 再到最近的Harness Engineering 表面上看 好像只是换了几个新的名词 但如果你只是把它理解成 属于流行史那就完全低估他们了 那这三个词分别对应了现在AI系统发展的三个阶段性问题 模型有没有听懂你在说什么 模型有没有拿到足够而且正确的信息 模型在真实的执行里能不能持续的作对 你会发现这些问题是一层一层往外扩张的 在大模型刚活起来的时候 大家最直观的感受就是同一个模型 你换一种说法 结果可能差很多 比如你说一句帮我总结一下这篇文章 他可能只会给你一个很平的总结 但如果你换一种说法 效果马上就会不一样 所以那个阶段 大家都相信一件事情 模型不是不会 而是你没有把问题说明白 于是大家开始疯狂的研究提示词 什么角色设定 奉革约束 非优秀的势力 分部引导 输出格式等等 那为什么这些东西有效呢 因为大模型本质上是一个对上下文 非常敏感的概率生成系统 你给它什么身份 它很容易沿着那个身份去回答 你给它什么样的样率 它很容易沿着那个范氏去补权 你强调什么样的约束 它就很容易把那一部分当成重点 所以提示词工程的本质不是秘密模型 而是塑造一个局部的概率空间 那这个阶段的最重要的能力 不是系统的设计 而是语言的设计 但提示词工程很快就遇到了天花板 因为很多任务不是你说清楚就行 而是你真的得知道 比如你让模型分析一份公司的那部文档 回答一个产品的最新配置 按照一套非常长的规范去携带码 在多个工具之间完成复杂的任务 这个时候你会发现 提示词写得再漂亮 也替代不了事实本身 所以提示词擅长的是 长期任务约束输出 激发模型的已有能力 但是它不擅长 天空弥补缺势的支持 管理大量动态的信息 处理长连录任务里的状态 说白了 提示词解决的是表达的问题 不是信息的问题 于是第二阶段开始了 当大家还只是做聊天机艺人的时候 提示词的作用很大 因为任务短、链路短、状态少 很多问题确实靠把话说明白就可以解决了 但后来Agent开始火了 模型不只是要回答问题 而是要进到真实的环境里面做事情 它要多论对话、调瀏览器、解开码 输入于故事的工具 还要在多个步骤之间传递中间结果 还要根据Web的反馈不断修建计划 这个时候问题就变了 系统面对的已经不是一次回答对不对 而是整条链路的任务能不能跑通 比如如果你不是简单的问题句 帮我总结一下这篇文章 而是让它做一个更真实的任务 比如说 帮我分析这份需求文档找出潜带风险 结合历史的评认意见 给出改缘建议 再生成一版 发给产品经理的返回稿 你会发现 这已经完全不是一句提示词就能解决的问题了 它至少要拿到当前的需求文档 历史的评认记录 先回归范当前目标 已经分析出来中间结论 输出的对象是谁 语气应该怎么调 等等等等 所以 context-engineering的核心就变成一句话 模型未必是知道的 系统必须在合适的时机把正确的信息送进去 那这里的context也不只是几段背景的资料 在工程的意义上 它代表了所有影响模型当前决策的信息的总和 包括用户的输入 历史对话 检索结果 工具返回 当当前任务的状态 中间产物 系统规则\n安全约束或者其他Agent传过来的结果化的结果 所以你会看到 prompt其实只是context的一部分 也正因为如此 推到上下文的攻击机制是非常重要的 那说到context engineering 我觉得IG也算是一个比较典型的实践 IG的价值是很直接的 模型参数里面没有指示 怎么在运行时补进去呢 那做法大家都知道 先检索再把相关的内容塞到上下文 但是真正成熟的context engineering 关注的肯定不只是检索 它关注的是整体完整的链路 比如文档怎么切块 结果怎么排序 常文怎么压缩 历史对话什么时候要保留 什么时候要摘药 工具返回要不要全部暴露给模型 多个Agent之间 到底传原文摘药还是结果的自断呢 包括最近很火的Agent Skills 我觉得本质上也是上下文工程的高级实践 因为它解决了一个特别现实的问题 如果你把十几个不同的工具 工具的说明所有的参数定义 全部一上来就塞给模型 理论上模型会知道的更多 但是实践往往会更糟糕 为什么呢 因为上下文的窗口是非常稀缺的资源 信息一多 注意力就回换赞 所以Skill采用的是一个非常典型的思路 叫渐进时披露 不是一开始就把能力全部给模型看 而是只给它看最少量的原信息 等它真正的要触发某些能力的时候 再把那部分的SOP 详细的参考信息 脚本动态的加进来 那这个思路呢 其实非常重要 因为它告诉我们 上下文的优化不只是给的更多 而是按需给分层给 在正确的实际给 但是上下文工程其实也不只是终点 因为后来大家又发现了一个更麻烦的问题 就算信息给对了 模型也不一定能稳定地执行的正确 它可能计划做得很好 但是执行跑偏了 掉了工具 但理解错了反回结果 在一个很长的电路里已经慢慢偏行了 但是系统却没有发现 这个时候我们发现 提示词和上下文其实主要的解决 都在输入词的问题 提示词优化意图地表达 上下文优化的是信息的攻击 但是复杂的任务里 还有一个更难的问题 当模型开始连续行动的时候 谁来见读它、约束它和纠编它呢 这个时候,第三阶段来了 Harnes这个词呢 原本的意思是 江神、马具、约束装置的意思 放到AI系统里面 就是在提醒我们一件非常普速的事情 当模型从回答问题走向执行任务系统 不只要能够负责卫星席 还要能够驾驭整个过程 这个就是Harnes and De Niering的出发点 如果前两代工程关注的是 怎么让模型更会想 那Harnes更关注的就是 怎么让模型别跑偏,跑得稳,出了错还能拉回来 这里呢,我用一个比较通俗的例子来解释这三个概念 假设你要派一个新人去完成一次很重要的客户拜访的工作 prompt engineering就是你要告诉他先把任务讲清楚 比如见面先行宣,再介绍方案,再问需求,最后劝人下一步 这个就是prompt,重点是把话说明白 那contest engineering是啥呢? 你要告诉他把资料要准备齐全 比如说这个客户的背景,过往的沟通记录,产品的报价,竞品的情况 这次会议的目标 这些都是context的重点 是把信息要给对 那如果这个会议真的很重要 你还会继续做很多事情 比如说让他带着checklist去 让他在关键的节点实施汇报 会后何时计要和录音 如果发现偏差马上纠正 最后按照明确的标准去验收结果 这些就是Harness 重点已经不是说清楚和资料起不起了 而是有没有一套持续观测 持续揪篇最终验收结果的机制 所以这三者也不是替代关系 而是包含的关系 prompt是对指令的工程化 context是对输入环境的工程化 harness就是对整个运行系统的工程化 它们的边界是一层比一层大的 Lunchin的工程师给harness下了一个很典型的定义 agent等于model加harness harness就等于agent.model 翻译成人话就是 在一个agent的系统里面 除了模型本身以外 几乎所有能决定它能不能稳定交付的东西 都可以算尽harness 那如果拆开来看呢 我自己会把一个成熟的Harness Engineering分成六层 第一层啊 就是我们重新站在Harness的视角去看Context 模型能不能稳定发挥 很多时候不仅取决于它聪不聪明 而取决于它看到了什么 所以Harness的第一职责 就是让模型能够在正确的信息边界内思考 第一层通常包括三件事情 首先啊 角色的目标和定义 模型要知道自己是谁 任务是什么 成功的标准是什么 第二 信息的抬检和选择 上下文不是越多也好 而是越相关越好 第三啊 结构化的组织 固定的规则放在哪儿 帮起的任务放在哪儿 任务运行的状态放在哪儿 外部的证据又放在哪儿 最好分层清楚 因为信息一旦乱掉呢 模型就很容易漏重点 忘约束甚至自我污染 第二层 工具系统 没有工具 大模型本质上还是一个文本鱼色器 会解释 会总结 但它接触到真实的世界 一旦连上工具呢 模型才可以真正的做事 比如算网页、读文等、写单码、调 API等等等等 但是Harness在这里做的 不是简单的把工具挂上去 而是也有解决三个问题 第一 给它什么工具 工具太少\n能力不够,工具太多,模型又会乱用 第二,什么时候该调用工具? 本来不需要查的时候别乱查 该查证的时候也别硬答 第三,工具结果怎么重新未会模型? 送送过来的几十条结果 不应该远峰不动地塞回去 而是要提炼、筛选、保持和任务的相关性 第三层,执行编排 那这层解决的核心问题呢 就是,模型下一步该做什么? 很多AZ的问题呢 不是某一步不会 而是不会把所有的步驻给串起来 它会搜索,也会总结,也会携带嘛 但整个过程想到哪做到哪 最后交付出来一堆半成品 所以一个完整的任务 通常需要有这样的轨道 首先理解目标 然后判断信息够不够 不过继续补卧 继续结果继续分析 然后上程输出 检查输出 不满足要求就重新修正或者重视 这个时候你会发现 这已经非常接近人在工作了 区别在于人靠经验 agent靠Harnes这套环境 第四层记忆和状态 那没有状态的agent 每一轮都会像失忆一样 他不知道自己刚做了啥 也不知道哪些结论已经确认了 哪些问题还没解决 所以Harness还必须要管理状态 这里我们要至少让他分清三类东西 首先当前任务的状态 绘画中的中间结果 长期的记忆和用户偏好 这三类如果混在一起 系统会越来越乱 看清楚之后 Agent才会像一个稳定的协作者 第五层 评估和观测 这个就是很多团队最容易忽视的一层 很多系统其实不是生成不出来 而是生成完了之后 根本不知道自己做得好不好 如果没有独立的评估和观测的能力 agent就会长期停留在自我感觉良好的状态 这一层通常包括输出和验收 环境的验证 自动测试 日治和指标 错误的归因等等 也就是说系统不仅是要挥作 还要知道自己有没有真的能够作对 第六层约束教验 失败和恢复 最后一层往往才是真正决定这个系统 能不能上线的关键环节 因为在真实的环境里面 失败不是例外 而是常态 可能搜索不准 可能是API超时 也可能文档隔世混乱 或者模型误解的任务 那如果没有恢复的机制 Agent每次出错就只能从头再来 所以一个成熟的Harnes 一定要包括三件事情 约束哪些能做哪些不能做 教验比如输出之前 输出之后要怎么检查 恢复失败之后怎么从事 切入境回滚到稳定的状态 专案概念我们来看最有参考价值的部分 一线公司的真实实践 因为Harnes这个词 最近之所以突然火起来 不是大家在空谈这个方法论 而是很多公司都已经把它做进了 产品和工程体系里面了 比如Lunchin在底层模型完全不变的情况下 只通过改造和接待Harness 就把它自家的智能体业 从一个把蓝上的排名 直接从30开外杀到了前5 OpenAI依靠一个只有几名人类工程师的团队 用Agent从零构建了一个 超百万行代码的生产基金用 100%的代码都是由Agent编写的 耗时只有纯人工开发的十分之一 那Anthropic也构建了一个 可以完全自主编码的系统 只凭一句自然源的需求就能在无需人类干预的情况下 连续运行几个小时 最后做出完整的游戏 完整的数字音频工作站 那我们先看看Athropic的实践 首先他们在长生自主的任务上 总结了两个特别典型的问题 那第一个问题我自己把它翻译成上线文交曆 时间一长上线文越来越满 模型就开始丢细节丢重点 甚至还会出现一种很有意思的现象 他好像知道自己快装不下了 于是开始着急的去收尾 很多系统面对这种问题 都会做context complication 也就是把前面的历史上下文压缩一下再继续跑 但Athrobic发现对一些模型来说 这还是不够的 因为压缩只是变短了 无代表那种负担感真的消失了 所以他们做了一件更积极的事情 叫context reflect 不是在原上下文里面继续压R式 换了一个非常干净的新的agent 把工作交接给它 这个思路很像什么呢 特别像工程里面遇到内存泄漏之后 不是继续倾缓存 R式直接重启整个进程在恢复状态 这个其实就是一种非常典型的Harnes设计 那anthropic解决的第二个问题呢 就是自平施争的问题 首先模型自己干活 再让它自己给自己打分 往往会是会偏乐观的 尤其是在设计、体验、产品、完整度这类 没有标准答案的问题上 偏差是更明显的 所以他们采用了一个非常关键的思路 把干活的人和验收的人分开 他们是这样采分的 Planer负责把模糊的需求获产成完整的规格 Denarator负责逐步的去实现 Evaluator负责像QA一样去 去真实的测试 更关键的是 这个Evacwriter 它不只是会看代码 而是会真实的操作页面 看具体的交互 检查实际的结果 也就是说 这不是一个抽象的审查 它是一个带具体环境的验证 这个事情非常重要 因为它背后是一个 很明确的工程原则 生产验收必须分离 只要评估者足够独立 系统就能形成一个 真正的有效循环 生成检查修复 再检查的这样的一个循环 那OpenN 在这方面 感觉是他们重新定义了工程师在Agent的时代的工作 他们做了一个非常有意思的思路 人类在这个环境里面不需要写一行的代码 人类只需要去负责设计环境 具体来说\n说,工程师的工作变成三件事情 首先,把产品目标拆解成Agent能力阶的小任务 Agent失败的时候,不是让它更努力一点 而是问环境里缺了什么能力 最后建立返回的链路,让Agent真正能够看到自自己的工作结果 这句话我是非常认同的 当Agent出了问题的时候 修复方案几乎从来不是要更努力一点 而是确定它缺了什么样的结构性的能力 这个其实也是典型的Harnes思维 我们也还有一个特别典型的事件 也是见尽时披露 他们早期犯过一个很多团队都会犯的错误 写了一个巨大的Agent 4.md 把所有的规范框架约定全部塞进去了 结果呢 Agent更糊涂了 因为上线门窗口是一个稀缺的资源 塞得太满 其实等于什么都没说 后来他们怎么改的呢 把Agent 4.md变成一个目录页 页面只保留核心的索引 更详细的内容呢 拆到架构文档 设计文档 执行计划 执行评分 安全规则 这些具体到紫文档里面去了 那Agent的先看目录需要的时候再钻进去 那这个时候我们会发现 这个和我们前面说的Scales 本质上是一个词录 不是一次性全给 而是暗虚暴露 还有一个实践啊 就是OpenAI不只是让Agent写代码 还会让Agent看见整个应用 因为产业速度一旦上来呢 平静其实就不再是写而是验了 那人类呢根本是验不过来的 所以他们让Agent自己去验 怎么验呢 首先接浏览器能截图点验面 能模拟用户的真实操作 然后去给Agent接日式系统和指标系统 让它能够查LOG,查监控 最后每个任务都独立隔离的环境在跑 互不影响 结果就是Agent不再是写完代码 就说写完了 而是真正的可以跑起来看结果 翻显Bug,修Bug再验证 这个其实就是Harness里非常完整的一套 工具系统,执行编排 评估和观测,约束和恢复 还有一点需要注意的是 OVAI不只会靠人类在最后的CodeReview环节去兜底质量 因为agent的提交速度太快了 人类是盯不过来的 所以他们把很多资深工程式的经验 直接写成的系统规则 比如模块怎么分层 哪一层不能依赖哪一层 什么情况下必须拦截 发现问题之后应该怎么修 重点是这些规则不只是负责抱错 而是会把怎么修也一起返回给agent 进入下一轮的摄像本 那你会发现 这已经不是传统意义上的代码规范了 而是一套可持续运行的自动智力系统 这个也是Harnes的典型形态 最后我们说一下 engineering 解决的是怎么把任务讲清楚 context engineering 解决的是怎么把信息都给对 Harness engineering 解决的是怎么让模型在真实的执行中持续作对 所以Harness不是在取代prompt 也不是在取代context 它是在更大的系统边界上把前两者都包含进来 当任务还是简单的单额生长的时候 prompt是很重要的 当任务开始依赖web支持去运行信息的时候 context就很关键了 当模型真的进入了常链路可执行低融错的真实场景里面 Harnes几乎就是不可避免的 这是为什么同样的模型在不同的产品里面表现差距会这么大 因为真正决定上线的可能是模型 但是真正决定能不能落地 能不能稳定交付的就是Harnes 到了这个阶段我们也看清了一个现实AI落地的核心挑战 正在从让模型看起来更聪明 转向让模型在真实世界里稳定的工作 如果你最近也在做Agent 我觉得这件事情非常值得你趁早想明白 好,本期教程的内容就是这么多 如果本期教程对你有所帮助 希望得到一个免费的三连和关注 感谢大家,我们下期见"
    }
  ],
  "language": "",
  "source": "whisper_chunked_parallel",
  "model": "small"
}