Sdd怎么升级成harness

哈喽，大家好，我是迪迪，今天想跟大家聊一个最近很火的话题，叫 harness。 只要你在研究 ai agent 这个词其实是绕不开的。那大多数人对它的理解其实暂时停留在听说过，但不清楚它到底是什么，为什么需要它？它长什么样。那今天我就跟大家一起来用三分钟的时间把它给剖析开。 第一个呢？什么是 harness？ 先给一个最简单的定义，其实它就是一个包裹在 ai 模型外面的一层结构，它的作用是让模型能够保持在正轨上，不跑偏，不半途而废，不自己乱来。 它具体包括哪些东西？它是一个整体，包括有提示词，工具的调用，反馈循环啊，验证机制等等。那简单来说，它其实就是一个模型周围的一切，把一个会聊天的 ai 变成一个可以真正完成复杂任务的可靠的一个系统。 这边有两个类比可以大家去看一下。比如说它是一个车子，那模型本身呢？它就是一个发动机的引擎，而 harness 本身，它其实是整辆车子，没有这辆车子，发动机只是在原地的空转，那你哪里都去不了。那有了车子， 有了 harness， 有 了模型，你才可以把客户送到目的地，所以这个是一个比喻。那下面一个比喻呢？就是马与万俱， 一匹野马的力力量很大，它想跑哪里就跑哪里，你控制不了，但是这个时候你给它套上这个 harness 万具，你就能够引导它的力量朝你想去的一个方向走。所以说 ai 模型的话，可以比喻成一个野马，而有能力，但需要被引导，而 harness 就是 那副马万万具， 所以有了这两个类比，我们大致就有了 harness 是 什么样的一个概念。那接下来就是我们为什么会需要 harness， 没有 harness 会怎么样呢？那现在大家都在谈 ai agent， 核心问题只有一个，怎么给 ai 一个复杂的目标，让它自己能够主动地工作几天几小时， 那最后可以看一下他有没有真正的完成这件事。如果说没有 harness， 会出现几个典型的一个问题，第一个就是 ai 会试图的一口气把所有事情都跑完，结果跑到一半上下文用完了，直接中途就停止了。那第二个可能遇到的情况就是断头了，他可能把工作做到一半就停下来，什么交接文档都不做， 这样的呢，下一步根本就不知道另外一个模型去的时候能够做什么东西。第三个就是一个假完成，其实也是最麻烦的，他会提前宣布任务完成，看起来做完了，但是你一用的话，其实发现根本跑不起来。这不是一个偶发的一个故障，而是 ai agent 在 长时间运行时候的一个通病， 那模型越强大，没有 harness 其实问题会暴露的越明显。所以有一个正确的结论就是对于长时间运行的一些复杂的任务， harness 的 设计和模型其实本身一样重要，不是模型越强，其实就能解决一切，那模型再强，没有合适的 harness， 它照样会跑偏。 所以接下来我们就来看一下 harness 的 一些基本结构。 astropic 最早的一个方案是两部分的系统，第一个是一个原始的初设化的 agent， 它负责配置环境、拆分功能的模块创建、进度的追踪，这样呢就是一个基本的一个初设化 agent。 第二部分呢，就是一些编码的 agent， 它每次只处理一个功能，然后做完呢提交给 git， 同时呢留下一些清晰的交接材料，方便下一个 agent 去接手继续工作。所以这边是编码 agent 一， 编码 agent 二，一直往下。 那这套设计的核心逻辑其实就是三件事情，把一个大目标去分解开来，然后呢渐近推进，最后呢做一个干净的交接文件， 每次完成其实都是有记录，这样即使中途重启，也会从上次停掉的地方再继续接着干。那接下来我们看一下 harness 一个比较关键的机制，就叫做上下文的管理。 在 harness 的 设计里面，其实要了解它，先要了解一个问题，就是上下文的焦虑。随着对话越来越长，上下文的窗口其实被填满了， 模型的行为也会因此而改变，它不只是失去了连贯性，它会开始急着收尾，草草了事，甚至明明没有完成，也会说，我完成了。你如果跟 ai 在 一个对话里面交谈太久的话，其实经常会发现它的回复后面会变得越来越短，然后越来越敷衍，这就是同一个现象。 那有一种呢，就是上下文的压缩 compacting， 他 可以把历史对话压缩摘要，让腾出一些空间。但即使很多时候使用了压缩，但是模型有些时候还是会出现焦虑的一个情况，原因是他没有真正从头开始，脑子里还残留着快要结束的这些想法， 所以这个还是一个比较重要的问题，所以 harness 的 解决方案呢，就是上下文的重置，直接能够给它清空，开一个全新的上下文的窗口，把上一段的一个阶段的文件通过交接，然后给到下一个 agent， 让它从一个干净的一个起点继续去开始，然后不带任何焦虑去继续工作。所以这个就是一个重置的机制，也就是 harness 的 一个关键的机制。那另外一个 harness 的 另一个关键机制呢，就是叫评估 agent， 光有深沉还不够。 harness 里面呢，还有一个需要专门去挑毛病的角色叫评估的 agent， 为什么说需要他？因为如果你让同一个 ai agent 又做事又评价自己，那他几乎完全是不知道怎么样去评判，不知道怎么样去做，所以在人类看上去明明质量很差的情况，他还会说他做得非常的好。所以只有当两个 agent 完全分开的时候，才能够发现真正的问题。 评估 agent 的 工作模式就是像真实的用户一样去做结果的交互，在浏览器里面去点击操作，操作每个功能，去发现 bug， 写出具体问题，然后给到反馈，再生成给 agent 去修改。那这里就有个重要的现象， 评估 agent 不是 配置好就能用的，早期实验中，评估 agent 发现了问题，又说服自己说这不是一个大问题，直接放行。它测试的也很表面，不会主动地去挖掘里面的一些问题。 要让屏幕 agent 真正能够有效，需要多轮的打磨，花时间去调整它的一个判断标准，给到它一些具体的 guidelines， 所以 屏幕 agent 怎么样去设计也非常非常的重要，另外有一个点想跟大家分享，就是 harness 会随模型而进化。 harness 不是 一次性就能够搭好的，它每一个组建本质上其实就是对模型自己做不到这件事情的一个假设。上下文重置这个设计是因为当时模型有上下文的焦虑，所以当模型升级的时候，这个这个组建也就不再需要了，可以直接的去掉， 那评估 agent 的 价值也一样。如果说任务在模型的能力范围之内，评估 agent 是 多余的一个开销，那如果任务在模型的极限边缘，评估 agent 就 非常关键了。所以每一次开一个新的模型， 都要重新审视你的 harness， 去掉已经过时的一些假设，加入能够新的能力的一些组建，这个才是 ai 持续迭代 harness 一个真正的工作。 所以这个就是 harness 的 一些大概的一些观点和要点，它主要还是在模型外部的一些结构，把模型变成一个可靠的系统，没有它 ai 跑常规任务的时候就会跑偏卡死草草了事。 那它的核心组建包括之前说到的任务拆解、上下文的管理、评估、反馈等等，每个组建呢，其实都是针对模型每个具体弱点而设计的，而随着模型越来越强，这些组建其实也是会跟着去调整。 harness 的 设计其实和模型本身一样重要，所以之后我们在讲某一个模型，它在升级的时候，它随之对应的 harness 其实也是在不停地进化和优化。今天想跟大家分享的就是关于 harness 的 一切。

