harness在ai中的含义

ai 时代的操作系统是什么？是 agent harness？ 本期我们精读 google deepmind 工程师 flipshmidt 的 博课 the importance of agent harness in twenty twenty six， 一 起看看 harness 在 二零二六年为什么会非常重要。各家顶尖模型在静态跑分上的差距已经缩小到只有很小了。但这可能是一种错觉，因为任务越长越复杂，模型之间真正的差距才会暴露出来。比如你让模型进企业，跑一个长线自动化流程，读几百页文档， 查代码，总结依赖关系，到第三十步，调 a p i 建一个工单，到第五十步，再汇总一份报告，跑着跑着他就开始跑偏了，或者完全忘了第一步定好的安全规则，最后整个工作流彻底塌死，排行榜上那点的分叉根本测不出这种灾难。 所以我们需要一种全新的方式来验证模型的真实能力，需要一套系统能证明模型可以可靠地执行跨天的长线工作流，而 agent harness 就是 其中一个解法。 agent hornets 是 包裹在 ai 模型外围的基础设施，用来管理长生命周期的任务。它本身并不是那个去干活的 agent， 它是软件系统层面的一种控制机制，确保 agent 始终保持可靠高效可操控。那它具体干什么呢？第一个， prompt presets， 预设提示词，就是在模型开始干活之前，提前给它塞好一套规矩。比如你是一个代码审查员，输出必须是 jason 格式，这些规矩不用每次手动写， harness 会自动帮你注入。第二个 tool handling 工具调用管理。第三个， lightcliffe hooks 生命周期钩子，钩子就是你提前在流程里买好的检查站模型，每执行完一步，钩子就自动触发一次检查， 比如输出格式对不对， token 有 没有超限，有没有触发安全红线，如果检查不过，钩子直接拦截打回重来，不用等到最后才发现整个流程已经跑歪了。第四个，现成的高阶能力， 比如自动规划文件系统读写，甚至子 a 阵管理。为了更好地理解它的定位，菲尔举了一个例子，大模型 就是 cpu 提供原始的计算处理能力，上下缝窗口就是 r a m， 内存条容量有限，关掉就没了。 agent harness 就是 操作系统，也就是 o s， 它负责料理上下文，负责处理开机引导，就是塞进去基础提示词预埋。生命周期钩子还负责提供标准化的驱动程序， 就是工具调用的处理。而你写的那个 agent 应用呢？它是跑在这个操作系统之上的。 a p p 那 现在市面上有这样的通用 harness 吗？费尔坦言，目前还很少。 cloud code 是 这个新兴品类里最典型的代表， anthropomorphic 正在尝试通过 cloud agent sdk 来把它标准化。 lanchan 也推出了 deep agents， 在 做类似的事情。不过话说回来，你仔细想想，其实所有的编程 c i i 工具在某种程度上都算是专用的 agent harness， 只不过它们是为写代码这个特定场景设计的。 harness 的 重要性体现在三点，第一， 弥合跑分和真实体验之间的鸿沟。现有的 benchmark 跟用户的真实诉求严重脱节，有了 harness， 我 们在真实场景里验证模型到底行不行？第二，释放模型的潜力。如果没有 harness 的 加持，用户的实际体验大概率会远远落后于模型本身能爆发出的上限。 harness 可以 让开发者可以直接用验证过的工具和最佳实践来构建 agents， 不 用从零开始踩坑。 第三，构建闭环反馈。只有在一个统一的稳定的 harness 环境里，系统才有闭环反馈回路，研究人员才能根据用户实际使用中遇到的真实问题，一步步去迭代和改进。说到底就是 feel 那 句话， 你改进系统的能力上限，完全取决于你验证输出有多容易，大模型太容易输出飘忽不定的垃圾了。 harness 通过强制结构化输出，把生成的文本定格成可打分的机器日制。 只有数据结构化了，才能被量化衡量，只有能被量化衡量，系统才能被持续改进。这就是 agent harness 在 二零二六年的核心价值定位，不是业务代码， 是底座，不是应用，是操作系统，不是锦上添花，是基础设施。好了，本期内容就到这里，下期我们将继续读这篇文章的后半段，聊聊为什么 fusemaid 说 你辛苦搭建的 harness 代码天生就注定要被删除，以及为什么这些注定被删的废代码能创造整个 ai 工业界最有价值的。这里是慢学 ai， 我 们下期见。

上期我们聊了 agent harness 是 什么？这期来聊一个更关键的问题，怎么构建它。你可能会想，这还不简单，写控制流，编排逻辑模型输出格式不对，加一层 f l s 拦截重试，多部规划走偏了，搭一套复杂的状态机，强制纠偏， 把每个可能出错的地方都用代码锁死。这套思路在传统软件工程里没毛病，但放到 agent harness 的 构建上行不通。为什么那么说？计算机科学家 rich sutton 写过一篇著名的短文，叫 the bitter lesson 苦涩的教训，核心论点是，过去三十年，凡是依赖庞大算力的通用方法，每一次都击败了人类手工编码进去的鲜艳知识。无一例外，这堂课正在 agent 开发领域真实重现。看看顶级团队是怎么做的。 manus 六个月内把自己的 harness 重构了五次，目的只有一个，删掉那些僵硬刻板的前提。假设 lion chain 一 年之内把 open deep research 架构推翻重写了三次， versio 更狠，直接砍掉了 agent 百分之八十的 tour。 结果呢？执行步骤更少， token 消耗更低，响应速度更快。顶级团队不是在加代码，是在疯狂的删代码之前精心设计的聪明逻辑，在新模型面前全成了累赘。 所以 harness 的 构建原则可以概括为， build delete， 为废弃而构建 harness 必须做到轻量化，因为每当新模型一发布，它必然带来全新的 agent 构建方式。二零二四年还需要复杂管道才能实现的功能，二零二六年可能一条 prompt 就 搞定了。 所以你的 harness 架构必须像乐高积木一样松散，允许你随时流畅地撕掉昨天才写好的那段聪明控制逻辑。如果你对控制流做了过度设计，下一次模型更新会直接击穿你的系统。既然写的 harness 代码注定要被删，它的价值在哪儿？ 这就要说到大模型，一个很难根治的问题，模型漂移 model drift。 短对话里，模型表现得很好，但在超长任务中，它会慢慢发生变化。跑到第一百步的时候，它会悄悄忘记开局设定的规则，开始胡言乱语。 就像潜水员在深海待久了，会出现弹醉，这种长城漂移很难捕捉。但如果大模型是跑在 harnis 里面的呢？ harnis 会像飞机黑匣子一样精确记录模型在第一百步之后，到底是在哪个节点上丧失了遵循指令的能力。 这些断点数据在推理时收集到的失败日制可以直接投喂回训练级，反补到下一轮训练中。 the harness is the desert tent， harness 就是 数据级。 重点在于，你的 harness 到底捕获了多少条长任务崩盘轨迹 a 阵，他每一次在工作流后期跑偏失败，那一次失败都可以被用来训练下一代系统。 谁的 harness 在 真实场景里拦截到了更多崩溃轨迹，谁就能提炼出更好的后训练数据集，就有可能训练出更好的模型。所以回过头看这篇文章的脉络，一条非常清晰的逻辑线。大模型很强，但长任务里会崩，你得给它搭操作系统，也就是 harness。 这套系统里的控制代码注定会被新模型淘汰，但它在运行中捕获的崩溃日记，才是全行业最稀缺的数据金矿，不要抗拒虫垢和废弃代码，学会张开监控网，记录大模型每一次失控的瞬间，这是用来训练更强模型的宝贵数据集。 好了， phil smid 这篇文章的精读到这里全部结束了，如果你觉得有价值，欢迎点赞关注，这里是漫学 ai， 我 们下期再见！

