Harness开发实践教程

今天还是讲一下 hashcode， 嗯，昨天讲了 hashcode 在 agent 的 层面的控制力是全部由人控制的。然后今天讲一下在呃规范的加载上，它也是跟嗯，大家常用的这些工具是不太一样的。 比如说我们需要加载的很多代码规范，那通常的做法，比如在 open code 或 color code 里，我们直接把 p r d 在 一个三十年扔给大模型之后，大模型除了自己会去分析决策 要叫哪一个 agent 来工作以外，它还会自己去决策我当前做的这个开发任务，它要加载哪些 skill， 它是不是要加载？那这个其实也是呃大模型自己发挥的一个空间，在这个细节上哈尼斯 code 也把它控制住了。 对，因为呃这个跟我们那个哈尼斯 code 里面拆解代码规范的颗粒度是 相匹配的，那我们拆解颗粒度是按照呃很小的一个任务的属性，比如我写的是一个 map， 写的是一个 controller， 那 么 map 的 规范是什么？ controller 的 规范是什么？但是在 skill 里它一般不会做到这个颗粒度，它一般都是以现行的 呃规范去总结的。写 p r d 的是什么？然后写 java 的是什么？写 python 的是什么？那对，然后这么做。为什么这么做？因为我们在过程文件里已经这样，大模型在拆解任务的时候，把每一个最小颗粒的任务 匹配到了它需要用到的那个规范上，那我这一个任务写的都是 control， 那 我就只需要加载 control 的 这个规范就好了。那这样的话就保证了它的输入是最小范围且有效的。 但是如果它是加载一个 skill 的 话，那 skill 里面会有很多很多规范，第一是它加不加载是大模型自己控制的，第二是加载之后它要读的那个东西有很多跟当前这个任务不相关的内容。 对，这就是 hashcode 在 代码规范的加载上的一个机制，和这些常见的框架不一样的地方。

前两天， antropolis 实验室发布了一篇基于 hardest 工程的实战案例，今天我们就来扒一扒这篇文章，用大白话深入拆解这套让 cloud gold 化身超级开发团队的核心架构。 为什么普通 ai 写不出长代码？ a 社总结了两个致命的系统病，第一就是上下文焦虑症。随着开发任务推进，上下文窗口被历史对话和代码塞得越来越满。这时候模型会产生一种焦虑感，他觉得自己的内存快爆了， 于是开始强行收尾，导致项目直接烂尾。以前为了解决这个，大家会用上下文重置，每写完一个功能就强制清空记忆， 但这种方法交接调度极其复杂，延迟高的离谱。第二个病是盲目自信。如果你让一个 agent 写完代码或者做完设计，再问他做的怎么样，他大概率会把自己吹上天。 在有明确报错提示的后端代码里还好，但在前端设计这种缺乏绝对标准的主观领域，这就是灾难。界面到底好不好看， agent 永远倾向于给自己的作品打高分，其实效果一塌糊涂。既然单一 agent 不 能自查，那就给他找个死对头。 a 社借鉴了深层式对抗网络 j a n 的 思路，把系统分成了两个对立的角色，生尘器、干活评估器、挑刺。为了治好 ai 前端设计那股廉价的 ai 位， a 社给评估器定下了四条死规定，重点抓两样，第一是整体设计感，不能是东拼西凑的零件。 第二是原创性，只要出现类似白卡片配紫色渐变这种典型的 ai 偷懒套路，直接扣分打回。接下来是最硬核的环节，生成器写完静态代码后，评估器根本不看这些死代码。 a 社接入了 playwrite 这种自动化测试工具，直接在浏览器里把这个网页跑起来。评估器像真人一样去点击按钮截图看视觉效果，只要发现排版崩了或者交互不通，直接写出尖锐的批评打回去让生成器推翻重做。 这就把物理世界的验证逻辑强行塞给了 ai。 这套高压机制的效果极具惊人。在为荷兰艺术博物馆做网站的任务里， 前九轮 ai 一 直都在做一个四平八稳的暗黑风网页，但到了第十轮，在评估器的不断逼迫和挑刺下，神沉气直接推翻重来，硬生生做出了一个带透视效果的三 d 房间。艺术品全挂在墙上，用户点一下门就能在画廊里穿梭。 这种级别的创造力飞跃，使你写多长多复杂的单次提示词，都绝对无法深沉的前端的左右互搏。跑通后， a 社将其扩展到了全站开发，引进成了一套三体架构。第一个角色是规划师， 你可以理解成一个霸道的产品经理，你只需要给他一到四句的模糊需求，他就会自动扩写成一份宏大的产品规格说明书。这里有个小细节非常关键， a 社故意不让这个规划师去写太细的技术实现，因为怕他写错带偏。后续的开发， 它的核心任务是专注在产品逻辑和高级架构上，甚至主动往产品里塞一些 ai 特斯功能。第二个角色就是苦逼的开发工程师，生成器。为了克服我们最开始提到的上下文焦虑，生成器的工作方式被设计成了 sprint， 也就是冲刺模式。 他每次只认领一个功能，用 react 加 fast api 的 技术栈写完，并且系统还给他配备了 git， 让他可以像人类工程师一样进行版本控制。这样就把一个大任务拆解成了无数个不会让他焦虑的小任务。现在来到最精彩的一环，第三个角色，无情的铁面 q a 评估器。 在写任何代码之前，生成器和评估器必须先签订一份 sprint 合约，这相当于把丑话说在前面，双方先吵明白 到底测试通过的标准是什么？及格线画在哪里。代码写完后，停库器再次掏出 playwrite， 像真实用户一样，在跑起来的应用里点按钮，测接口，查数据库状态。只要有任何一项没有达到器约里规定的标准，直接打回重写，没有任何情面可讲。 这套架构到底有多强。 a 社给他输入了一句话，需求建一个包含观察编辑器、清零图编辑器和游玩模式的二 d 复古游戏制作器。如果只用单个 agent， 花了九美元二十分钟做出来的东西，布局崩坏，角色放上去根本动不了， 而是使用这套 harvest 架构。虽然花了二零零美元，耗时六小时，但他硬生生做出了一个包含音乐系统，内置 ai 帮画素材、物理引擎，基本正常的完整游戏引擎平台。 更恐怖的是，评估器在里面抓出了无数个深度的逻辑 bug， 比如画笔工具只在起点和终点生效，无法拖拽填充这种人类 qa 都不一定能发现的问题。然而这篇分享最硬核的洞察在最后，当你把这套系统着调的完美无缺时，底层模型自己升级了。 a 社在研发过程中发布了能力更强的 opus 四点六，这新模型长文本能力大幅增强，根本不怎么焦虑了，这时候怎么办？ a 社的理念是只在必要时增加复杂度。 于是在 v 二版本的 harness 中，他们大刀阔斧地砍掉了 spring 的 拆分，让 opus 四点六一口气写两个多小时，代码评估器也后置了，等整体完成后再进行。 q a 就 用这套简化后的架构 ai， 用将近四小时在浏览器里硬生生撸出来一个专业的 daw， 也就是我们说的编曲软件。 a 四的这次实战，给所有 ai 开发者指明了未来的方向，总结下来是三条核心素养， 第一，验证重于生成，把干活的和检查的分开，并且让检查的人拥有物理世界的交互能力，比如通过浏览器自动化去模拟真人操作，这是提升 a 值上限的杀手锏。 第二，不要迷信固定的脚手架。随着模型能力从 open 四点五进化到四点六， harness 框架必须做减法。以前为了弥补模型智商不足而做的那些复杂拐杖，在新模型下反而会成为拖累效率的累赘。 第三，寻找下一个边界。优秀的 ai 工程师未来的工作不再是天天写那些死板的 prompts， 而是要去观察模型在真实环境下的执行轨迹，识别它当下的能力边界在哪里， 然后用最小成本的脚手架去兜底他，逼迫他直到触达下一代更强 ai 的 边界。理解了这些，你就超越了百分之九十的传统 ai 使用者。