哈喽，大家好，我是勇哥，粉丝寄过来一台小度 x 八的升级版。什么是升级版呢？其实就是啊，普通的小度叉八增加了一个 hdmi 的 接口在背面啊， 在这里增加了一个 hdmi 的 接口，有了这个接口就可以将小度上的内容呢投放到电视上。那这就有意思了啊，你可以用更大的屏幕来使用这个小度。 但是呢，话又说回来了，这种小度的话，你不开会员，其实你看不到什么资源的，他很多东西都是要收费的，所以呢，粉丝寄过来要求扩容六十四 g 刷机双系统，安装第三方应用。这个升级版啊，和普通的叉八他的结构基本上差不多的。首先呢，我们要拆除这个装饰板，他这个之前是有布的，可能是粉丝给撕掉了， 然后这个屏幕呢，我们需要放到加热台上面去加热，加热完之后我们用拆机片呢拆一下这个屏幕， 左侧不要划啊，左侧有排线，排线划断了，屏就废了，三边划开之后，屏直接就可以打开了。拆掉这个螺丝啊，这个挡板呢也掉下来了。拔开这个屏幕的排线， 那这个屏呢，我们就拆下来了，现在我们拆掉能看到的所有的螺丝。 拆掉螺丝之后呢，我们现在拆一下这两个排线， 然后顶部这边撬一下。 好，这样呢，这个中框呢我们就可以拿掉了，这边还有个喇叭的排线。 ok， 这个中框的背后呢就是主板。 好的，这个主板呢我就拿掉了， 那这个设备的 cpu 呢，它是一个联发科的八幺六七 a 自库，是一个江波龙的八 g， 我 们现在呢就把江波龙这个八 g 芯片呢给它拆下来，然后换一个六十四 g 的。 好的芯片更换完毕了啊，我们现在呢给它组装起来。 好的，经过一顿折腾呢，现在我们终于搞好了，我们来看一下这边有个小白点，单击一下选择档位桌面，我们就可以来到档位的桌面。那这边呢能安装第三方的软件，切回角度呢也非常简单，点一下主屏就可以了。我们看一下储存空间。 那现在呢已经扩容到了六十四 g， 空间是非常非常充足的啊。 那这个系统呢，还可以搭配遥控器来使用啊，非常的方便啊。 好的，非常感谢大家能看到最后，我是勇哥，那我们下期再见啦，拜拜。