当 ai 接管了写代码这件事，如何保证它们不会以光速造出一座史山？ open ai 的 思路是严格的约束，约束是速度的前提， 边界必须刚性封死，但边界之内让 agent 完全自由地实现。我们继续来精读 open ai 工程。博克 harness engineering 强制执行架构与品味部分，可以用规范文档来约束吗？答案是不够。 agent 看了文档理解了，但他未必会遵守。 文档是建议，而 agent 需要的是法律。如果规则只是写在文档里， agent 会复制已有结构，放大已有模式， 错误结构会被指数级复制。在这种速度下，靠人类 code review 维持秩序是不可扩展的。如果没有钢性护栏架构，漂移几乎是必然发生的。所以问题不是写不写规范，而是怎么把建议变成法律。核心原则是强制执行不变量，而不是微观管理实现。 什么意思？举个具体的例子， openai 规定所有外部数据必须在边界处做 skimmer 校验，这是不变量，是死规定，不能商量。 但你用什么工具来校验，可以用不同的实现方式，这是实现。 a 政可以自由选择，不是不管，而是只管那条不可逾越的底线， 底线以上，你怎么跑都行。就像高速公路，正是因为有了护栏和车道线，你才敢踩油门。这个原则落地之后，形成了一套极其严格的刚性架构。没有护栏的高速公路，越快越致命。首先是分层，每个业务领域被划分为固定的几层，从类型层到配置层， 到数据访问层，到服务层，到运行时层，最后到界面层。代码只能向前依赖，决不能回头。为什么？ 因为反向依赖会让改一个地方牵连到一大片。如果 service 可以 调 u i i， 那 改 u i 的 agent 呢？根本不知道自己同时也影响了 service， 他 只看得见自己负责的那个文件。 当一百个 agent 同时改代码，这种隐性牵连会迅速失控。打个比方，后厨流水线之所以高效，就是因为方向是死的。切菜递给灶台，灶台递给摆盘，如果摆盘的人可以反过来要求切菜的人重新处理食材，整条线立刻瘫痪。 谁也不知道自己手上的东西是最终版还是半成品。单向依赖的本质就是控制影响范围，改动指向前传播，上游永远不会被下游拖下水。然后是横切关注点的处理。什么叫横切关注点？ 就是那些每个模块都需要，但又不属于任何一个模块的东西。比如用户认证、日制记录、功能开关，这些东西很容易到处乱跑，哎，模块自己接一下，认证 b 模块也自己接一下，很快就乱成一锅粥。它们的做法是，所有这些公共能力必须通过一个统一的入口 providers 进入。你可以把它想象成大楼的门禁系统。不管你是送快递的还是修空调的，都必须从大门刷卡进入，不能翻窗户，不能走消防通道。除此之外的任何路径，禁止 c i 直接红灯打回。 而且这些约束不是靠人去检查的，是靠自定义 linter 来机械执行的。这里有一个非常精妙的设计，这些 linter 不 只是报错工具，它们是上下文注入工具。当 linter 报错时，错误信息里会直接写上补救指令。比如 service 层不能引用 u i 模块，请将共享逻辑移动到 us 目录。 agent 读到这条报错，等于读到了一条 prompt， 然后他自己重构代码，重新跑 linter， 直到全部变绿。整个过程不需要人类介入。 不是人类守规则，而是规则守系统。说到这里，我们讨论的还只是怎么管理结构，但真正有意思的地方在于，规则本身的性质发生了变化。在人类优先的工作流里， 结构化、日制格式、命名规范、文件大小限制。这些规则常常让人觉得限制创造力，但对 agent 来说，这些规则是倍增器。一旦你把一条规则写进代码，它瞬间就在所有 agent 的 所有任务中生效了。 同一条规则在人类世界是负担，在 agent 世界是杠杆。还有一个挑战，很多工程师审美直觉的认知， agent 写的代码风格可能不像人写的谢亮明，可能有点怪，排版可能不够优雅，但只要它符合三个标准，正确可维护， 对未来的 agent 可读就是好代码。好看不再是标准，好用才是人类的角色也因此发生了根本性的转变，不再是一行一行 review 代码的审查者，而是历法者。人类的品味被持续地反馈进系统。 怎么反馈？通过 review、 评论、重构 pr 以及用户反馈的 bug。 当你发现自己在 review 中反复纠正同一个问题时，你不去修那段代码，你把规则升级为代码，从建议 到文档再到代码，这是约束的三级火箭。简单总结下，在 agent 时代，约束不是束缚，而是基础设施。具体来说，第一架构是法律刚性分层和 providers 模式保证了 agent 不 会在结构上跑偏。第二， linter 是 prompt 自定义， linter 不 仅报错，还自带修复指令，让 agent 形成自我纠正的闭环。第三，规则是倍增器对人类繁琐的规则，对 agent 来说是一次便携全职生效的杠杆，而人类的工作从写代码审代码变成了为机器世界立法。下一期 我们要讨论当 agent 数量扩大到百台级别时，如何管理海量并行 p 二带来的合并冲突。这里是慢学 ai， 我 们下期再见。