今天这期我们讲一个最近很火的概念，叫 harness engine， 如果说你最近在看 ai agent， 尤其是 coding agent， 你 会发现一个问题，很多产品它在演示的时候会说这个 agent 有 多么强，改出来的代码它在各方面的这个评分有多么的高 啊，一方面是和自己过去的这个参数比，再一个是和其他模型或者其他工具比，但是我们真的把这个工具放到日常开发的过程中，大家最担心的并不是它会不会写代码，因为这一部分已经是它自己的已有的能力了，而是我们更担心它会不会稳定可控的改代码。 今天我们讲的这个 hearthis engineering 这个概念呢，就是怎么把一个聪明的 agent 变成一个更靠谱的 agent。 很多人第一次用 coding agent 都会有一种感觉很惊喜，但是又很担心它乱改的，这种感觉 就是惊喜的在于他写代码的速度真的是比我们平常速度快太多了，有的时候可能我们要写半天的代码，他可能只需要花呃几十秒就能够生成出来，而且质量比我们自己写的要高。 那担心的一点呢在于他有的时候就像一个经验丰富的这个加固师写出来的代码，有的时候呢他就像一个实习生，而且嗯写出来的东西呢，也不能够完全的按照需求去做， 他可能一下子帮你改对了很多东西，也可能在你没有注意的时候，顺手把不该改的地方也一起改了，要不是有 get 管理，我们可能都发现不了，就会埋下很大的这个隐患。所以说真正的问题不是他有没有能力，而是他做事的时候有没有边界，有没有纠错的机制。你可以把 harness engine 理解成为围绕着 ai agent 搭建的一套工程化的控制系统， 它其实不是一个插件，它也不是一个提示词，它更像是一套制度。嗯，也可以把它理解为我们的操作系统，嗯，可以是一套确保 agent 的 不只是能够做事，而且能够稳定的做对事情的方法。 这里最关键的几个词是约束、反馈、流程和迭代。也就是说，我们不只是关心 agent 输出了什么，我们还关心他怎么输出，怎么被检查，怎么被纠错，然后怎么越来越稳。 为什么 harness 这么重要？ ai 一 诊现在已经融入到了我们的日常工作了，它不再是呃辅助我们了，甚至它在写代码方面已经占据了我们全部代码的百分之九十几以上。 它会帮我们改代码，呃，帮我们改 bug， 做 ppt， 也可能会执行指令，创建个文件，生成个文档什么的，这些能力都已经成为了现实，我们目前更关心的是能不能放心的交给 ai 去做，这就是 harness 存在的意义。 如果说类比一下，我觉得最好的理解方式就是自动驾驶大模型呢，就像一个发动机， agent 就 像驾驶系统，而 harness engine 就 像整套的安全系统， 它不只是让这个车能跑，而是让车知道什么时候应该减速了，什么时候应该停车，什么时候路线错了，我们要重新规划路线，然后出了事故之后呢？还要呃进行复盘，并且更新规则。所以说 harness 的 作用不是给 agent 增加麻烦的，而是防止它在错误的这种 它过于自由的这样一个空间里啊，一路狂奔，不受我们的控制。如果你只记住这一页，其实你就已经抓住这个概念的主体了。 harley's engine 通常可以拆分为五部分。第一部分呢，就是约束机制，告诉 e 诊断什么能做，什么不能做。第二部分呢，就是反馈回路，告诉 e 诊断这次做的到底对不对。 第三个呢，就是工作流控制，规定任务应该按什么顺序推进。那第四个呢，就是持续的改进循环，让系统把这次的经验带到下一次。 第五个呢，就是观测与治理，保证整个过程看得见，说得清，出了问题能够复盘。约束机制是低层护栏。很多人一提到 ai 智能，就只想到让他能够更自主更自由的进行做事情。但是真正的进入到了工程的环境，第一步往往反而是先收权，你要告诉他哪些文件不能动， 哪些命令不能直接跑，哪些操作必须由人确认之后才能够进行操作，然后哪些代码风格和业务的规则必须遵守。 因为如果说没有边界的自主，那其实不能叫智能，很多时候会带来很大的事故和隐患。只有约束还不够，因为 a 阵他真正开始执行之后，你还得让他知道自己做的到底对不对。这就是反馈回路， 测试构建结果，运行日记截图，人类去 review。 这些呢，都是反馈源。若说没有这些反馈， agent 很 容易出现一种错觉，他觉得他自己已经完成了，但实际上呢，他可能只是生成了一堆看起来像正确答案的东西。所以说反馈回流的价值呢，就是让 agent 不 只是啊往前冲啊，一直就是在做，但是 不知道自己可能已经出错了啊。就是反馈回流的价值，就能够在这种情况下，就在出错的时候能够及时把这个 agent 拉回来。 真正成熟的 a 种呢？他不是上来就改变了，他通常会先理解任务，再写计划，然后再决定改哪里，然后执行，再验证，再根据结果修正，最后把经验沉淀下来。这一步特别重要，因为如果说系统每次都从零开始，那他其实只是一个重复犯错的高性能的工具。 只有当他能够把成功的经验和失败的教训逐步的沉淀成为规则、模板， skill， 或者说一些检查项，那这个系统才会越来越稳。所以说 harness engine 它是一个持续变强的一个闭环的系统。 如果说没有 harsh， 最典型的问题不是他完全不会做，而是他会在一些我们看起来可能没有那么夸张，但是代价很高的地方翻车。比如说改了不该改的文件，修了一个 bug， 又引入了新的 bug， 本地看着没问题，但是一上线就会各种层出不穷的这种线上 bug 出现，甚至同样的错误下周还会再犯一次。 所以说很多人认为自己遇到的是模型不稳定所导致的。但其实更准确的说是这个 a 阵呢，缺少一套完整的工程化的护栏，问题不一定出在大模型这个大脑层面。很多时候呢，在制度方面，也就是系统的这个角度也是我们要考虑的。 对 harness 的 认识普遍存在三种误区，一是认为只要 t 值词写的足够好，就不需要 harness， 实际 t 值词是没有办法替代测试审批啊，还有后续的这些流程的，这些还是要交给 harness 做。还有一种误区呢，认为 harness 会让 agent 变慢，就是短期多规划几步，是为了更大限度地向大局最优解去优化。 还有人觉得我们团队这几个人不需要 harness， 这个东西太重了。其实呢，不管团队大小，都需要在整体上有统一的把控和规划，才能够减少失误。 harness engine 它本质上就是一套围绕着 ai agent 的 可控系统设计，它关心的是边界、验证、流程、复盘还有进化。 如果说你真的想把 ai agent 用进日常的开发，甚至未来放进团队流程，那你迟早都要会从怎么让他更能干这个问题，走到怎么让他更可靠这个问题上。而从这一刻开始，你思考的其实就不只是 t s 工程了，而是 harness 跟着你，我是不吃辣。 chris， 如果说这期视频对你有用，记得点赞关注，我们下期再见！