你有没有想过，未来的程序员可能一行代码都不用写？ open i 最近通过驾驭工程，彻底颠覆了软件开发的底层逻辑，这不仅仅是工具的升级，而是一场从写代码到指挥代码的物种进化。 在这场变格中，工程师的角色被彻底重构，我们不再是盯着屏幕逐行敲代码的搬运工， 而是进化为 ai 架构师。我们的核心任务变成了制定设计规划、确定 代码品味标准及设计自动化审查流程。像 cnyf 这样的系统，已经能从让 ai 智能体自主完成提交代码、解决冲突甚至部署测试的全弊方。最惊人的案例是， 一个三人团队在零人工写代码的情况下，竟然产出了百万级别的产品。应用 基础规范的跃迁更是令人扎舌。软件分发不再依赖传统的代码包，而是变成了幽灵库，一种可执行的规范文档。 ai 能根据 运行环境实时生成最适配的实现。甚至 ai 开始自主选择最适合的技术栈，比如 elext 语言，这完全突破了人类程序员的技能限制。更深层的变更在于知识管理， 每一次 ai 的 犯错不再是简单的报错，而是被转化为系统的集体智慧，自动更新规则与文档。这意味着代码正在沦为一种临时产物，而人类对系统本质的洞察、 目标定义的能力以及独特的品味，才成为不可替代的终极生产资料。 如果 ai 能搞定所有执行细节，你觉得未来程序员最核心的竞争力到底是什么？评论区聊聊。

到了二零二六年，大家应该都发现了，大模型越来越便宜，各家之间的智商差距也越来越小，不管你用谁家的 a、 p、 i 算力都快变成白菜价了。 但为什么在真实的业务里，有的 ai 能全自动帮你干一整天的活不出错？而你自己用大模型拼凑的 ai， 跑个五分钟就开始胡言乱语？这个秘密不在于模型本身有多聪明，而在于包着模型的那层外壳。在工程界，这层外壳被称为 agent harness， 也就是智能体运行框架。 过去我们总以为只要提示词写得好， ai 就 能干好活。但面对复杂的商业任务，光靠提示词根本兜不住底。 为了让 ai 不 乱来，工程师们引入了规范驱动开发，也就是 s、 d、 d。 简单来说，就是在 ai 动手之前，先给他定好死规矩，规定好他必须输出什么样的数据格式。这就好比给建筑工人画了一张极其严谨的施工图纸，但是图纸画得再好，施工现场没人盯着， ai 还是会跑偏。 因为大模型本质上是在做概率猜测，任务链条一长，它必定会产生幻觉。 harness 就是 施工现场那个铁面无私的监工。 ai 每走一步， harness 都要按规矩查验。你想输出结果， harness 先拦截下来，看看格式对不对。你想跑一段代码， harness 先把你塞进一个完全隔离的沙盒里，防止你把系统搞崩溃。 harness 的 存在，就是强行把 ai 天马行空的想象力按在一条绝对安全的轨道上摩擦，宁可让 ai 死板一点儿，也决不允许它在关键时刻掉链子。 很多人还有个误区，觉得给 ai 配的外部工具越多，他就越全能。但在实战中，给 ai 塞几十个复杂的 a、 p、 i， 他 反而会挑花了眼，连最基本的逻辑都会搞砸。真正顶级的 harness 都在做减法，把花里胡哨的工具全部砍掉，只给 ai 留最底层的权限， 把边界卡死。大模型反而能发挥出最强的推力能力。把 ai 管好之后，还得解决它和外部世界沟通的问题。以前想让 ai 连上公司的数据库或者办公软件，需要写一大堆定制的对接代码，极其痛苦。 现在大家都在用 m c p， 也就是模型上下文协议，你可以直接把它理解为 ai 界的 type c 接口，只要所有软件都支持这个协议， ai 拿这根虚拟的线一插，就能看懂所有数据，它让整个对接过程变得异常简单。 最后，当这些 ai 真正在公司里跑起来的时候，你怎么知道他有没有在后台偷偷发疯？以前我们监控软件只要服务器没死机，我们就觉得没问题，但这招对 ai 没用。服务器运行的好好的 ai 可能已经在用极其冰冷的逻辑伤害你的客户了。 这就需要一种全新的监控方式，也就是智能体的可观测性。它不仅看最终结果，还会把 ai 每一步的思考过程，每一次为什么调用这个工具，全部像树状图一样扒开给你看。配合上 harness 的 断点记忆功能，就算任务执行到一半断网了， ai 也能自动存档，下次直接从断点继续，彻底解决 ai 干着干着就失忆的问题。 所以是时候改变认知了。大模型现在只是廉价的发动机，而 agent harness 才是决定这辆车能不能安全上路的底盘和刹车。谁能搭好这套基础设施，把 ai 的 行为管住管好，谁就真正掌握了二零二六年 ai 时代的护城河。