他已拿下两万家新标字节跳动开源的深度研究家。多智能体框架 dear flow， 它不是一点零的升级版，而是从零开始的全新版本。它能帮你深度调研搜索网页、分析内容代码、执行、内容生成等几乎任何任务。 因为它内置了多智能体协助系统，能分工合作、并行执行，甚至能记忆你的偏好，让每一次请求更聪明高效。最关键的是，支持各种主流搜索引擎集成自定义工具和私有知识库，可以说是学习科研、自动化办公的全流程智能解决方案。

我们继续精读 openai 的 工程博克 harness engineering leveraging codex in an agent first world。 当代码生成速度不再是瓶颈，验证能力就成了新的瓶颈。 openai 的 解法是让 agent 自己验证自己，但这里有一个前提条件， agent 得先看得见系统的状态。什么意思呢？ 一个人类工程师修完一个 bug， 它会打开浏览器，看看有没有报错，看看性能监控面板， 确认响应时间正常。这些动作的本质是人在用眼睛和听诊器感知系统的状态。但以前的 ai agent 不 具备这些感官，它只能写代码，写完就甩手了。 它看不到页面渲染成什么样，不知道系统有没有报错，更不知道性能有没有变差，需要人验证后截图告诉它哪里有问题。而现在，如果让 agent 自己验证自己需要可读性 legibility， 它的意思不是代码写得好不好读，而是 系统的状态对 agent 来说是不是透明的、可解析的、可验证的。这给我们带来的思维转变是，不要问 agent 能为你做什么，而是问你能为 agent 提供什么。那 open i i 的 团队具体是怎么做的呢？首先要解决一个前提问题， agent 需要一个独立的工作空间。在技术上，他们用了一个叫 gitworktree 的 方案，你可以把它理解为从主代码库附了一份独立的副本， agent 在 这个副本里自由折腾， 改什么都不影响别人。就像每个厨师有自己独立的操作台，各做各的菜，互不干扰。有了这个独立空间之后，接下来就是装感官了。第一个方向， 给 agent 装眼睛。把 chrome 浏览器的开发者工具协议接入了 agent 的 运行时，你在 chrome 里按 f 十二，会弹出一个开发者工具面板，可以检查页面结构、看网络请求、调试代码。 现在 agent 它也可以用这套工具了，它可以启动应用，打开页面，看到页面上每个按钮、每段文字、每个输入框的位置和状态。它们还给 agent 创建了专门的技能，来处理 dom 快 照、截图和页面导航。 dom 快 照是什么？你可以把它想象成网页的 x 光片，网页表面上是你看到的按钮和文字，但在底层，它是一棵树状的结构，叫 dom。 dom 快 照就是把这棵树在某一刻的状态完整拍下来，交给 agent 的 分析。 有了这些， agent 就 能够直接复现 bug， 验证修复结果，并推理 ui 的 行为。注意这里的直接，以前 agent 写完代码就结束了，现在他可以自己打开应用，自己看效果，发现不对自己修。第二个方向，给 agent 装听诊器， 光看 ui 还不够。系统内部的状态、日制、性能、指标、请求、链路，这些肉眼看不到的信息同样重要。 open ui 对 可观测性工具做了同样的改造。可观测性是什么？简单说就是系统运行时的体检报告，包含三样东西，日制记录、发生了什么事、指标、各项性能数据是多少。 链路追踪一个用户请求从进来到出去，经过了哪些环节。他们给每个 agent 任务搭建了一套临时的可观测性环境，每个任务有自己独立的日制和指标， 用完就销毁。这就像给每个 agent 配了一间隔音室，他看到的日制只属于自己，这个任务不会被其他并行任务的信息干扰。然后 agent 可以 用 log ql 查日制，用 prom ql 查性能指标。 log q l 和 prom q l 是 什么？可以理解为专用的搜索引群。 log p l 用来在海量日记里精确搜索某一条错误记录， prom q l 用来查询最近五分钟的平均响应时间是多少这样的性能数据。 有了这些工具之后，像确保服务启动在八百毫秒内完成这样的 prompt 就 变得可执行了。还有更复杂的，比如这四个关键，用户旅程中没有任何一个环节超过两秒。以前，这些约束不容易被 agent 验证，需要靠人类盯着监控面板去看。现在 agent 自己就能查， 就能判断，就能通过或者打回这两个方向的投入。装眼睛和装听诊器带来的最终效果是什么呢？三次 codex 运行在一个任务上，工作经常超过六个小时，通常是在人类睡觉的时候。这就是可读性投资的回报，因为 agent 有 了眼睛和听诊器，它可以自主地写代码， 看效果，查日记，发现问题，修复再验证。这个循环完全不需要人盯着才能干活儿， 变成了可以自主干活儿值班。总结一下，这一期讲的是状态可读，让 agent 能看见 ui， 得知系统内部状态，从而实现闭环自主工作。下一期我们聊如何让知识被 agent 发现。这里是慢学 ai， 我 们下期再见。

我们之前读过 openai 和 deepmind 的 工程师的博课，他们都在强调一个趋势， agent 的 上限越来越取决于 harness， 而不是模型本身。今天开始精读 lanchen 的 这篇博课， improving deep agents with harness engineering。 他 们在不改变模型基座的前提下， 通过调优 harness， 让 deep agents 的 跑分从五十二点八提升到了六十六点五，从榜单第三十开外一路进到前五。他们刻意把 harness 优化空间压缩到三类 系统提示词、工具体系，以及围绕模型和工具调用的中间件。中间件是 line chain 使用的术语，本质上就是挂在模型和工具调用周围的 hook。 这三类改动都属于 harness。 lanchin 认为 harness 的 目标是把模型那种监次式不稳定的智能塑造成适合完成特定任务的稳定执行系统，在模型外围打造系统结构，去优化任务表现、 token、 效率、延迟等指标。那他们是如何发现 agent 在 哪里出了问题？ agent 跑偏报错超时之后，留下的是成千上万行运行轨迹，人工逐行排查成本极高，几乎不可能形成快速迭代。 于是 langchain 把读日制找问题这件事儿做成了 trace analyzer skill。 这个 skill 流程分为三步，第一步，抓取数据，从 langsmith 日制平台把这次实验里所有 agent 的 运行轨迹原始数据全部拉下来。第二步，并行分析。 系统按批次把这些 trace 切分开，同时启动多个分析子 agent 并行跑，每个子 agent 负责一批，专门做错误分析。找到报错点之后，所有子 agent 的 结论汇总到一个主 agent 那 里，由主 agent 统一提炼成结构化的发现和改进建议。第三步，人工审查。 主 agent 给出的是下一次实验要改什么的完整建议清单，工程师在这里参与核对建议是否合理，批准后才进入下一轮改动。有一点很重要，改动必须是通用的， 对特定任务过度拟合的修改可能让其他题目的表现退步。这三步加在一起，把原来需要几个小时的日制排查压缩成一个可以快速循环的工程流程追踪记录，也就是 trace 是 整个改进闭环的核心信号。很多所谓模型不够聪明的问题， 其实是系统没有在合适的时机把正确的上下和约束交给模型，没有 trace 就 无法定位这种缺口问题只会被归结为模型能力不足。 lincoln 做的这套实验，本质上是在证明一件事， agent 的 提升不只是模型能力问题， 更是系统设计问题。本期我们梳理了它们的实验框架和诊断机制。下一期我们来看在这些 trace 分 析之后， linkchain 具体做了哪些 harness 设计真正提升了 agent 的 表现。这里是慢学 ai， 我 们下期见。