最近在研究这个多 agent 的 编排，那前两天阿斯特雷克发布了一篇关于他们是怎么在这种长城编程当中使用这种哈里斯 design 的 一篇博贺文章，我觉得还是蛮值得一看的啊，它也解决了我的很多的疑问，今天带大家一起去看一看。 先讲一下这篇文章到底在讨论什么，他讨论的是一个如何在人尽可能少的干预下，让模型自主去建构一个高质量完整的软件。相信这也是大家会关心那个问题。现在的单一的 agent， 他 是做不到长时间的工作的。大家如果有实践的经验，你会发现，其实如果你只使用单 agent 去实现你的程序，那个结果往往是 不够好的。而通过这种多 i 阶的 highness 的 编排，可以有机会去拿到一个远超模型的精准水平的一个结果。我们先去看一下他的案例，我觉得是最直观的，他想去做一个博物馆的网站， 那一开始他的这个网站其实也是一个非常常规的，我们也都能经常看到的这种网站风格。 但是经过十轮的这种反馈和迭代之后，这个 ai 却生成了一个这样的带有交互的博物馆式的这种网站，我觉得从结果来看还是蛮惊艳的。这里面 acropine 给到的经验是，就代理在给自己工作打分的时候，总是倾向于给到一个比较积极的评价， 即使说这个结果质量显然是比较平庸的，但是模型自身是没有这个分辨能力的，所以为了解决这个问题，他会去引入一个评判者的角色。一旦存在这种外部的反馈， 模型就会有一个非常具体的一个迭代的方向。对于这种设计的评价往往是一个比较主观的评价，所以 arabic 是 给到了几个更加细分的评价的维度，比如说设计的质量，你的设计是不是一个连贯的整体 设计的原创性，你的整个的模板和布局是不是有自己的思考，还是说直接是用别人的？像我们常见的那种白色卡片，紫色渐变的这样的一个 ai 的 生成是会直接被评判者给否掉的， 以及它的设计实现和它的功能性。它会从这四个维度给干活的模型去打分， 负责干活的那个 agent 干完活会把他的结果交给评判的那个 agent， 他 们会不断的这样子交互和迭代，最终能很有效的去提升整个模型的一个结果。 他后面又尝试了一个更复杂的一个项目，他只给了一个提示词，就是创建一个具有关卡编辑器、精灵编辑器实体行为的一个二 d 的 复古游戏的制作工具。 如果你没有使用这种 door agent 编排的方式，整个的页面效果是长成这个样子的，它只有几个很基础的模块，在验收的时候也发现流程其实跑不通的，但如果做了这种 door agent 编排之后， 它的整个的结构就会非常的丰富，也能够完整的跑通它的核心功能。它最后还给了一个价格的对比，如果说你是 dan agent， 执行它的 持续时间只要二十分钟，花费九美元。但如果说你想有一个更加完整，更加质量高的交付，它能持续跑上六个小时，价格也花了两百块钱， 虽然价格是多了不少，但这个输出的质量也确实是肉眼可见的提升了非常多。我觉得特别是对生产环境下，这种多 agent 编排的技巧是非常值得去学习的。这篇文章里面还有非常多的细节，比如说他们这个多 agent 之间是如何进行通信的， 如何通过文件系统去进行交付的，以及他们怎么看模型的能力的迭代和这种 harness engineering 的 这种编排之间的关系。 如果大家感兴趣的，我是会推荐大家去看看原文的。好，今天就分享到这，我是李普，关注我，获取更多一手 ai 思考，我们下期见。

像 bmad 或 spec kit 或 open spec 这样的框架允许您在实际开发开始之前创建结构化需求，这样 agent 就 不会孤立的循环，而是按照预定义计划工作。所以这些框架解决了 agent 的 问题， 缩小要完成的工作范围。但在外部验证之外，实际上是 agent 在 自我评估期工作，所以在这种背景下， agent 具备了这些这些方法。 episodic 观察到，当智能体执行这类任务时，存在两种常见的失效模式，束缚 harness 和 ralph wiggle 循环。 一种是所谓的情境焦虑。当上下文窗口填满时，模型不仅失去了连贯性，他们实际上改变了他们的行为。他们开始过早的结束谈话，他们匆忙通过步骤并宣布事情已经完成。 当他们还没有真正完成的时候，你自己可能也注意到了，如果你和大模型在很长一段时间内的单个上下文窗口中聊天，上下文最终会变得越来越短。 有一种技术叫做上下纹压缩，实际绘画线层被压缩并总结留出更多的空间，更多可用上下纹空间。 但 ansropik 发现及时使用上下纹压缩，类似于 sonya 四点五这类模型仍然表现出上下纹焦虑并试图提前完成。原因是你并不是从空白上下纹开始的。这就是为什么他们去年十一月的原始解决方案是上下纹重置。

harness 运行系统处理的是模型外部的一整套工程设计，它不是在叫模型怎么回答，而是设计模型怎么工作。你可以把它理解为一辆车的方向盘、刹车、车道边界维护计划和警示灯等完整系统。 综合多家头部 ai 公司如 antelphi、 open ai、 google 等的实践视频，将一个成熟的 harness 系统完整地归纳为六大核心模块。一、 上下文工程与知识管理基础层这是最底层的信息处理模块，确保模型能获取并消化必要的知识项目。指令文件 a 阵启动时需要读取的全区文档，例如 a 阵按 d 或 cloud 按 d。 动态上下文注入，从日制 指标或追踪信息中实时获取并注入当前需要的数据。上下文隔离，将不同的子任务在隔离的上下文窗口中运行，避免信息干扰。 上下文压缩。当模型的上下文窗口即将填满时，自动丢弃或摘要无关信息。二、工具编排与全线设计决定 a 着你能用什么，不能用什么。强调约束及生产力精心策划的精简工具集，移除多余的选项，因为工具过多会导致模型困惑和容易调用。 系统权限与集成，包括 mark 布协议集成、文件系统访问管理以及沙箱隔离机制，确保 agent 在 一个安全的与生产环境隔离的环境中运行。三、 验证机制与约束核心特征这是 harness 区别于简单脚手架 sky fold 的 关键，它不完全依赖大模型自身的判断。确定型约束，引入传统的软件工程规则，如自定义的 linter 代码检查工具结构化测试、 pre kamehux、 预提交钩子等硬性规则生成与评估分离架构上设立独立的评估器 a 阵。一八六 a 的 verifier 专门负责用交互式工具如 playrite 进行验证和打分，防止模型盲目自信。自动审查循环， 强制 a 阵在本地审查自己的更改或请求其他 a 阵审查，并在循环中迭代，直到通过。 四、状态管理与记忆持续性用于解决大模型本身无状态，每次启动都是从零开始带来的长任务挑战。外部化记忆将进度追踪、文件结构化、功能、需求清单、增量、 get 提交记录等外部制品作为持久化记忆。 每次塞肾启动前，先从中重建上下文检查点与恢复机制，确保任务中断后可以从特定节点恢复。 可观测性与反馈闭环负责监控系统的运行健康度，并促进自我进化。监控与检测包括对 agent 执行路径的追踪、输出质量的分级以及异常检测。 反馈闭环能够将 a 针在生产环境中发生的失败模式精准追溯到 harsh 的 具体缺陷上，从而驱动系统的持续改进。料，人类接管与生命周期管理设定 ai 的 边界和应急余案。关键决策点暂停，当涉及高风险操作，如删除数据库、执行扣费、 发送客户邮件时，系统必须暂停并交由人类确认。生命周期控制包含失败重视机制、向上级人类或其他系统的升级汇报路径，以及完整的生命周期勾子。 life cycle hooks。 总结来说， 这六大模块组合在一起，就形成了一个能够解决任务拆解、上下文管理工具编排全线设定状态交接结果验证和失败恢复的完整运行环境。