让 ai 写代码总是一团糟，因为你少了一步画图纸。这就好比建房子没图纸，施工队全靠瞎蒙，这就是 s c d 规范驱动开发的本质。别急着敲代码，先让 ai 把你的想法转成一份结构化的施工蓝图， 你来审核蓝图， ai 在 严格暗图施工，先对其认知后下笔深挖，彻底告别 ai 的 自由发挥和代码幻觉。目前有敏捷的 open spec 和严谨的 spec kit 两大流派，真实业务如何兼顾？下期揭秘我们的融合玩法，点赞关注！

三个工程师，五个月一百万行代码，人类临行手写。这个夸张的数据出自 openai 内部的 harry sanderson 预剧工程。关于这篇文章，网上讨论很多，但今天我们不爆新闻，而是用结构化的视角来拆解它。 剥开表象，它其实结识了研发范式的三级，跳过去，我们怎么管 ai 写代码？第一层是 y， 不 扣定分为编程，也就是跟着感觉让 ai 写 ai 就 像个盲盒，快但不可控。第二层是 s、 d， d 归约，驱动开发 人先写好严谨的规范文档，再让 ai 按规范干活， ai 变成了流水线工人。而 harness engineering 是 第三层，也就是人在后， ai 在 前， 人不写代码，甚至不写具体规范，只负责三件事，第一件，搭环境，给 ai 接入浏览器、预制系统和监控，让它能自己去跑去试。第二件，定约束，用严格的分层架构和自动化检查，划出死线，这叫修赛道。 第三件，养文档，不是人写，而是派一个文档员丁， ai 去自动扫描，自动更新。这就好比 ai 是 一匹狂奔的马，有冲劲但不知道往哪跑。你不再需要代替马去跑步， 你的新工作是打造一副最完美的马具，包括江神和马安，也就是哈尼斯。 openai 真正想告诉我们的是，未来淘汰的将是低头敲代码的 code， 而最值钱的是能为 ai 制定纪律 搭建脚手架的 engineer。 这才是真正的工程师。点个关注不迷路，我们下期见。

我们来说一下路虎 sdd 的简单使用，当前选用的车辆是一台一六年的揽胜，我们打开 glr sdd， ok， 加载完毕，右下角提示一个设备连接已经成功，我们从这里可以观察一下这个绿色的这个 g l e c i 状态，就是一个设备的连接状态， 然后第三个这个蓄电池状态，它是一个车辆蓄电池的电压状态，还有一个 sdd 服务器，这个 像 wifi 图标一样啊，这个是一个网络连接，网络连接如果是没有没有连接好或者是断开的话，它是一个红色的 电瓶的话，如果是电瓶欠压，是一个黄色的图标，黄色的电瓶如果说是电瓶电已经亏电了，他就是变成一个红色的 设备连接必须是绿色状态。我们继续 跳转到当前页面之后，会出现一个车架号的读取， vin 的读取，我们选择自动读取 vin， 正在读取 vin， 这是当前 识别到的车辆的信息，这是一个车型 l 四零五发动机，是一个 v 六三点零的柴油机，带 dpf 年款一六年的车架号。开始新的回话， 打开点火开关，继续打开，师傅已将点火开关打开，是的， 这个软件版本管理箱导，这个下载的是一个边有念 这个编辑文件，这个编辑文件是关于车辆的配置信息，出厂配置信息，在此在此过程中网络需要保持连接状态。已经下载成功， 当前这个页面是需要对所执行的绘画进行的一个选择， 下面有交车签检查的绘画，还有测量应用程序 维修功能，活动诊断，绘画好关闭，绘画正常，我们读 去故障码就选择诊断，然后对模块进行配置或更换，就选择维修功能，需要读取模块的测量值就是实际值数据流这一块信息，我们就要选择测量应用程序。 交车前检查是删除运输模式，还有他的那个出厂限速我们需要执行交车前检查，我们通常需要毒故障的话就近诊断， 在诊断之前需要选择一下选定的症状，我们需要选定的症状是一个发动机的故障吧， 在传动器找到发动机燃油气味比较重，内或者外排放排气管冒烟多，根据他实际的情况进行一个选择，我们模拟检测一下， 选择完毕之后，点击右下角下面的继续，他会根据你所选的症状把故障进行分类。 这是当前车辆的空中单元，能够通讯的空中单元就是 上面当前能够通讯的单元，绿色对勾的是没有故障码的， 然后有一个爱的是有故障码的，如果打叉他就是模块不通讯。关于他的图标解释，我们看一下右上角 原型图标，打叉是已安装的模块未响应这个，也就是说这个东西，这个东西 rbm 这个模块在当前车辆配置里面他是存在的，实际存在的，但是他没有通讯了，然后 圆形的一个 i 是存在我存在的模块响应。 dtc 就是这个模块里面有故障码，就比方这个 pdm 当前有两个 dtc， 两个故障码。圆形对号的图标指示的意思是延 装的模块不存在 dtc 就是说已安装的模块，当前安装的模块是正常状态，没有过上马 四方图标里面有个问号是可选模块，未想要安装可选模块，他属于那种选配件，就比方当前车上他没有配备着 ipma 全摄像机， 这个模块是不通讯的。第二个四方形里面有个黄色的 i， 像这东西的话，他就是一个 选装件，存在有 dtc， 我们看一下空中单元数，在这上面我们找到 tcutcu 模块， 就远程信息处理模块，就是我们俗称的 sos 模块，他这个模块的话就是一个选装配件，选装配件并且有两个故，两个故障码， 四方形有个绿色对勾的，他就是这个选装模块已安装，并且是不存在 gtc 的，就像 gpm 轮胎压力监测器模块，这是关于图标的认识。