当 ai 从简单的聊天走向更复杂的工程实践行业发现，决定 agent 在 生产环境中成败的往往是其外层的 harness 基础设施，而非底层模型的微小差异。 即使是像 gpt 五这样强大的模型，如果没有高效的 harness 来管理状态和验证结果，也很容易在长周期任务中迷失方向。今天我们通过一个视频理解什么是 agent harness， 它是运行在模型外部的基础设施层。 打个简单的比方，如果把大模型比作 cpu， 那 么 agent harness 就 相当于操作系统处理除模型本身以外的所有事物。 不同模型适配的 agent harness 略有不同，但通常包含了以下几个为独的管理能力，一是上下文管理，核心原则是最高效利用有限的上下文窗口。主要方案包括上下文压缩、按需加载以及不同任务间的上下文隔离。二是为 agent 构建持久化记忆能力，通常采用外部存储时限， 其中文件系统被认为是 agent 记忆机制的最终解决方案。第三个是工具管理能力，包含了安全隔离的运行环境，为模型提供与外部环境交互的能力。值得注意的是，工具并非越多越好，数量一般控制在二十个以内，部分极简框架仅保留脚本与 coco 两类工具也能实现良好效果。 其他能力还包括 agent 的 规划与调度，引导模型完成复杂目标。监控系统负责监测任务运行状态与系统指标识别工具调用失败与逻辑死循环，让模型能够快速从错误中恢复以及安全管理。通过设定 agent 的 权限边界，避免越权行为。 业界有一个共识是， harness 的 设计应当是模块化，并遵循未可被删除而构建的理念。因为随着模型能力持续提升，系统中的硬编码逻辑将不断减少，整体结构也会趋于简化。 除记忆管理异常恢复等少量核心协调需求外，绝大多数功能最终都会被模型加工具的简单组合所替代。希望能对你有所帮助。那今天就到这了，感谢大家。

软件工程师这个职业正在被重新定义。工程师不再写代码，而是为 agent 搭建工作环境。 openai 给这套新范式起了一个名字， harness engineering。 openai 的 团队做了一个实验，五个月构建一个真实上线的、拥有百万行代码的复杂系统。人类工程师零行手写代码， 期间大约合并了一千五百个片儿。最初只有三名工程师驱动 codex， 后来扩展到七人，人均吞吐反而提升人类掌舵。 agent 执行早期进展其实很慢，但原因不是 codex 不 够强，而是环境定义不足。 agent 写不出好代码，不是因为它笨，而是因为它瞎。它缺乏工具，缺乏对系统架构的认知，更缺乏上下文。真正的瓶颈不是模型智商不够，而是工程结构没搭好。 harness generation 就是 为了解决这个问题而诞生。 它不仅仅是让 ai 写代码，它是构建一个系统，让 ai 可以 稳定、可控、可验证的工作。当 agent 犯错时，不要去修代码。 作为一个 harness 工程师，第一反应应该是环境里缺了什么信息，导致 agent 犯了这个错误。是提示词没写清楚？是测试用力覆盖不足，还是工具链报错不明显？你是在调试 agent， 而不是在调试程序？ 工程师的角色彻底变了。在传统的软件工程里，工程师是泥瓦匠，关心每一行代码的语法，关心每一块砖的摆放。但在 harness engineering 里，工程师变成了系统设计师，工程师不再直接写代码， 代码的属性变了。以前代码是昂贵的资产，现在代码变成了廉价的翻译产物，它像打印出来的纸一样，随时可以生成，随时可以丢弃。 harness 工程师的核心职责只剩三件事，第一，设计环境。你要给 agent 打好脚手架、仓库结构、 c i 流水线、 lent 规则、开发者、工具。这些是 agent 赖以生存的基础设施。没有这些， agent 就是 在一片荒地上盖房子。第二，明确意图。 你要用足够清晰的语言告诉 agent 你 到底想要什么。不是模糊地说帮我写个功能，而是要把需求拆解成 agent 能理解的、无歧义的规范。第三，构建反馈。这是最关键的一环， agent 自我审查、静态检查、集成测试， 让 agent 在 提交代码前，在这个闭环里自己跑通。这不是提示词工程，这是反馈闭环工程。 这就打破了软件工程经典著作人越神话的核心定律。通常来说，人越多，效率越低。 但在这个团队，人数翻倍，人均产出反而加速了。新加入的工程师不是来流水线上拧螺丝的，而是来升级流水线的。当你的工作是改进基础设施时，你的每一分投入都会通过 agent 的 执行力 被放大成千上万倍。那具体是怎么做的呢？原文描述了他们的工作方式，深度优先把一个大目标拆解成一个个小的构建模块， 设计、编码、审查、测试，然后让 agent 逐个完成这些模块，再用它们去解锁更复杂的任务。当某个环节失败时，修复手段几乎从来不是再试一次，而是回到原问题，缺了什么能力？ 如何让这个能力对 agent 既清晰又可执行？在日常工作流里，人类工程师跟系统的交互几乎完全通过 prompt 完成。工程师描述一个任务， 启动 agent， 然后 agent 会自己开一个 pull request。 接下来，为了把这个 p r 推到完成，他们会让 codex 先在本地自我审查，再请求其他 agent 在 本地和云端分别做额外的审查，然后根据反馈自动修改，循环往复，直到所有 agent 审查者都满意为止。而且 codex 直接使用团队的标准开发工具，比如 g h 命令行、本地脚本以及嵌入在仓库里的技能文件来自主收集上下文，完全不需要人类在命令行里复制粘贴原文管。这个流程叫 ralph wiggum loop。 这个概念来自独立开发者 jeffrey huntley， 他的核心思想是把 ai agent 放进一个循环里，给他一个目标，让他反复执行 编码、审查、测试、修复，直到循环跑通为止。而且人类甚至不需要审查这些 pr。 原文说，随着时间推移，他们已经把几乎所有的代码审查工作都交给了 agent， 之间互相审查。简单总结下， harness engineering 重要性正在凸显。当代码可以被无限生成，工程师的价值就从写代码迁移到了设计让代码产生的环境。好了，本期内容就到这里，这里是慢学 ai， 我 们下期再见。