如果一个 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 产品，这篇文章最值得抄的不是某个固定三代理模板，而是它背后的方法论。先看真实失败点，再加结构，模型升级以后，再把不再承重的结构砍掉。

港大最新开源 open harness， 四天冲上八千星！ open harness 最吸引我的是它对 agent 基础设施的极简重构。港大团队将 call 五十一万行繁杂的 ts 代码，精简为仅一点一万行的纯拍脏实线， 体积缩小四十四倍，却保留了百分之九十八的核心工具链。它彻底解决了黑核痛点，采用模块化子系统架构 engine、 turbo hux memory 等，让 agent 的 每一个决策环节都清晰可见，可定制内置四十三个工程化工具，完美兼容本地模型。 最实用的是它的安全审批与任务分发机制，非常适合在个人开发或团队协助场景下，作为轻量级的 ai agent 底座进行二次开发。感兴趣的朋友欢迎评论区交流。

嘿，朋友们，欢迎回来。今天呢，我们来聊一个说实话，可能会让很多软件工程师感到焦虑，但又无比兴奋的话题。 想象一下，当 ai 已经能自己写出一百万行代码的时候，那我们，我们这些工程师未来到底该干什么呢？这可不是危言耸听，咱们会发现，未来的核心竞争力可能真的不再是疯狂敲代码了，而是转变为设计一套精巧的系统，去驾驭这些强大的 ai。 准备好了吗？咱们这就开始 好，今天咱们的思路是这样的，首先呢，我们会从一个超级震撼的事实开始，看看现在的软件开发已经变天到什么程度了。 然后我们会引入一个特别关键的概念，叫驾驭工程，也就是给 ai 套上江生。接着咱们会聊点实际的，看看这个江生具体要怎么设计。最后也是大家最关心的，咱们一起来揭晓，在这个新世界里，攻城着新角色到底是什么 好。第一部分，从编码到引导，你可能会觉得这不就是工具变好用了，效率高了点吗？哎，别急，这可远远不只是效率提升这么简单，这根本就是一场游戏规则的改变，一个真实的实验已经证明了这一点。 你看看这个来自 open ai 的 一句话，简直是识破天经。他们搞了个实验，从头到尾交付了一个内部软件产品，整个过程你猜怎么着？没有一行代码是人写的，真的一行都没有， 这听起来就像科幻电影里的情节对吧？但它确确实实的发生了。这数字有多夸张呢？你想象一下，就三个人，花了五个月的时间，居然就让 ai 智能体吐出来一个将近一百万行代码的系统， 这是什么概念？平均下来等于每个人每天都要搞定三个以上的大功能开发，这根本就不是什么生产力提升了。朋友们，这简直就是一场生产力的大爆炸。但是等等能力这么强，一个很现实的问题就来了，我们能信得过他吗？ 这就产生了一场所谓的信任危机。你想，这些大模型它本身就有点像个黑箱，结果不是百分之百确定的，它又不像我们一样真正理解这个项目的来龙去脉。它其实并不懂代码的意义，只是在玩符号游戏。 那它写出来的东西，我们怎么敢直接用呢？那这个问题怎么解决呢？总不能烟也费时吧？ 答案就在咱们的第二部分，我们得给这些 ai 智能体套上一副江生，嗯，没错，就是江生。这是一种全新的思维模型，教我们怎么跟 ai 一 起干活，既要利用它的强大力量，又要能牢牢地控制住它。 这个理念就叫做驾驭工程。他的核心公式特别好理解，一个能干活的智能体，等于那个大模型本身，再加上我们为他量身打造的这套江绳。 所以啊，这个江绳就是我们围绕着模型件的所有东西，他就像一个教练和裁判的集合体，负责引导、限制甚至纠正模型的行为。 那么这副浆绳具体长什么样呢？它主要由两部分组成，一部分叫引导，你可以把它想象成脑裆力图， 它是在 ai 动工之前就告诉它你应该往这边走。另一部分呢，叫限喘气，这个更像是质检员，它是在 ai 杠完火之后来检查结果，看看有没有问题，甚至帮它自己改错。 这些控制手段又可以细分成两种，第一种叫计算型，特点就是快、准、狠，结果是确定的，比如我们天天写的单元测试、代码格式检查什么的就是这种。 第二种呢，叫推断型，这个就高级了，它会用另一个 ai 来做裁判，去从语义上判断代码写得好不好。这种方法呢，能力更强，但自然也更慢，成本也更高。 好，理论铺垫的差不多了，那光说不练假把式，咱们接下来进入第三部分，看看在实际工作中，这套僵绳和反馈回路到底是怎么设计和应用的。 咱们来看几个特别具体的例子。比如说想让 ai 遵守我们的编码规范，我们可以在动工前用一个叫 a g s 点 m d 的 文件，就用大白话告诉它规则，这就是一种前馈引导。 那等它写完代码之后呢？我们可以用自动化的架构测试，比如 arch unit， 来检查它有没有把模块之间的依赖关系搞乱，这就是一种反馈。馋传 你看，一个是在事前引导，一个是在事后检查，一个柔性，一个刚性，这么一组合，一个有效的控制系统就有了。 在 openai 的 实验里，他们发现了一个可以说是铁的定律，代码仓库必须是唯一的信息来源。什么意思呢？就是说，如果一个知识点，一个规则只是存在于咱们的聊天记录里，某个零散的文档里， 甚至只存在于某个资深工程师脑子里，那对不起，对于 ai 来说，它就等于不存在。所以代码仓库本身必须成为那张唯一的、最权威的地图。 所以你看，我们的工作就变了。我们要做的就是把这个代码仓库从一个冷冰冰的代码存放处，改造成一个对 ai 极其友好的知识库。 这个思路很重要，别扔给他一本厚的、像字典一样的说明书，而是给他一张清晰的地图。 比如说，用一个 a、 g、 n、 s、 m、 d 文件当做地图的入口或者说目录。然后呢，把所有的知识都结构化地放在 doc 目录里，甚至我们可以用专门的 ai 文档原定来自动维护这些文档，保证它们永远不会过时。 open ai 是 怎么执行这些规则的呢？你看这张图，它们用了一个非常严格的分层架构， 从类型配置一直到界面依赖关系，只能从上往下走，单向流动，绝对不允许下面的层反过来调用。上面的这种规矩啊，对我们人类开发者来说，可能觉得尤连四版太不灵活了， 但你猜怎么着啊？对于 ai 智能体来说，正是这种清晰的、毫无含糊的约束，才给了他们快速、可靠工作的空间。所以说，在这里约束反而创造了自由。 好了，听到这儿，我猜你心里肯定在犯嘀咕了。如果写代码、写测试，甚至连遵守架构这种事 ai 都能自己搞定，那我们这些人类工程师究竟还能干点啥？这问题问到点子上了， 这不就来到了我们今天最核心的部分了，工程师的角色正在经历一次根本性的转变。用一个比喻来说就是，我们不再是那个亲手砌每一块砖的工人了，而是成为了整个宏伟建筑的总设计师。 没错，我们新的工作重心已经不再是竹自足的敲代码了，而是去设计一个环境、一个系统，能让 ai 在 里面高效可靠的工作。 我们的注意力从具体的代码实现转移到了更高维度的系统设计、架构、决策，以及去寻找那些能够撬动 ai 能力的杠杆点。 我们可以这么来理解这个转变。你看一个有经验的工程师，他脑子里其实有一套自己的僵硬，这套僵硬是隐性的，是靠他的经验、技术品位，还有对业务的理解形成的。 但 ai 不 懂这些呀，他需要的是一套显性的被写成代码的僵硬。所以我们工程师的新工作，在很大程度上就是把我们脑子里那套隐性的东西翻译成 ai 能看懂的显性规则。 所以未来的工程师职位描述可能会是这样的，第一，你要去引导 ai 通过不断迭代你设计的那套将生来完成。第二，你要把团队里那些约定俗成的惯例，那些所谓的代码品位给外化成自动化的检查器和测试。 第三，你要去设计那些精巧的反馈回路，让 ai 能自己发现问题，自己修正。最后，你还要像一个城市规划师一样去治理整个系统，防止它慢慢变得混乱不堪。你的核心价值在于指导人和机器的注意力投向最有价值的地方。 openai 团队的这句话可以说是对未来软件工程的最好总结了。他们说，现在最难的挑战已经变成了如何去设计环境、反馈回路和控制系统。 你发现了吧，软件工程的前线已经转移了，最硬核、最有价值的工作不再是实现某个具体的功能，而是这种更高维度的系统设计能力。 最后留给大家一个问题，我觉得特别值得思考，在一个 ai 写代码的世界里，如果你设计的那些 sensor 从来都没有报警，一片岁月静好，这到底意味着 ai 的 工作纸料真的完美无瑕呢？还是说你设计的这套检测机制本身就已经不够用了呢？ 这个问题可能就是下一代工程师每天都要面对的核心挑战。好了，今天就聊到这里，感谢收看！