规范驱动开发真的是 ai 编程的最终答案吗？最近你一定听说过一个词，规范驱动开发软件专家 martin follow 专门写了一篇文章，分析了 kiro、 beckett、 tessar 这三款工具。今天呢，我用五分钟给你讲清楚它解决了什么，又解决不了什么。 什么是 sdd？ 它把 sdd 规范系统开发啊，定义为了一句话，在用生成式 ai 写代码之前，先写清楚规范，让规范成为代码生成的可信来源。也就是说，人不再主要写代码，人去写约束边界意图，还有实现。 规范呢，就成了人和 ai 之间的工程语言。本质上啊，就是面向规范文档编程。 它就像以前呢，从写会编升级到了写 c、 java 这些高级语言，以前直接和 ai 交流，现在呢，引入规范文档，我们和文档对话，文档又和 ai 对 话， 你可以理解为是以另一种形态的提示词工程 cd 呢，它有三个层次，分别是 spec first， 规范优先是先写规范，搞弄完就丢，适合一次性的任务和小功能。第二层是 spec anchor 规范，锚定 规范和代码一起长期的存在，重构扩展时呢，可以反复使用，这是目前最现实的一档。 第三层， space source 规范及原代码，规范就是唯一的真理，人只改规范不改代码， ai 呢，反复生成代码测试实现，你可以理解为人类从程序员呢，慢慢转变成了规范设计师。他重点分析了我之前视频发布过的 kiro's backy， 还有一个 test 的 工具， 想了解的可以去我主页看一看。但你会发现一个共性啊，它们都在做一件事，就是用工程结构去约束大模型的不稳定性。 我个人认为呢，规范系统编程啊，它本质上是一种工程的补丁，而不是对大模型能力的根本性的突破。它只要弥补三件事情。第一个就是大模型的幻觉问题，模型会自信的胡说八道，生成一些可能有 bug 或跑不通的代码。规范呢，它将一个人工护栏把幻觉压到最低。 而第二个是上下文的窗口受限，项目一大呢，它就会出现前后代码不一致的问题。那规范就相当于是外置的一个长期的记忆存储块，帮助我们 rec 解锁，保持稳定。 第三个就是推理的稳定性不足，同样 problem 不 同的结果，这大模型架构本身的随机性的问题， 我们的规范就相当于一个收敛的手段，让它的多样化缩到最小，稳定性最高。但问题是啊，这些呢，都不是根治，只是缓解。很多人会认为 s d d 它类似回到了瀑布模型，就是先写规范再实现。但作者强调了传统瀑布的问题是长反馈周期 和分离的设计实现。那 s d、 d 的 规划和实现并非远离反馈，而是一个短周期频繁迭代的规划实现循环， 核心的目标就是抵消 webcoding 带来的不稳定、不可靠的输出，而不是复刻旧有的模式。所以在作者看来啊， s c d 它不是瀑布的复活，而是对不良 ai 编程习惯的工程纠正。 这里呢，有一张四象线的图，横轴是问题的清晰度，纵轴呢是项目的规模。那针对于小项目目标清晰的，我们可以选用 webcoding 分媒编程，普通的 ai 编程就够了，那中等规模需求明确的，我们用 s、 d、 d 非常的有效，性价比很高。 那规模巨大的需求又不清晰，还高复杂度的，那 s、 d、 d 也帮不了太大的忙。为什么？因为这类问题啊，不只是现实问题，而是有认知、探索、建模的综合问题。在大模型能力没有出现质变之前，这类项目啊，依然必须高度地依赖人类。 还有一个现实问题啊，我发现现在几乎所有的 s、 d、 d 啊，他们都不会根据项目的复杂度自动地去选择合适的工作流，结果呢，就是小需求，他就用重度的 s、 d、 d 简单的更改呢，又套了一层又一层的规范，典型的过度工程化， 像杀鸡用牛刀大炮打蚊子。这不是 s、 d、 d 理论的问题啊，是当前工具缺乏自适应智能的问题。这个问题是很容易解，但又不好解， 因为你很难有指标去判断这个项目的需求清晰度和复杂度。这种呢，我的终极结论就是 s、 d、 d， 它不是 ai 编程的终点，而是 ai 能力不足阶段的一个工程拐杖的补充， 它在特定的条件下会非常的强，但在复杂不确定问题上啊，还是依然有限。真正的出路只有两条，一条就是大模型的能力出现质的飞跃。第二种就是开发出一种全新的 编程范式。在此之前呢，程序员还是非常重要的。关注我，带你了解更多有用的 ai 编程知识。