上一期我们讲了强制验证，本期来看第二个真正有效的 harness 改进点上方注入。 agent 对 自己所处的环境约束条件和评估标准了解的越多，他就越能自主地指导自己的工作。很多失败并不是能力不足，而是环境信息缺失。围绕这个原则，他们做了三件事儿。 第一件事是注入工作环境地图。通常的做法是让 agent 自己去探查环境，比如调用 l s 查看目录结构。但原文指出，这种自行发现上下文的过程本身就是一个高错误率环节 路径理解错误文件层级判断失误都会让任务跑偏。 luncheon 的 做法是由系统替 agent 完成这一步，他们加入了一个 local context metaf。 agent 一 启动系统，自动扫描当前工作目录、父子文件夹结构、工具路径以及 python 安装信息。把这些环境信息结构化后直接注入上下文。 agent 拿到的不是去找环境，而是一份已经整理好的运行地图。 这样做的目的是减少无效搜索空间。第二件事是明确告诉 agent， 它的代码会被程序化测试。打分模型本身并不知道什么叫可测试性，它只是生成代码。 line change 在 系统提示词中明确声明，你的产出会被自动化测试。评估任务规格里提到的文件路径必须严格遵守，否则自动评分会失败。同时强调必须覆盖边缘用力，而不仅仅是顺利路径。这样做是 为了避免代码只在理想情况下通过，从而防止质量逐渐松散，问题不断积累。换句话说，这是把评估标准提前显性化。第三件事是注入时间预算。 command bench 有 严格的超时限制，如果 agent 在 某个问题上反复尝试，它可能会一直消耗时间，直到任务失败。 lanchin 在 提示词中加入持续的时间预算提醒，当接近截止时间时，系统会引导 agent 收敛问题，进入验证与收尾阶段。模型天然不擅长时间估算，它不会主动优化时间分配， 所以这种约束必须由外部系统注入，才能保证在实线内完成工作。这三件事背后的逻辑其实是同一个，不要让 agent 自己去发现和组装它需要知道的运行条件。 harness 的 职责是提前整理好环境信息、评估规则和约束边界， 再主动递给模型外围位的信息。越精准，模型就越能把算力集中在真正的解析步骤上，而不是浪费在搜索路径和猜测规则上。这一步改动的本质并不是让模型更聪明，而是减少它的无效探索空间。 下一集我们来看第三个 harness 改进点，循环探测中间键如何防止 agent 进入无效修正循环。这里是慢学 ai， 我 们下期见。

当 agent 能瞬间写出大量代码，随之而来的是逐渐难以察觉却不断累积的代码商增，以及随之膨胀的技术债。本期我们继续精读 open ai 工程薄课 harness engineering 的 最终章， 看看 open ai 在 处理商增和技术债上的经验。哪怕你投入了再多精力去设计架构护栏， agent 的 本能依然是复制，它会模仿仓库中已有代码的模式。 一旦某个角落出现了细微的技术债，这种便宜的妥协就可能被 agent 快 速复制放大，最终导致系统结构逐渐失去连贯性。在早期实践中， openai 团队曾尝试过一个办法， 每周抽出大约百分之二十的时间由工程师专门做代码清理。听起来合理，但很快他们发现这种方式不可扩展。 在一个高度自动化、吞吐量极高的环境中，代码生成的速度远远超过人类清理的速度。人工清理永远追不上自动生产。问题在于规模已经失衡。 于是他们从改变机制入手，首先把工程师对代码的品味编码成一组明确的黄金原则，也就是可以被机器检查和强制执行的规则。例如优先使用共享的工具库， 而不是在不同模块里各自手写小工具函数。这样做并不是简单地禁止造轮子，而是把关键逻辑集中管理，避免多个版本的实现被 agent 反复复制，逐渐分叉。 又比如，在处理外部数据时，禁止那种 load 式的随意探测，也就是在未验证结构的情况下，直接假设字段一定存在。举个实际的例子， word 写法是拿到一段外部 j 散数据，直接通过 id 字段读取，用户 id 完全默认这个字段一定在里面，一旦对方传来的数据里缺少这个字段，程序就会直接崩掉。系统要求要么先做显示的结构验证，比如先判断字段是否存在，要么通过内部封装好的强类型 s、 d、 k 接口来统一获取数据。 通俗地说，也就是在代码里拿到一段外部数据后，不能直接去掉字段写逻辑，必须先写一段专门的代码来验证数据格式，或者全部由官方写好的数据接口层统一接管。 但只设立黄金规则还不够。接下来，他们建立了一套持续运行的清理机制，后台会定期运行专门的 agent 任务，扫描代码库中是否出现偏离这些黄金原则的模式， 一旦发现问题，就自动生成针对性的重构 pr。 这些 pr 往往力度很小，可以快速 review， 甚至自动合并。这种机制的运作方式更像是系统底层的垃圾回收，不是等系统失控再进行一次痛苦的大规模重构，而是持续小步自动地清理结构偏移。 在 a 政时代，技术债更像是高利贷，如果放任它，累积增长速度会超过你的偿还能力。唯一可持续的方式是建立一个持续小额自动偿还的机制。最后，这种高度自制的系统依然存在很多未知。目前还不清楚在一个主要由 a 政生成代码的系统里， 架构的连贯性在未来几年会如何演化。他们也仍在探索人类的工程判断究竟在哪一步能发挥最大的杠杆作用，以及如何把这种判断编码进系统，让它产生持续的复利。同时，随着基础模型不断进化，这套复杂的控制系统未来是否会变得更简洁也仍是一个开放问题。 但在这些未知之中，有一件事他们给出了非常明确的判断，纪律正在从代码本身转移到工程的支架上，代码本身将不再是纪律的主要主体。这里的支架指的是工具、执 行环境系统、抽象反馈回路以及整个底层的控制系统。这也指向了一个最后的核心结论，现在最困难的挑战 集中在设计环境、反馈回路和控制系统上。在新时代，软件工程的难点已经不在于如何榨取模型生成代码的能力极限， 而在于你能否构建出一个足够稳健的控制架构。好了，本期内容就到这里。至此， open ai 这篇技术博课 harness engineering 精读系列完结，下期再见。