ai 圈最反直觉的真相来了，模型一行没换，性能却能直接从三十名开外冲进前五，这就是最近 agent 圈最火的 harness engineering。 很多人以为 harness engineering 只是给 ai 多加几条约束，其实完全不是这么简单。 lanchin the coding agent 就是 一个典型案例，它们没换底层模型，只改了系统提示、工具配置和中间箭钩子，成绩却一路逆袭。 harness 这个词本意其实就是马具，比如江省和马鞍。 这个比喻特别好懂。模型像一匹猎马，强大跑得快，但它自己不知道该往哪走。工程师像骑手， harness 像连接骑手和马的控制系统，负责方向、边界和纠错。很多人会把它和提示词工程、上下文工程混在一起， 其实一句话就能分清。提示词工程是在劝 ai 听话，上下文工程是在管给 ai 看什么， 而 harness 工程是在管系统预防什么、修复什么、测量什么。如果把 harness engineering 拆开看，你不用背复杂架构，记住六个关键词就够了。它们分别是，上下文架构、架构约束、自验证循环、上下文隔离、伤治理和可拆卸性。 这六层加在一起，才构成一个能稳定跑起来的 agent 系统。前面三层解决的是 ai 看什么，怎么做怎么验。 上下文架构强调按需加载，不给 ai 一 次塞进百科全书。架构约束把规则写进工具， 自验证循环则要求他退出前必须校验，失败就重新规划。后面三层解决的是系统长期运行时怎么不失控。上下文隔离，让多个 agent 各干各的，不被彼此污染。 商治理负责清理过时文档和漂移信息，可拆卸性则保证模型升级后，旧模块可以随时删除和替换。 harness 最大的价值在于它的投入是复利生效的。今天补上一条规则，后面所有绘画都能少犯一次错， 但也别过度工程化，只需要盯住 ai 已经犯过的错误，逐步把这些错误工程化消灭掉。现在你应该能看懂 harness engineering 了。如果你想继续往下学， 下一步不是继续背概念，而是把自己项目里 ai 反复犯的错一条条找出来。评论区扣。学会了，下一期我就接着讲怎么从零搭一套可落地的 harness。

在硅谷，最近最火的概念不是 agent， 而是 harness engineering。 这并非什么全新的概念，而是意味着 ai 的 发展已经到了一个全新的阶段，真正能空城化落地的阶段。如果做过 agent 的 开发，那么想必都会遇到这样的问题，为什么 demo 演示时效果惊艳 一上，生产环境就会出现各种各样稳定性的问题？这正是 harness 要解决的核心痛点。首先我们理清相关概念，一个完整的 ai 系统可以分为三层， 第一层是模型层，比如 gpt 这样的大模型，是 ai 系统的底层基础。第二层是框架层， 比如 agent sdk 这样的工具，负责把模型与应用工具连接起来，而最上层的 hannis 正是 hannis 系统的核心关键。那么 hannis 到底是什么？简单来说，如果把模型比作汽车引擎，那么 hannis 就是 汽车的其他全部配套系统。引擎再强大，如果汽车本身不行， 一样跑不起来。所以 hans 的 核心作用就是为 ai 构建稳定的工作环境，设计规范的执行流程，建立完善的运行规则以及配套的验证机制。他不负责直接回答问题，而是专注于 ai 的 一系列自我管理工作，比如提示词的结构化管理、工具调用的稳定性控制、 任务生命周期的把控，以及上下文与记忆的高效管理。 harness engineering 之所以变得事关重要，核心原因是当前 ai 发展的瓶颈已经不再是模型够不够强大，而是长任务执行的稳定性不足。 一个真正可用的 a n 的 系统，可能涉及五十多次工具调用、多轮上下文压缩以及跨场景的状态延续，而问题常常就出在这个过程中， 上下文容易丢失，执行状态容易中断，工具调用频繁，这也是很多人 demo 表现不错，一上生产环境就虚脱的根本原因。因此， harness engineering 本质上就是要解决这一些的问题，核心围绕三件事情展开。第一是持续的任务执行能力。 传统的模型调用是一次性请求返回的闭环，而 agent 是 长流程任务必须实现，中断后可恢复， 出错后可重试，无需从头再来。这也是如今很多团队采用 tempro 或 long graph 等工具，将 ai 任务当做工作流系统来运行的原因。 第二是完善的记忆架构。很多人误以为向量数据库就是 ai 的 全部记忆，其实这远远不够。一个可用的 a 境至少包括三层记忆，记录过去和当下正在发生的事情，存储自身掌握的知识，明确具体的执行方法。缺少这三层记忆， ai 只能临时发挥，无法实现持续进化。 第三是科学的目标与状态管理。普通 ai 是 被动响应，问一句答一句，而 agent 是 主动执行任务，具备明确的目标、进度和计划。因此必须要有一套完整的系统来管理当前目标执行进度、卡点解决方案以及是否需要人工介入。还有一个很多人容易忽略的问题， 为什么 ai 在 任务第十步还能正常运行，到了第五十步就会崩掉？这背后是一个典型的系统问题，上下文退化。随着任务流程不断变长，上下文不断被压缩，关键细节不断丢失，进而导致决策质量下降，这并非单纯优化 prompt 就能解决，而是需要从系统设计层面入手。因此，我们能够看到一个非常明显的行业趋势，过去大家都在卷提词词工程，而现在行业重心已经逐步变为上下文工程和 harness engineering。 最后总结一句， ai 的 上限由模型决定，但 ai 的 可用性由 harness 决定。 如果你是开发者或创业者，现在要思考的问题不是我该有哪个模型，而是我是否拥有一套真正能让 ai 稳定运行的系统，这正是 harness engineering 的 核心价值所在。