你有没有发现，这两年 ai 居然很喜欢发明新词？前两年大家还在说 prompt engineering， 后来又开始讲 context engineering， 到了最近又冒出来一个更新的词，叫做 harness engineering， 很多人一看就蒙了，哎，怎么又来一个 engineering？ 到底是新屏装旧旧，还是 ai 工程真的在升级？今天这期视频，我将带你把这三个词一次性彻底理清楚，它们分别解决的到底是什么问题。 你可以先记住一句总纲， front engineering 解决的是怎么说，而 context engineering 解决的是给它看什么，而这个 harness engineering 呢？解决的是让它在什么规则里头干活。这三个东西不是互相取代的关系，而是一层比一层更完整。我们先从最早的这个 front engineering 说起。 所谓的 front engineering， 本质就是你怎么给模型下指令，才能让它更好的完成任务。比如说，同样是让 ai 总结一篇文章，你如果只跟他说一句啊，帮我总结一下， 他可能就会给你带来一些啊，非常泛泛的一些废话。但如果你改成，哎，请用三句话总结这篇文章啊，第一句话讲核心的观点，第二句话讲关键的证据啊，第三句话讲他的局限性，你就会发现，哎，输出立刻规整了很多。 这个就是 prune engineering 的 最经典的思路，通过更清晰的任务描述、角色设定啊，输出格式，还有设为约束，去提升模型输出的质量。说在那个阶段，大家都在研究怎么写这个 prune， 比如说零样本，样本链式思维，结构化输出，还有节省格式约束等等等等。 很快大家就会发现一个问题，很多时候呢， ai 表现不好，不是因为你没有说清楚，而是他压根不知道。比如你用一个模型帮你回答公司内部的制度，那你不让他写的再漂亮也没有用，因为公司制度又不在他的预训练数据级 别。比如说，你再让他帮你改写一个项目里的 bug， 如果他根本就没有看到这个代码库的结构啊，没有看到日字，也没看到报错，那你不让他再精致，他也只能瞎猜对不对？ 于是行业开始从怎么提问转向怎么给模型提供对的上下文，而这就是 context engineering 上下文工程。 context engineering 的 核心呢，不再是去啊雕琢一句 prompt， 而是去设计在模型开始回答之前，它到底应该看到哪些信息， 比如说他要不要先解锁知识库啊，要不要拿到这个用户的历史对话，要不要看到工具返回的结果，要不要读代码文件等等等等。到了这一步， ai 已经不再是一个聊天的机器人，更像一个真正干活的人。而你要做的事情呢，也不只是提问，而是在给他准备工作资料。 而 anark 公司在之前讲解 a 件的时候，专门强调过这一点，高质量 a 件的关键就是给模型组织好上下文，让他在有限的上下文窗口里头看到最相关的信息， 而不是一股脑全给它塞进去。这一步已经比 prion 的 engineering 高级很多了，因为它开始接近真实的系统设计。但是问题又来了，就算你给了模型正确的上下文，它也未必就一定稳定。比如一个写代码的智能体，你把呀代码呀，文档啊，报错地址都给了它，它还是有可能改了这个 bug， 哎，然后又引入了一个新的 bug， 格式修好了，但测试又挂了，甚至啊，偷偷改到不该动的文件。你们有遇到这种情况吗？这个时候你会发现，光靠提示词和上下文已经够了，因为 ai 已经开始行动了，而他一旦开始行动，问题就从回答的好不好变成了这个系统到底可不可控。这就是最近很火的 harness engineering 要干的事。 honey 这个词呢，本来的意思是马具啊，将神的意思放到 ai 里，你可以把它理解为 front engineering， 是 你告诉马要往前走。而 context engineering 呢，则是你告诉马你要在哪个地图上走。而新出的这个 honey's engineering 呢，则是你怎样去控制并限制住这个马怎么走。 一句话说就是不是直接教 ai 怎么走，而是给他搭一个可控的工作环境。 open ai 在 二零二六年，也就前一个月谈的这个 codex 的 文章里讲的很清楚，现在的重点已经不只是 prompt， 而是为 agent 搭建一个完整的运行环境， 包括代码库，隔离测试文档啊，工具揭露等等等等，以及错误后的反馈闭环。这里非常推荐大家视频后可以看一下。这篇原文写的非常好，或者你们想听我的讲解，也可以在弹幕当中扣波。一总结一下，就是 prompt engineering， 像是你在给厨师下菜单。 而 context engineering 呢，像是你把食材啊，配方啊，厨房工具都准备好。而 harness engineering 呢，则是你连后厨这些制度啊都给它搭好了。比如说谁能进厨房啊，哪些菜必须经过质检啊，煤气超标了会不会报警，做坏了能不能自动回滚等等等等。所以你会发现，这三个 engineering 的 层级关系其实非常清楚。 on the engineering 是 指你研究怎么把任务说清楚。而 context engineering 呢，是你研究怎么把任务相关的信息准备齐。而 harness engineering 呢，是你研究怎么把 ai 放到一个有规则、有反馈、有约束的系统里持续工作。你会发现，越往后关注点越不在模型说什么，而是系统如何保证他别乱来， 他们不是谁取代谁，而是 ai 从会聊天走向会干活，再走向能稳定干活的三步净化。现在大家可以把你们的 ai 从会聊天走向会干活的三步啊写在公屏上。 好，如果这期视频对你理解的三个概念有帮助的话呢？记得点赞双击加关注，咱们下期视频见！