当 agent 的 自主能力不断飙升，到底它深层的范围可以扩展到哪一步？一旦跨越了某个工程离界点， agent 将完全接管从代码到运维的每一环，是高度自治、端到端的全流程驱动。本期我们继续精读 open i 工程薄课 harness engineering， 看 ai 开发的自主性究竟可以到达何种程度。首先要重新界定 agent 深层的范围。在 openli 的 这个实验中，当他们说这个代码库是由 codex 生成时，指的不只是产品代码和测试代码， 它还包含 ci 配置与发布工具链内部的开发管理、工具架构设计的历史文档、评估系统测试的框架、 pr 下面的审查、评论与回复管理、仓库本身的脚本以及生产环境的监控面板、定义文件。并且， agent 正在像人类一样直接使用标准的开发工具，他们会拉取审查意见进行内联、回复、推送、更新，甚至经常自己压缩并合并 pr。 也就是说，他正在深度参与并运转着整个工程系统。当繁琐的执行环节被全面接管，人类工程师在干什么？人类依然在回路中，但工作重心已经转移到了一个完全不同的抽象层。人类不再是写具体代码的工人， 而是成为了定义规范的甲方工程师。现在的核心工作是三件事，排定优先级，将用户反馈翻译成明确的验收标准， 以及最终验证交付成果。如果在中间过程中 a 证卡壳了，人类也绝对不会下场去帮他逐行修代码。他们会把 agent 的 挣扎视为一种报错信号，去排查是不是系统里少了某个检测工具，缺了某种护栏， 还是文档没写清楚，找到缺口并补充到系统后，依旧让 a 证自己去完成代码修复。人类不再是执行者，而是环境与标准的设计者。随着测试、频审、反馈处理等 整个开发循环都被明确编码到系统架构中后， the great 跨越了一个决定性的自治域值，只需给定一个 prompt agent 就 能完全脱离人工干预，端到端地实现。来看看原文展示的这条全自动闭环流水线， 它会先自动查验代码库现状，遇到 bug 时自主运行应用去复现，甚至会自己录制展示错误的视频留作证据， 随后完成代码修复，通过再次驱动应用来进行自我验证，并录制第二段成功运行的视频作为比对。接着他会自己开启 pr， 如果有人类或其他系统 agent 提出审查意见，他能自行响应。 遇到构建报错，他会自我排查并修复。除非遇到了真正涉及方向性抉择的情况，他才会按零叫人类来判断，否则他会一路走到底，最终自动合并代码。这是一个在极其严苛的结构化环境中真实跑通的软件制造闭环， 从输入一段需求到最终代码合并，中间长达数小时的执行过程全由机器接管。这种真正跑通端到端的全自动开发，已经成为全行业最顶尖工程团队共同确定的引进目标。不仅是 openai enterprise 在 不久前展示的 agent teams 原型实验展示了相同的趋势， agent 已经进化出自主的端到端开发能力。未来的工程师不再是帮 ai 补全某个局部函数，而是把它当做真正的外包承包方，你只需要甩出完整的需求，不再管怎么写， 只定义什么算完成，然后等待它独立交货。虽然这种端到端全自动运行的前景令人兴奋，但是 openlight 紧接着给出了一个非常冷峻的提醒。原文写道，此行为高度依赖于该代码库的具体结构和工具链，也不应假设其能普遍推广，至少目前如此， 除非投入了类似的开发资源。这意味着这种高速运转的自制决不能被简单的复制粘贴，它是用极高的基础设施门槛换来的。如果没有这套重金打造的环境与护栏，单纯追求让大模型自动写代码， 只会制造出加速系统崩溃的数字垃圾。这也揭示了自制的尽头绝对不是对 ai 下手不管。相反，越是高度的自制，越离不开极度严密的环境设计与工程约束。好了，本期内容就到这里，这里是慢学 ai， 下期再见。

langchain 总结出的第三个真正有效的 harness 改进点是循环探测中间件，用来防止 agent 进入死循环。在大量 trace 日记里，他们发现一个非常典型的问题，当 agent 确定了一个解析方向之后， 它会高度执着地沿着这条路径继续推进。即使这条路径已经明显走不通，它仍然会在同一个文件上反复做微小修改，尝试局部修补，而不是整体重审。有些日制显示，同一个文件被连续修改超过十次，但整体思路没有发生任何改变。原本把这种现象称为 doom loops 模型，现在局部最优里出不来，不断消耗算力却无法推进任务。问题不在于他没有行动，而在于他没有跳出当前框架，重新思考。 luncheon 的 解决方式是加入一个 loop detection metalware， 它的原理很直接，通过工具调用的钩子 持续记录每个文件的编辑次数。当某个文件的修改次数超过预知 n 时，系统会向 a 阵的上下文中注入一条提示，要求他重新审视整体方案，而不是继续做局部修补。 这里有一个重要的细节需要说明，这种机制并不能保证模型一定会换方向。如果模型高度确信当前方案正确，它仍然可能继续沿着原路径前进。这不是一个逻辑保证机制，而是一种启发式干预。 它的作用是在模型陷入局部循环时提供一次强制反思的机会。原文对此有一段非常清醒的说明，这是针对当下模型缺陷设计的工程护栏。随着模型能力提升，这类机制未来很可能会变得多余，但在今天，它能够显著提高任务成功率。这背后体现的是 harness 工程的一种现实主义哲学，短期内识别并修补坏模式，而不是假设模型天然完美。 deepmind 工程师曾经说过一句话， harness 是 为了删除而构建，意思不是说它没用， 而是说它本质上是在为当前模型的短板提供临时支撑。随着模型进化，这些补丁会逐步消失。 harness 工程师的职责是理解模型的已知弱点，并为他们设计合理的护栏，同时也要意识到这些护栏是阶段性的解决方案，而不是永恒结构。下一集， 我们来看 lantern 在 算力分配上的 harness 策略。为什么推理不是越多越好，而是要合理分配？这里是慢学 ai， 我 们下期见。