第一集我们聊了这个实验多疯狂，第二集拆解了上下文和约束，但还差最关键的一环，如果 agent 看不见自己写的代码跑起来什么样，他就只能盲写。这就像一个画家闭着眼睛画画。今天的主题是给 agent 装上眼睛。 实践三的名字叫让一切对 agent 可读。这里的一切指的不只是代码，而是运行中的应用本身。 想象一下， agent 每天提交三四个 pr， 你 来得及每个都手动点开页面测一遍吗？来不及的，所以唯一的出路是让 agent 自己去测。 他们的做法非常硬核，直接把 chrome devtools protocol 接近了。 agent 的 运行时， 每一个代码变更都会启动一个独立的应用实体，独立的 work tree， 独立的进程。然后 agent 通过 devtools 协议连上去，它能看到页面的 d o m， 能截图，能点击按钮，能填表单。 它可以复现一个 bug， 修复它，然后自己验证修复是否正确。整个过程可以持续数小时，没有人类参与。 三个角色登场。 codex 是 导演，应用实力是演员。 chrome devtools 是 摄像机， codex 先切分支，启动应用，每个任务一个隔离环境，互不干扰。然后连上 devtools， 打开页面，拿到 d o m 结构快照，相当于 agent 睁开了眼睛。 接下来 agent 分 析页面，点击交互截图，对比验证结果。一个完整的端到端测试循环，全程自动， 光能看到 ui 还不够，代码在后端跑的时候，日制性能指标列录追踪这些信号， agent 也需要能看到它们。为此搭了一套完整的可观测性系统。 应用产生三种信号，日制指标追踪所有信号通过 vector 散出到三个 victoria 组建里。日制指标追踪各一个， 每个组件都暴露查询接口， log ql 查网址， prom ql 查指标， trace ql 查分布式追踪。 重点来了， codex 能同时查三种信号，跨日制指标和追踪做推理。这意味着什么？意味着你可以给他这样的 prompt， 让服务的冷启动时间降到八百毫秒以内。然后 agent 自己去改代码，自己测量，自己验证， 提交 pr， 重启应用，重跑测试，再查指标。不够快，继续优化。够了，收工，一个完整的反馈循环。这不是外部抠钉，这是有测量有数据的工程。 接下来是一个很多人会忽略的问题。 agent 的 写代码很快没错，但快就意味着垃圾也产生得快， agent 会产生伤，代码风格不一致，命名混乱，死，代码堆积，这些都是高吞吐量的副产品。就像一个城市越繁荣，垃圾产生的越多。 早期，它们每个周五都在做人工清理，一整天什么新功能都不写，全在收拾 agent 的 烂摊子。 后来他们想明白了，清理工作也应该交给 agent。 于是他们设了一批后台， agent 按固定频率运行，自动扫描代码库，对比黄金标准，开重构 pr。 这里面最优雅的地方是清理速度和代码生成量是同步扩展的， agent 写得越多，清理 agent 也跑得越多，不依赖人的时间。最后一个实践，也是最有意思的一个， agent 给 agent 做 code review， 他 们给这个流程起了个名字，叫 ralph wigem。 循环 第一步， codex 先审查自己的代码，就像你写完一篇文章，先自己通读一遍， 然后他请求其他 agents 来审，有的在本地跑，有的在云端跑，多个视角交叉审查，收到反馈之后， codex 自己修改迭代，一直循环，直到所有 agent 审查者都通过。 只有那些真正需要品位和判断的问题，比如产品方向、架构取舍，才会上报给人类日常的代码质量， agent 自己搞定。 与此配套的是一个看起来很大胆的合并策略，最小化阻设 p r 不 需要在 review 队列里等三天。 pr 生命周期极短，发现问题不用回滚，直接开一个新的 pr 来修测试，偶尔失败重跑就好了。不要因为一个 flaky test 堵塞整个流水线。 但这里有一个大前提，这套做法只在你有强大的架构护栏的时候才能用。没有 linter， 没有分层约束，没有自动化测试，这种快速合并就是在玩火。有了这些护栏呢，它就是一个巨大的吞吐量成数。 讲完五个实践，最后来看看支撑这一切的底层架构， agent 循环。这个循环是整个体系的心脏， 用户也就是工程师唯一要做的事情就是发一个 prompt， 比如给 dashboard 加一个搜索框，就这一步，后面全是自动的 response api， 把 prompt 发给模型，模型思考之后返回要执行的 shell 命令， 命令在沙盒化的运行时，容器里执行，执行结果 s t， o， d 和 c o r 反馈回来，然后模型再响再执行这个循环一直转，直到任务完成。 agent 循环里还有一个很酷的机制叫 skills， 模块化的能力组建 agent 遇到特定任务时，可以调用对应的 skill 来处理。来看 skill 的 解析流程。 response api 连接三个后端， registry 存储 skill 的 名字和描述。 bundle storage 保存打包好的代码。 container runtime 负责执行 模型，通过 command output 循环来调用 skill 执行结果，从容器返回 api。 skills 是 模块化的，隔离的，可以像乐高积木一样组合。 好了，三集的内容到这里就全部讲完了。最后来做一个总结，不管你用的是 cursor， cloud， code， copilot 还是 codex， 底层原则是完全一样的。 第一，你的仓库就是你的 prompt， 那 些文档、目录、结构、命名、规范，它们不只是给人看的，从今天起，它们就是给 agent 的 指令。 第二， linter 就是 老师，把报错信息写得像一个耐心的导师，告诉 agent 错在哪，为什么错怎么改。 第三，可观测性是超能力，如果 agent 能查日记，查指标、查追踪，它就能自己调试，自己优化，自己验证。第四，无聊技术赢了别追心，追稳。 第五，把一切都写下来，你脑子里的那些经验、判断、直觉，如果没写进仓库，它就不存在。这五条原则就是 harness engineering 的 精髓。 代码由机器来写，但系统设计、约束、规则、反馈、循环、品味、判断，这些东西仍然是深层的，不可替代的人类工作。 最后送你一句话，未来不是 ai 写代码，未来是工程师设计一个世界，让 ai 在 里面写出好代码，这就是 harness engineering， 而它已经到来了。 感谢你看完这三集。如果你想深入了解，去看 open ai 的 原文， harness engineering leveraging codex in an agent first world 链接在简介里，如果这个系列对你有帮助，记得点赞和关注我们下个系列，再见。