如果一个 ai 能连续写代码几小时，你最该担心的已经不是它会不会写组件儿了，而是它到底会不会规划，会不会验收，会不会在错的方向上越跑越远。在全站开发部分， anthtapiti 把前面的思路升级成三代理系统。 第一个是 planner， 它接收的不是超长 p r d， 而是一到四句话的简单需求，然后把它扩成完整产品规格。文章特别强调， planner 不 能一上来写得太死，尤其不要把细碎技术实现提前锁死，否则上游猜错一点，后面会层层传染。 所以它更关注产品上下文和高层技术方向，还会主动把 ai 功能织进产品设计里。第二个是 generator， 它不是一次性把全部东西糊出来，而是按 sprint 工作，一次拿一个 feature 去实现。 技术栈写得很具体，前端是 react 和 vite， 后端是 fast ipi。 数据库先 static， 后面再到 post script， 还用 git 做版本控制。每个 sprint 结束后，它会先自查，再交给 qa。 第三个是 evalerer， 他 用 playwrite mcp， 像真实用户一样点应用，不只是测 ui， 也测 api 和数据库状态。每个 sprint 都会按一套标准打分，覆盖产品深度、功能、视觉设计和代码质量。更狠的是，每个维度都有应域值，只要有一项没过，这个 sprint 就 算失败。 generator 必须带着详细问题继续改。这套系统还有一个非常实用的设计，叫 sprint contract。 每次开工前， generator 和 evalerer 先谈清楚这一轮什么算做完，怎么验收，哪些行为必须可测， 因为 planner 给的是高层 spec， 这一步相当于把产品意图翻译成可验证交付。通信方式也很朴素，就是通过文件来回写，一个 agent 写文件，另一个 agent 的 读文件在回复。这么做的好处是交接稳定，上下文清晰，也不容易因为一长串对话把真正的任务目标冲淡。 文章给了一个 retro game maker 的 对照实验，单 agent 版本跑了六小时，花了两百美元，成本超过二十倍， 但质量差距非常明显。单 agent 做出来的界面看着像回事，可一上手就暴露问题，布局浪费空间，操作流程不顺。最关键的是游戏根本玩不起来，实体显示了却不响应，输入 完整。 harness 那 边 planner 把一句话扩成了十六个功能，十个 sprint 的 规格，除了基础编辑和试玩，还加了动画、行为模板、音效、 ai 辅助、精灵生成和关卡设计，可分享导出链接。最终虽然也有一些产品直觉不够好的地方，比如流程提示还不够清楚， 但至少核心玩法是真的通了。更关键的是 evalererdrawbug 的 质量。文章举了几个例子，比如矩形填充工具，实际上没有正确触发填充逻辑，删除实体出生点的条件判断写错了。 put frames reorder 路由因为放在斜杠 frame id 之后，被 fast api 当成整数参数匹配，直接报四二二。这些都不是空泛批评，而是可以马上修的具体缺陷。不过 anthropic 后面没有停，在多加 agent 就 对了。这个结论上，作者开始反向做减法， 因为第一版 harness 太重太慢太贵。随着 opps 四点六发布，模型在长任务规划、代码审查和调试上的能力更强。于是他们先尝试去掉 sprint 结构，保留 planner 和 evaluator， 把 evaluator 改成整轮，结束后再做 qv。 这里文章给了一个很重要的判断， evaluator 不是 永远必须存在的固定配置，而是看任务是否超出当前模型单打独斗的可靠边界。落在边界内，它可能只是额外成本， 越过边界，它就有真实提升。新版 harness， 他 们拿浏览器内 daw， 也就是数字音频工作站来测，一句话，需求是用 web audio api 做一个全功能。 daw 整轮还是跑了大约三小时五十分，花了一百二十四点七零美元。 其中 planner 四点七分钟第一轮构建，两小时七分钟七十一点零八美元。后面又经过几轮 q a 和反攻， q a 依然抓到了关键问题。比如很多核心交互只是展示，不是真能拖动编 辑录音按钮是假的，没有麦克风采集音频效果可塑化，只是数字滑块，没有真正的图形化 eq 曲线。最后，作者的结论很克制， 模型更强，以后某些老的 scout 会过时，应该删掉。但这不代表 harness 不 重要，反而意味着你要持续重新判断，到底哪些结构还在提供增益，哪些只是历史包袱。 基于原文可推断，未来最有竞争力的 ai coding 系统，可能不是最会堆 agents 的， 而是最会根据模型待机变化动态调整编排复杂度的那一批。 如果你在做 agents 产品，这篇文章最值得抄的不是某个固定三代理模板，而是它背后的方法论。先看真实失败点，再加结构，模型升级以后，再把不再承重的结构砍掉。