lanchin 总结的 harness 改进点还包括算力怎么分配，以及 harness 和模型之间的适配关系。先说算力分配，推理型模型，也就是会在后台进行多步思考的模型，通常都有不同的推理强度档位。以 gpt 五点二 codex 为例，它有四档 low medium high x high， 档位越高，思考越深入，但消耗的时间和 token 也会显著增加。 turn knob bench 有 严格的超时限制，如果全程 kixmath 让模型在每一步都深度推理，很容易在简单步骤上消耗过多时间，最终因为超时失败。 lanchin 实测发现，全程 x high 的 得分只有百分之五十三点九，主要原因就是超时太多，而全程使用 high 反而能跑到百分之六十三点六，那怎么再提高？它们采用了一个非常直观但有效的策略，可以理解为推理加薪 x high high x high 规划阶段使用 kaxai 理解任务，制定整体方案。这一步最容易决定成败，值得投入更高算力中间实现阶段降到 high， 按计划写代码，不需要每一步都过度推演，降低推理强度可以节省大量时间。最后的验证与收尾阶段，再拉回 x high 查错确认结果，这一步需要谨慎。 这种分段式算力分配，最终把分数推到了百分之六十六点五，也就是系列开头提到的那个数字。这里有一个关键结论，推理强度不是越高越好，而是要分配的对。 harness 不 只是控制流程和提示词， 它还在管理算力预算。接下来是模型适配问题。 land chain 用 cloud opus 测试过同一套 harness 得分是百分之五十九点六， 表现有竞争力，但低于 codex 的 结果。它们的分析是，这套 harness 是 围绕 codex 反复迭代优化出来的，并没有为 cloud 单独跑过完整的改进循环。这带出一条工程原则， taylor harnesses to models 为特定模型定制 harness。 不 同模型在提示风格、推理节奏、工具调用习惯上都有差异。很多原则是通用的，比如做好上下文准备， 强制验证，减少无效循环。但如果想把某个模型的表现推到极限，仍然需要为它单独跑几轮 harness 迭代。回顾整个实验，可以提炼出五条工程实践，第一， 追踪及反馈，没有 trace 就 没有改进方向。第二，代劳上下文工程，把模型需要的环境信息提前整理好。第三，强制自我验证，让模型真正面对测试结果。 第四，识别并修补坏模式。循环探测是阶段性补丁，但有效。第五，为特定模型定制 harness。 通用原则之外，还需要针对模型单独挑优。如果用一句话概括这篇文章，那就是模型能力决定上限，而 harness 决定你能逼近上限多少。这里是慢学 ai， 我 们下个系列见。

ansaurus， 黑客松冠军，他开源了一个 github 项目，直接把 curlcode 变成高级工程师， 就是 everything curlcode 这个配置经过十个月的实战经验，有以下几个核心功能。第一个是 agent， 它有不同的一个 agent 的 分工，像一整个开发团队一样帮你工作，有功能实现规划，还有系统设计，决策测试， 质量和安全审查，漏洞分析，代码审查，还有一些错误的解决。第二个是 skills 定义，工作流和领域知识，这里面包含语言最佳实践， api， 数据库缓存模式， 还有一些什么子代理的渐进式、上下文系化、 tdd 方法论等。第三个是用于快速执行的一个斜杠命令，包括不限于测试，开发规划， 一拖一的一个测试生成，质量审查等。第四个是规则，包含了一整套 ai 必须遵循的一套规则，保持它模块化，同时它包含一些基于触发器的一个自动化，这里面有精简版本，也有详细指南， 那详细版本会有一些 token 的 优化，内存持久化、评估、变形化这些内容。如果你也想做一个复杂的 agent 的 开发，这是一个很好的一个学习资料，可以很好地帮助你和 cloud code 更好的写作。关注我，我会持续分享 ai 相关的内容。

上一期我们说了 luncheon 靠改进 harness 让 agent 跑分提升了十三点七分，他们总结了几个真正有效的 harness 改进点。本期聚焦第一个， 强制模型验证。 luncheon 在 trace 记录里发现最常见的失败模式是这样的， agent 写完代码，回头读了一遍自己刚写的内容， 觉得逻辑上看起来没问题，然后直接停工宣告完成。他根本没有去运行测试，拿实际的执行结果来验证，问题就在这里。大模型的深层内容在语言层面可以自洽，但在实际运行层面完全可能出错，只有跑测试才能拿到真实的反馈信号， 有了真实的报错模型才能修复，才能得到正确答案。蓝晨对这个问题上了两道防线。第一道是提示词层面的约束，他们在系统提示词里明确规定了一个四步走的解析框架，第一步，规划读任务，扫代码库，理解要求， 想好验证方案。第二步，构建写代码，同时要考虑测试，包括正常路径和边缘用力。第三步，验证 运行测试，读完整的输出结果，拿结果去对照最初的任务要求，而不是去对照你自己写的代码。模型很容易拿结果去跟自己的代码做比对，然后得出我的代码是对的的结论。这是一种自我封闭的逻辑，必须强制要求他回到原始的任务要求上做验证。 第四步，修复分析报错回头改，但只有提示词往往不够，模型还是可能忘掉或绕过。所以第二道防线是系统层面的卡口，完结前检查中间键，这个中间键的作用是，当 a 阵准备退出宣告完成时，系统直接拦截他， 强制要求他对照任务规格做一次验证，确认跑过测试才允许退出。这本质上是一个拉尔夫循环模型，偏向接受自己的第一个答案，必须主动推一把， 让他真正面对客观的测试结果，而不是他自己的主观判断。好了，本期内容就到这里，下一集我们来看第二个有效的 harness 改进点上菜上注入中间键。这里是慢学 ai， 我 们下期见。