今天我们来拆解最核心的两个实践。先说第一个，这个团队踩过的最大的坑就是信息过载。他们最开始做了一件所有人都会做的事， 他们把所有的规范、约定、架构、说明、测试要求全塞进了一个巨大的 agents md 文件里。结果呢？ agents 的 表现反而变差了。 为什么？因为上下文窗口是有限的，你塞太多信息进去， agents 就 会就近匹配它，抓到哪条规则，离得近就用哪条，而不是真正去理解该怎么做。 修复方法很简单，也很优雅。把 agents 点 m d 变成一份只有一百行的目录，一张地图，具体的规范、详细的文档全放在 doc 目录里， agent 需要什么就顺着地图去找。 来看看一个设计良好的 agents 点 m d 长什么样？注意它有多短，看到了吗？每个板块只有一两行，给一个核心规则，然后指向详细文档， agent 的 按需渐进，发现上下文用到什么，查什么， 注意这里，它是一个指，真不是内容本身，这个区别直观重要内容放在 docs 里，按需加载，这样 agent 的 上下文窗口永远留给当前最需要的信息。 说到信息，这里有一个更深层的问题，它会改变你对代码仓库的整个认知。 想想看，你的团队有多少知识是藏在 slack 聊天记录里的，有多少架构决策是开会时口头定下来的，有多少安全规范是某个前辈私信发给你的，所有这些 agent 统统看不到。对他来说，如果信息不在仓库里，就完全不存在。 这个绿色标记就是 agent 的 知识边界内的世界，仓库里的 markdown 文档是他唯一能看到的东西。 下面呢？产品规划文档在 google docs 里，安全指南在 slack 私信里，架构决策在某个人的脑子里全部不可见。所以结论是什么？每一条团队知识都必须推入仓库，变成版本化的文件，否则对 agent 来说，它就不存在。 好上下文的问题解决了。但还有第二个更棘手的问题，当 agent 每天产出三四个 pr 的 时候，谁来保证代码质量？靠人工扣 review 吗？ 根本来不及。每人每天三点五个 pr， 你 就算全天只做 review， 也跟不上这个节奏。所以答案是，把规则变成代码，让机器来执行。 最底层是 types， 纯粹的数据定义，零依赖 config 只能引用 types， 往上是 report， 它只能引用 config， 每一层只允许依赖它左边的那一层，决不能越级。 service runtime， ui 一 路向右。这条规则被硬编码在 linter 里面，不是建议，是铁律。 如果有一个 u i 文件，直接 import 了 repo 层的代码， c i 立刻变红。 agent 看到报错自动修复，整个过程不需要任何人类参与。而这里面最精妙的设计是什么呢？是 linter 的 报错信息。来看这个例子， 注意看这个报错，它不是简单地说一句违规了就完事了，它告诉你哪里错了，为什么错了？该怎么改，详细文档在哪里。这段报错信息会直接注入到 agent 的 上下文里。换句话说， linter 变成了 agent 的 老师，每一次报错都是一次学习。 除了分层规则，它们还有一组叫作品位不变量的东西。听起来很文艺，其实就是一套机械化检查的代码风格规则。 比如说禁止裸的 console 点 log， 必须用结构化的 log 带上请求 id、 用户 id 这些上下文字段，这样出了问题才能查。 命名规范也是强制的， xgame 和类型的名称必须一致，数据库叫 user id， 代码里就得叫 u g a d， 不 能起别的名字。 文件大小也有硬限制，单文件超过三百行， linter 就 标红，强制你拆分，保持每个文件小而聚焦。 还有平台可信检查，移动端、桌面端 a p i， 每个平台都有自己的验证清单，一百万行代码，一套规则零例外。 说到技术选型，这个团队有一个让很多人意外的原则，他们故意选择无聊的技术。什么意思？就是可组合的，简单的积木块，每一块只做一件事，组合比继承更好理解， agent 也更容易把握， 而且必须是 a p i 稳定的。那些已经存在了很多年，不会每次发版都破坏兼容性的工具。你用一个两周前刚发布的炫酷框架， agent 大 概率不认识他。 还有一个关键，他在 ai 的 训练数据里出现过无数次。 agent 对 这类工具的理解最深，写出来的代码质量也最高。 更极端的是，他们甚至自己重新实现了一些小型第三方库，比如用自制的病发控制器替代 p limit。 为什么？因为自己写的代码， agent 能完全理解，完全测试，完全调试，绕开上游黑河反而更可控。 到这里我们覆盖了两个核心实践，第一把信息组织成地图，让 agent 的 按需查找。第二，把架构规则变成代码，让机器自动执行。 下一集是最后一集了，我们聊反馈循环，怎么让 agent 的 自己看见 bug， 自己清理代码，自己互相 review 下集见。

二零二五年八月， open ai 内部一个小团队做了一件疯狂的事。他们建了一个全新的代码仓库，然后立了一条规矩，从今天起，没有任何人可以亲手写一行代码， 所有的代码必须由 ai agent 完成。五个月后，这个仓库涨到了一百万行，一千五百个 p r 被合并，而团队从最初的三个人只增长到了七个。他们管这种新的工作方式，叫 harness engineering， 驾驭工程。 好，现在你可能会问，等一下，如果代码全是 ai 写的，那这些工程师一天到晚在干嘛？是不是就坐在那喝咖啡？ 恰恰相反，他们比以前更忙了，只不过忙的东西完全变了。以前呢，工程师的核心产出就是代码，你想你敲，你测，你上线。 但现在呢？你不碰代码了，你的工作变成了设计一个环境，定义清楚你到底想要什么，然后搭建一套反馈循环，让 agent 自己去跑。打个比方，你不再是赛车手了，你变成了赛道设计师加调车工程师。 这里面有一个非常反直觉的认知，当 agent 犯了错，你的第一反应不应该是这个模型太蠢了，而是要问我的环境里缺了什么？ 是少了一份文档，还是少了一条规则？然后你让 agent 去补上这个缺失。最妙的是，每一次补权都会永久积累，下一次遇到同样的问题， agent 就 不会再犯了。 说这么多理念，让我们看看具体的数字，这个团队在五个月里到底交出了什么成绩单？ 零应用逻辑测试、 c i 配置文档、工具链。所有东西都是 agent 写的，开发速度是传统方式的十分之一。同样规模的产品，传统团队可能需要几十个人干一年，他们七个人，五个月， 每个工程师每天合并三点五个 p r。 更有意思的是，当团队从三人扩到七人时，人均吞吐量不仅没降，反而还涨了。这说明什么？说明这套体系是可规模化的。 当然也不是一帆风顺。早期他们每个周五都要花一整天时间手动清理 agent 产生的质量问题，代码风格不一致啊，死代码啊，各种小毛病。但后来他们连这个也交给 agent 自动化了。 那它一开始是怎么启动的呢？很简单， codex c l i 一 行命令就把整个项目脚手架搭好了， 仓库结构 c i 配置代码格式化，包管理器、应用框架全部一键生成。最魔幻的地方是什么呢？连 agents 点 md， 就是 那个教 agents 如何在这个仓库里工作的说明书，居然也是 agents 自己写的， 套娃了，属于是好。那到底什么是 harness？ 这个词来自马具，就是套在马身上的那套装备。它的作用不是让马跑得更快，而是把马的力量引导到正确的方向上去，同时防止它乱跑。用在 ai 上也是一样的道理。 harness 就是 用户请求和 agent 输出之间的那层东西，但注意不包括模型本身。 martin fowler 总结了三大支柱， 第一个叫上下文工程。简单说，就是你在每一步精确地告诉 agent， 他 现在需要知道什么，信息太多，他会迷路，信息太少，他会瞎猜。 第二个是架构约束，你不能靠人去 review 每一行代码，速度太快了， review 不 过来，所以必须用 linter c i 这种机械化的手段来强制执行规则， agent 一 违规， c i 就 红了，而且报错信息会直接告诉 agent 怎么改。 第三个是商管理， agent 写代码很快，但快就意味着质量会漂移，风格不一致，死代码庸于逻辑都会慢慢堆积。你需要另一批 agent 在 后台持续清理，就像城市里需要环卫工人一样。 martin feller 说过一句很精辟的话，对 harness 的 改进比换一个更好的模型效果还大。换句话说，你在环境上每投入一分力气，回报都是永久的。 模型会迭代，但你建的这套体系它一直在好。以上是这套体系的是什么和为什么，但最重要的问题还没回答，到底怎么做？ 下一集我们来拆解两个最核心的实践，怎么给 agent 为信息，以及怎么用机器来守住架构的底线。我们下集见。