继 token prompt 之后， ai 圈又来了一个没人能翻译的词，叫 harness。 harness 本来的意思是马具，用来控制马的方向和力量。就好像 ai 是 一匹很强但不听话的马， harness 让它不跑偏。 过去三年，其实我们经历了三次升级，分别是 prompt 工程怎么跟 ai 说话， context 工程是给 ai 看到什么？到现在二零二六年，重点又变了，叫 harness 工程是怎么让 ai 能稳定工作，可控可付现，可验证。 但是问题来了， harness 到底该怎么翻译呢？

最近啊，人工智能圈啊，又出大事了，又出来一个新名词叫哈尼斯印证理论， 翻译成中文呢，就是驾驭工程啊，这个驾驭呢，这个哈尼斯呢，实际上是马具的意思，我们如果把人工智能大模型比喻成啊，一匹啊，疯狂的啊，这个奔跑的野马，那这个哈尼斯这个驾驭呢，就是希望这匹野马呢能更好的为我们人类服务。 那说的这一块呢，如果大家感兴趣呢，可以花两分钟时间啊，听一下老李的讲解，我相信呢，会对关注人工智能的朋友会有非常非常大的启发和帮助， 那也可以点到收藏里这个关注李福通频道啊，后面慢慢的去学习。那说到这个工程呢，就是大模型呢，其实工程化呢，有三个阶段，第一个阶段就是二零二三年初大家提出的叫工程，英文是 boom boom 的 引流引流， 那这个提智词工程呢，实际上是帮助我们更好的去和人工智能交流，让人工智能呢，给出我们更好的答案。那这是第一个阶段哈提智词工程，但提智词工程有什么样的问题呢？就是我们问人工智能大模型的时候，虽然我们有一些方法框架， 但是呢，人工智能有一个巨大的缺点，就是你手头有些数据，有些知识呢，他可能没有，或者他永远不会有，这时候的话呢，当没有这些数据知识 做支持的时候呢，他有可能会胡说八道，因为他没有嘛，他不可能啊，去把你的真实数据抓过来去做啊，这种分析啊，被你想要的一个答案， 那怎么办呢？后来又发展第二阶段，我们管它叫 context 应用啊，中文翻译呢，叫上下文工程，那上下文工程呢，通过这种挂在外部的数据知识文档的方式呢？让人物智能大模型的换句啊，大大减少了，也就是说啊，你问他问题的时候啊，他更受控了， 他给的答案呢，更能符合你的要求了啊。这是第二个阶段，叫 context 验证认证，那 context 验证认证是不是也有一些问题呢？还是有一些不足的？我们现在大家都在养龙虾哈，实际上啊，我们的融智能呢，我们希望它能帮助我们啊，自动化的干活， 比如说每天我们可以啊，早上起来的时候收的啊，全球的关于啊，那个方方向的一些热点了啊，一些最新的事件啊，我们可以让融智能做这个活啊，当然也可以做很多很多啊，一些我们日常的一些琐碎的工作。 在这种情况下呢，融智能呢，我们都需要通过这种智能体工作流的方式啊，来去让他工作 智能提供的流，包括呢，随着这个人工智能我们和他交流更多呢，我们也希望他能够啊和更懂我们啊，给我们答案越来越好，让他自我进化。 那这时候的话呢，我们就需要同一个系统的视角啊，来去看待，来去设计人工智能，那系统的视角是什么呢？比如说我们刚才讲了，具体我们要设计一套流程， 然后我们还要挂在知识库啊，同时还给他很多很多相关那些规则约束啊，这个我们就管他叫哈尼斯，一零零也都说啊，我们让人工智能呢更能帮我们做事，从过去呢，可以交流啊，可以帮我们出的答案更准确啊，到现在呢，更能帮我们干活 啊。以上呢，就是我们讲的三个用智能大模型的工程化的一个发展的路径，总结下来，第一阶段叫 t 值词工程，第二个阶段呢，我们管它叫上下文工程，最后一个阶段我们管它叫驾驭工程，也就是刚才说的 harness engineering 啊，希望呢大家啊，听到我的讲解呢，又有一些收获啊，也希望关注李福农频道。后面呢，我会给大家解锁更多的人物智能啊，与我们的商业社会以及每个人的成长发展相关的一些话题啊，今天就分享到这，谢谢大家。