上分管理是让 agent 在 大型复杂任务中高效工作的最大挑战之一。我们继续精读 open lii harness engineering 这篇技术博课，看 open lii 如何解决这个问题。它的做法是给 codex 一 张地图，而不是一本一千页的说明书。在开源社区里，有一个东西叫 adjacency， 已经有超过六万个开源项目在用它。 agent 点 md 和 readme 文件类似，区别在于它的读者是 agent。 openly i 团队一开始就试了一个巨型 agent 点 md 方案，把所有规则说明规范全塞进一个超长的 agent 点 md 文件里，结果以完全可预见的方式失败了。 失败的原因有四个，第一，上下文是稀缺资源。一个巨大的指令文件会挤占任务本身代码和相关文档的空间。 agent 要么漏掉关键约束，要么为错误的目标优化。第二， 指导太多等于没有指导。当所有东西都被标记为重要时，什么都不重要了。 agent 最终只会在局部做模式匹配。 第三，它会立即腐烂，一个巨大的说明文件会变成过时规则的坟场。 agent 不知道哪些还有效，人类也懒得维护这个文件，就悄悄变成一个有吸引力的麻烦制造者。第四，它难以验证一整块文本，难以做自动化检查。所以 与其把 i g s d r m d 当百科全书，不如把它当目录。具体做法是这样的，仓库的知识库存放在一个结构化的 doc 目录里，这个目录被当做真相源。 当信息出现矛盾时，以 duxley 的 版本为准来看，他们展示的目录结构跟目录有两个关键文件。第一个是 edison 点遍刚才说的一百行的目录，注入到 agent 的 正向缝里，功能就是一张地图， 指向更深层的信息来源。第二个是 architecture 点 m d， 项目的鸟瞰图有哪些业务域代码包怎么分层，模块之间什么关系？然后是 doc 目录，这才是真正的知识库。按类型分了几个子目录，设计文档被编目和锁影，每份方案都标了验证状态， agent 看到就知道该信任到什么程度。还有一组核心信念，定义了 agent first 的 操作原则，执行计划分，进行中的、 已完成的还有技术债务追踪、产品规格参考资料各自归类，再加上质量评分文档给每个产品预和架构层打分，谁准通过他知道哪块成熟可以放心改，哪块脆弱需要小心。接着是执行计划的具体用法，小任务用临时的轻量计划就够了，但复杂的工作要用。执行计划 包含进度记录和决策日制，这些全部都迁入代码仓库进行中的计划，已完成的计划，已知的技术债务，全部版本化集中存放。 这个知识仓库整体形成了渐进式。譬如 agent， 从一个小的稳定的 agents 点 m d 开始，然后被告知接下来该去哪里找信息，而不是一上来就被淹没。但光有好的结构还不够，文档最怕过时，所以他们用自动化手段来强制执行文档质量。 第一，专门的 linter 和 ci 任务来验证数据库链接有没有失效，交叉引用对不对，结构是否正确。第二， 他们还专门用了一个文档园丁 urgent， 定期运行，扫描仓库里的文档，发现哪些内容已经不再反映真实的代码行为了，就自动开 pr 修复，连维护文档这件事都交给 agent 来做了。 到这里，我们解决了怎么把仓库里的知识组织好的问题，但还有一个更根本的问题，知识得先在仓库里才行。 从 agent 的 视角来看，任何他在运行时无法在上下文中访问的东西，实际上就不存在。存在于 google docs 里的知识。聊天记录里的知识，人们脑子里的知识对系统来说全部不可访问。在一个正常的团队里，知识实际上散布在很多地方。 slack 频道里的讨论， 上次我们决定用方案 b google docs 里的方案文档，产品经理说了这种情况走异常流程。你同事的脑子里这个 api 有 个坑， 上次踩过一次，甚至是茶水间的闲聊，老板说下个季度要重构这块儿。这些知识对人类来说是自然的，你问一下同事就知道了，或者搜一下 slack 历史记录。但对 agent 来说，这些全部都是黑洞。 agent 能看到的现实世界只有仓库里的版本化文件、代码、 markdown 文档、 配置文件、 schema 定义、执行计划。如果你想让 agent 有 效工作，你必须把重要知识搬进仓库，但搬不是。把 slack 里的碎片对话原样复制进去。给 agent 更多唱下文，是组织和暴露正确的信息，让它能推理，而不是用临时指令淹没它。 就像你给新队友做入职培训，你会介绍产品原则、工程规范、团队文化。同样的，把这些信息提供给 agent， 它的输出就会更符合团队预期。 这个逻辑。再往前推一步，不只是知识要对 agent 可读，技术本身也得对 agent 可读。他们倾向于选择那些被称为无聊的技术，也就是那些成熟的、稳定的、没什么花哨、新特性的老技术， agent 更容易理解他们。理由有三个，第一，可组合性好，老技术的 api 通常设计得更简洁、更规范。第二， api 稳定，不会动不动改接口。 agent 的 训练数据里学到的用法不容易过时。第三，训练数据里出现的多大模型见过大量使用这些老技术的代码，所以对它们的理解更深，犯错更少。 更反。直觉的是，有时候自己造轮子比引入一个流行的第三方库更好。当你引入一个第三方库， a 阵只能看到你代码里的 input 语句，他看不到库的内部实现。如果这个库的行为出了问题， a 阵没办法修，因为那段代码不在他的世界里。但如果他自己写一个简化版的实现呢？ a 阵可以完整看到他的代码， 测试它，理解它的逻辑，甚至在需要时修改它。而且这种对仓库可读性的投资具有巨大的杠杆效应。不仅负责写代码的 codex 受益，其他 agent 也能附用这套知识体系。 比如 openlight 内部还有一个叫 artwork 的 安全 agent， 它的工作是自动审核代码，发现漏洞。因为它和 codex 共享同一个高可读性的代码仓库，它也能准确理解业务逻辑，找出潜在风险，提升仓库的可读性和可发现性，是一次投入多个 agent 同时受益。好， 我们来总结一下这一期的核心逻辑。第一层可以概括为一张地图，而不是一本说明书。不要把所有规则塞进一个巨大的 ads 点 m d 这会儿几站上下文快速过时。正确的做法是建立一个结构化的知识库，用一百行的 agent man 做目录， 指向 docs 里的具体文档。第二层是认知转变，不在仓库里，等于对 agent 来说就是不存在。所以必须把 slack 和脑子里的隐性知识搬进仓库，但不是乱搬， 而是像给新队友做入职培训一样，组织成可推理的原则。第三层是技术选型，为了可读性选择无聊技术。 为了让 agent 能完全理解，可以选择成熟的老技术，甚至为了透明性自己造轮子。最终这些投入会带来巨大的杠杆效应。你的仓库越好读，所有在上面工作的 agent 都将受益。 但如果把视角再拉高一点，你会发现，当代码开始由 agent 生成，仓库就不再只是人类协助空间，它变成了一个机器认知系统。下一期我们讨论如何把人类难以言传的工程品位变成机器必须遵守的物理定律。好了，本期内容就到这里，这里是慢学 ai， 我 们下期再见。