上一课我们说到 harness， 绝对不是写一条长长的提示词，而是给 ai 装上轨道的整套工程。这就像新员工入职， 你不能只丢下一句好好干就走人，你必须给它配齐岗位说明书、工作台、质检流程和紧急刹车。把这套制度套用在 ai 身上。 on topic 管它叫编排层， openai 把它落地成平台隔离执行环境，把模型下达的指令和平台层面的真正执行并在一起，才是一套能让 ai 踏实干活的完整制度。构建这套制度的第一个零件是任务合同。 ai 最容易犯的毛病就是他觉得任务做完了，但你觉得根本没达到要求。 问题出在双方对什么算做完没有统一定义。 entropy 给出的解法是，任务合同每一轮工作开始前，必须明确这轮交付什么，怎么验证。 在具体实操中，他们让 agent 写一份两百多项的 j 三格式功能清单，一开始所有功能全部标成未通过状态，后续 agent 干活时被强制约束，只能修改通过状态这个字段， 不能乱动。测试定义本身，这就把一句话的模糊描述变成了可以逐一打勾的硬性检查项。 第二个零件是工作环境， ai 不 能在真空或者无界线的网络里工作，你需要给它划定物理操作范围。 open ai 和 cloud 分 别采用了隔离环境和沙箱机制，把文件系统和网络从底层隔开。设计这个环境有两条死命令， 第一， ai 需要的工具和权限必须齐全，缺了工具它就会卡住或者胡乱绕路。第二，不该碰的东西必须在物理层面直接切断。你不能在提示词里写一句请别碰这文件，而是要在系统级别让它根本碰不到。 第三个零件是上下文与记忆管理。这里有一个非常反直觉的现象，叫上下文辅案。很多人以为给 i s i 的 信息越多越好，但实际情况是，随着上下文窗口里的信息越积越多，模型准确提取信息的能力反而会直线下降。就像桌面上堆满了文件，你根本找不到需要的那一张。 行业里的共识做法是给 agent 建立多层结构化文件。比如 cloud， 就 把上下文分成了三层。全队共享的项目规则文件，用来记住之前重要发现的跨对话记忆文件，以及记录当前任务进度的文件。这保证了 ai 眼前的每一刻摆置的都是最有用的信息，不多也不少。 第四个零件是权限边界管理，权限最大的痛点是人类会产生批准疲劳。 osloffic 公布过一个扎心的数据，用户手动批准了百分之九十三的权限提示弹窗，绝大多数人看都不看就直接点同意，安全弹窗彻底变成了噪音。 为了解决这个问题， on topic 推出了自动模式，用一个分类器模型来代替人工审批。这个机制在测试中只拦截了百分之零点三六的操作，但被拦截下来的百分之百都是真正的危险行为。当然，分类器不可能拦截所有风险， 它只是安全和效率的平衡点。最终的底线依然是把 ai 放在隔离的沙箱环境里运行。第五个零件是质检与反馈。这里有一个铁律验证，绝对不能靠 agent 自报。如果 ai 告诉你所有测试都通过了，人类却发现跑不起来，这在职场上是严重的诚信问题。 接法使界限深层对抗网络的思路，把干活的 generator 和评判的 evaluator 彻底分开，让一个持怀疑态度的独立模型专门负责挑毛病，效果远好于让它自我批评。在实操层面，我们会用到 hooks 机制， 它不是在给建议，而是在改完代码提交前等关键节点，由系统强制介入，哪怕模型想违规， hooks 也会直接拦住，确保规则被物以值刑。 第六个零件是持续清理。 ai 有 一个特性，它会学习并复制系统里现有的坏习惯，产生那种技术上能跑但设计糟糕的垃圾代码。 open ai 分享过，他们早期每周要花百分之二十的时间专门清理这些 ai 垃圾。解决这个问题的正确姿势是把反复出现的错误直接升级成自动化检查机制，不要靠人盯着修，而是把代码规范变成强制的检查，把命名逻辑变成 ci 流水线的一部分， 让机制去拦住坏习惯，而不是等坏习惯泛滥了再去清理。讲完零件，我们要纠正一个致命误区， honest 绝对不是写一份超长的规则文件。 open ai 试过给 ai 写一个巨大的说明书，结果彻底失败了。因为上下文是稀缺资源，文件太大，任务本身就会被挤出去，这会引发上下文焦虑。 当模型发现窗口快填满时，它会产生一种够了的心理暗示，导致任务还没做完就过早收工。稳健的做法是把规则做成结构化的入职流程，提供一个短小的入口，配合深层的知识库链接，再加上能被机械验证的校验机制，这样才能保证 ai 在 清爽的环境下高效工作。 我们把这六个零件按约束力的大小排一下，就形成了 harness 的 三层护栏结构。第一层是软护栏，比如贴在工位上的便签，这只是建议模型，偶尔会忽略。第二层是硬护栏， 比如 hooks 和权限控制，这不是在商量，而是系统直接拦住不让过。第三层是最硬的护栏，就是沙箱和自动监控， 它不仅监控行为，还能在出事后回滚。有了这三层叠加，你才敢把复杂的、高价值的任务真正交给 ai 去独立完成。 一句话总结， harness 就是 ai 员工的岗位说明书，工作台、门禁、交接、本质检线，加上紧急刹车。只有这六个零件齐了， ai 才算从问答工具变成了独立的生产系统。概念讲完了，下一课我们来看实战 openai 是 怎么靠这套东西让三名工程师在五个月内写出一百万行代码的？ andropic 又是如何让 agent 连续工作数小时都不停手的？我们下集可见。