先修流程，再修结果：我如何理解 Agent 时代的可依赖性（Paul Graham 取向版）

我写网络小说有一段时间了，遇到过一种很具体的挫败：某一章读起来不对劲，我把它改好，接着往下写，过几章之后，同样的不对劲又回来了，只是换了个地方出现。

一开始我的处理很直接。一章坏了，就丢给 Codex，让它重写。人物说漏了他本不该知道的事，就把那句话删掉；打斗写得没劲，就往里加几句更重的描写。这种修改很快，快到让人以为问题已经过去了。可只要接着往下写，同一类毛病总会从别处冒出来，只是换了个说法，换了个位置。

后来我给自己定了一条规矩：先修流程，再修内容。

它的意思其实很简单：一章坏了，我先不急着把这一章改好，而是先问它为什么会坏、坏在创作流程的哪一层，然后去改那一层，最后才回来重做这一章。这个顺序更慢，有时慢得让人心里发痒，但它慢慢改变了我对“把一件事做好”这件事本身的理解。

写着写着我发现，自己真正关心的其实是一个问题，而且这篇文章从头到尾只追这一个问题：这次工作结束后，什么被留下来，使下一轮发生变化？

我会从写小说这件很小的事出发，一层层往外推：修一个结果，和修产生这个结果的东西，到底差在哪。中间会经过程序员的日常、人的能力、模型出错时怎么排查、以及便宜和昂贵的智能该怎么分工。但每到一个岔路口，我都想把它拽回同一个问题上：这一步做完，除了当前这个结果，还留下了什么，能让下一次不一样？

这些联想有一个很具体的起点。黄仁勋和 LangChain 的联合创始人 Harrison Chase 有过一场对谈，聊开放模型、企业专有的智能，以及 Agent 系统该怎么搭，原始视频在这里。从这场对谈及相关材料出发，我最在意的不是模型本身有多强，而是模型周围那一圈东西——它知道什么、能做什么、什么时候停、凭什么算做完——原来都可以被当成工程对象来修。后面关于流程、能力和学习的推演，都是我顺着这个入口自己往下想的，不是那场对谈的原话，我也会尽量把哪些是事实、哪些是我的推论分清楚。

一、那一章为什么总也修不好

先说清楚坏在哪。我最常撞见的有两种毛病，一种是人物越权知道了信息，一种是高潮写得没有力气。

第一种是这样：某个角色忽然表现得像读过了后面几章的大纲。他知道一个从没有人告诉过他的秘密，或者对一件还没发生的事提前有了反应。单看那一句，很好改，删掉、或者改成“他猜测”就行。但我改掉的只是这一句。再写几章，另一个角色又会因为差不多的原因，知道他本不该知道的事。很容易以为这是自己粗心，改得多了才会意识到，这不是粗心，是结构上的漏。

第二种更隐蔽。高潮不够劲，我的第一反应总是语言不够狠，于是加形容词、加动作、加重语气。改完那一段，确实激烈了一点。可再从头读整章，还是空。后来我才想明白，问题不在那一段的措辞，而在它前面：压制不够，主角没有真的被逼到绝境；代价太轻，赢得太容易；铺垫太薄，反转来得没有由来。高潮是被前面的结构顶上来的，不是被形容词堆上来的。你没法靠润色一个没有势能的句子，硬生生给它造出势能。

这两件事逼着我去看一个区别：我到底是在修一个结果，还是在修产生这个结果的东西。

删掉那句越权的话，是把一个坏结果换成一个好结果。它解决的是眼前这一章，是对当前结果的必要修复，我不反对先修好当前的结果。但如果创作流程本身没变，第十九章按下去的错误，到第三十章还会换身衣服回来。因为真正在生产这些句子的，不是我改的那一句话，而是我脑子里、以及我和 Codex 之间那套从没被明说出来的流程：这一章该写什么，每个人物此刻知道些什么，什么才算写好了。我改掉的是这套流程产出的一个样本，却没碰产生这些样本的那套生成流程。

有一类反复出现的错误，是在提示同一件事：系统里缺了一样本该被明确表示出来的状态或概念。当然，反复出错也可能来自上下文缺失、工具描述、模型本身、运行环境或验收失真等别的环节；但当同一种毛病换着地方反复回来时，它往往在指向一个还没被显式表示出来的区别。

人物老是越权知情，多半不是因为提示词里少写了一句“注意人物的信息边界”。更可能是整套流程根本没有一个地方，稳定地记着：哪个人物，在哪个时间点，通过什么事件，知道了哪些信息。这层状态不存在，模型每次就只能靠当前上下文里那点能看到的东西临场发挥，漏，是迟早的。同样的道理可以套到别的老毛病上：战力忽高忽低，可能是缺了一份“这个角色现在有多强、因为什么变强”的记录；伏笔埋下去就没影了，可能是缺了“承诺过什么、兑现了没有”这层关系；时间线自相矛盾，可能是缺了一个统一的事件时钟。有一类反复出现、又很要命的毛病，其实常在替我指出一件事：系统里有一个重要的区别，还没有被显式地表达出来。当然，这类反复错误也可能来自上下文缺失、工具描述、模型本身、运行环境或验收失真等别的环节，未必都能归到“缺一层状态”上。

如果把这层状态补上——比如给每个关键人物维护一份“到目前为止他知道什么”，情况就会不一样。写下一章之前，我可以把当前的知识边界先交给模型；写完之后，我可以检查这一章里人物新知道的每件事，是不是都能在这一章内部找到来源。约束从一句飘在提示词里、时灵时不灵的叮嘱，变成了一个可以读取、可以更新、可以核对的东西。

这里我想留住一个分寸，因为它很容易被做过头。关键其实不是那张记录知识的表，而是它背后那条不变量：人物可以靠偷听、推理、被骗、被人告知去拿到新信息，怎么拿都行，越有想象力越好；但任何新知识都必须有来源。把要求写成“每一处新增的认知都要能追溯到本章的某个事件”这样一条可检查的规则，比规定人物每一步该怎么走要有力得多。前者守住了故事的自由，后者会把人物的自由一并管死——Agent 是更听话了，故事也跟着僵了。

补上状态还不够，它必须真的进到创作链里去。写章之前，系统从那份唯一可信的故事状态里，把这一章需要的上下文组装出来；生成时，模型可以自由设计人物怎么获得新信息；生成之后，检查器把正文里“人物已知的事实”和写作前的状态做个差，要求每一处新增都能追溯到本章的某个事件；这一章确认之后，新的知识状态才被写回去；如果之后还要让 Opus 做文学化的重写，我还得再查一遍，这次润色有没有悄悄改动了信息揭示的顺序。否则那份状态表，就只是又一本认真维护、却从不参与决策的设定集。可靠不是因为某个文件“存在”就有了，而是因为状态在正确的时刻，真的参与了行动和验收。

这条链看起来很麻烦，它确实麻烦。修流程比修内容慢得多——改一句话是几秒钟的事，补一层状态、再把它接进生成前的组装和生成后的检查，搭起这样一套机制可能要花掉大半天。所以“先修流程”并不总是划算：如果一个项目已经接近结束、这类错误往后也没剩几次机会再犯，那花半天去搭一套机制往往就是浪费，直接改掉当前这个结果反而是对的。修流程的回报是复利，而复利需要时间去兑现；剩下的工作越多、这类错误越密，修流程才越值。当交付紧迫时，先修好当前的结果、把后续该做的改进记录下来、等有余裕再补上，也是一种诚实的工程决定，而不是偷懒。

时间线的问题可以拿来做第二个例子，因为它的解法形状和知识状态很接近，只是换了个维度。人物的年龄、季节、事件的先后老是对不上，一章一章单独去调，总有漏网的。真正缺的，是一个统一的事件时钟：每个关键事件都挂在一个明确的时间点上，写新章之前先对钟，写完再核对新提到的时间有没有和已有事件打架。你看，又是同一个套路——把一个反复出错的隐性约束，变成一个显式的、能在正确时刻被读取和检查的状态。这两个案例其实共享同一套有限的机制：在不同维度上，把隐性约束显式化，再把它接进生成前后的组装与检查。它更像一门“怎么让一类错误更难再犯”的通用手艺，而不只是关于写小说的某个小技巧。

也不是每次不满意都值得去动流程。一个偶然的措辞错误，直接改可能最省事；只有同类问题反复出现，才值得更新流程；错误牵扯到会持续变化的世界事实，才该补一层状态；验收长期发现不了的东西，才该去改验收；要是流程本身已经严到把所有章节都压成同一个模子里刻出来的东西，那反而该删规则、放松约束。流程不是越多越好，它只是另一种代码，一样会有 Bug，一样会欠债，加得太随手，几个月后自己都读不完。

先修流程，也可能修错流程

这里还有一个方向相反的常见错误：太急着修流程，结果修错了流程。看到一章出问题，就立刻把它抽象成一条规则写进去，比如“以后所有反派都不许在登场那一章就暴露动机”。这条规则常常是从一个样本里过度归纳出来的，它压掉的不只是那次的毛病，还有一大片本来合理的写法。修流程的诱惑在于它显得更聪明、更一劳永逸，可一条从单一样本里长出来的规则，和一个只改了一句话的补丁其实一样脆，区别只是前者会连累后面很多章。

所以在动流程之前，值得先问一句：这到底是一次意外，还是一类模式？判断的办法很土——回头翻，看同一种毛病是不是在不同的人物、不同的情节里反复出现过。只出现过一次，那大概率是个样本，直接改掉就好；换着花样出现过三四次，才值得停下来，去补那个缺失的状态或不变量。把一次偶然当成一类模式去修，和把一类模式当成偶然反复去补，是两种方向相反、但一样费钱的浪费。

还有一类坏章，根本不是流程能救的。有时候一章读着别扭，不是因为人物越权、也不是因为铺垫不够，而是作者本人还没想清楚这个故事到底想干什么、这条线到底要把读者带去哪里。这是目标层的问题，补再多状态表也没用，它只能靠人坐下来重新决定。这正是我想守住的一条边界：流程能让我不再重复犯同一个错，但它替我决定不了什么值得写。把一个“我没想清楚要什么”的问题，硬塞进流程去修，最后只会得到一套非常严谨、却在解决错问题的流程。

而且流程起效这件事，短期内往往看不真切。补一条不变量之后，可以立刻验证的部分是：历史里那批同类错误，检查器现在能不能扫出来。但“新章不再复发”这种好处，得再写很多章才显出来，中间常常很难分清，是流程真的起了作用，还是这几章恰好好写。这也是不该太快为一次改动庆功的原因——它是不是真的改变了下一轮，得让下一轮自己说话。

所以“先修流程，再修内容”对我来说不是一句口号，而是一个可以验证的动作。修完流程，我至少得能回答三个问题：过去那批同类错误，现在能不能被自动检查出来；新写的章节，同样的错误还犯不犯；以及流程会不会因为管得太严，把正常的创作也一起掐死了。修内容只解决当前这一章，修流程才让同类错误更难再犯，而把那个旧错误正式收进回归案例，才算真正确认新流程有效，而不是我的一厢情愿。

回到那个贯穿全文的问题：修完这一章，什么被留下来了？如果我只改了那一句话，留下来的就是一句更通顺的话，仅此而已，下一章我还得从头再来。如果我补上了那层状态、那条不变量、那个检查，留下来的就是一个会改变下一章生成方式的东西。这两种修都得做，只是回报兑现在不同的时间：改内容，收益在今天；改流程，收益在以后每一个类似的今天。

二、我后来发现，程序员一直在做这件事

把这套想法带到写小说之外，我发现它一点都不新。程序员做了几十年的事，本质上就是“先修流程，再修内容”，只是没人这么叫它。

写代码，表面上是在写函数、接口、页面。往深一层看，是在把一个含糊的愿望，翻译成一条可以反复执行、每次都算数的信息流。“用户应该能够登录”这句话里几乎没有确定性：密码会输错，令牌会过期，网络会断，数据库会超时，同一个账号可能在两台设备上同时刷新。程序员要做的，是把这些含糊情况一个一个拆成数据、状态、分支、超时和错误处理，让系统上线之后，遇到某种输入就走某条约定好的路，而不是每次都听凭运行时的偶然。

我们通常把这叫“实现需求”。这个说法没错，只是把最值钱的那部分说轻了。程序员真正交出去的，是一个承诺：在划定的范围里，事情会按照可预期、可检查、出了问题能追查的方式发生。测试工程师不是为了证明写代码的人粗心，而是把“我觉得没问题”换成一组外部证据；运维搭监控、做灰度、留回滚，也不是喜欢把上线搞复杂，而是不想让一个故障在没人发现的地方持续扩大。往远处看，财务制度、法律合同、医院的检查清单、飞机起飞前的检查程序，做的都是同一件事：把现实里那些含糊、易错、会遗忘、会心存侥幸的人类行为，压成一套能对结果负责的东西。

所以代码从来不只是聪明的展览，它是人类生产“可依赖性”的一种媒介。软件工程也从来不假设每个人永远清醒、每个判断永远正确，它假设人会忘、会误解、会赶时间，机器会坏，网络会抖，需求会变，然后用类型、测试、事务、权限、审查、监控和回滚，把这些不确定性关进一个能承受的范围里。它本质上是一门管理不确定性的手艺。

有意思的是，一旦从这个角度看，程序员交付的东西其实一直在往上走。最早，修一个 Bug 交付的是一个补丁；后来我们发现，光交补丁不够，成熟的团队还要交一个“以后这类 Bug 更难再发生”的机制——一个回归测试，一条断言，一次对设计的修正。这跟我在小说里做的事是同构的：改那一句越权的话是补丁，补上知识状态和检查才是机制。名字不一样，动作是同一个——都是从修一个结果，往修产生结果的东西上挪。而且这个挪动本身就在回答本文那个问题：交补丁，下一轮什么都没留下；交机制，留下的东西会替你挡住下一批同类错误。

值得说清楚的是，这不意味着代码不重要了，恰恰相反。当 Agent 能真的去动数据库、发邮件、改分支，代码所划定的边界比以前更要紧了，因为一个错误动作现在能造成真实后果。变的不是“要不要写确定的东西”，而是确定的东西被写在了哪一层：以前主要写在控制流里，现在还写在状态、工具契约、权限和验收里。

我原本以为，Agent 来了，这件事会被推翻——毕竟模型可以自己想办法，好像不再需要我们把每一步都写死。但真正发生的事更微妙。

很多规则驱动的自动化，是把路径提前写死：在设计阶段就把该走的每一步、每一个岔路尽量枚举出来，运行时留给机器的选择很少。当然，搜索、自适应控制、带反馈的工作流这些“运行时再决定”的做法早就存在，并不是 Agent 才发明的。Agent 真正不一样的地方，是把更多“选哪条路”这种开放式的行动选择，交给了模型在运行时来做。修一个线上问题，它这次可能先看日志，下次可能先复现，再下次可能先比对最近的改动。路径是活的。它的价值来自这种自由，它的风险也来自同一种自由——你没法一边指望它处理你没预料到的情况，一边又假装它还是那段每次都走同一个分支的老代码。

这很容易被误读成“人类终于可以不管确定性了”。恰恰相反。人的工作没有离开确定性，只是从“确定每一步”挪到了“确定目标、边界和验收”。我不再规定 Agent 每一步怎么走，但我必须比以前更清楚地规定：它要到哪里去，哪些地方是绝对不能碰的红线，能用哪些工具，以及凭什么算它到了。自由被放到了路径这一层，确定性被抬到了目标和验收这一层。

这里我想借一个词，但得小心地借。路径变活，意味着系统在运行时存在一个真实的“可能性空间”：一个模糊任务可以有很多种解释、很多条路、很多个结果。它至少有几层不同的不确定。一层是它一开始未必知道问题出在哪，也未必拿到了全部信息；一层是完成目标可能有好几种行动顺序；一层是同一个模型对同一个任务也可能给出不一样的方案，成功率并不是百分之百；还有一层最危险，某个看起来挺合理的动作，可能造成很难挽回的后果。传统代码倾向于在设计阶段就把前面几层尽量消化掉，Agent 则把一部分搜索留到了运行时。

我有时会用“熵”来描述这种可能性的多少——可能性多就说不确定性高，上下文和规则不断排掉不合适的选项就说系统在收敛。但这只是个工程比方。严格的信息熵需要明确的随机变量和概率分布，我没法真给一段提示词算出一个小数点后三位的熵值，谁要这么说，多半只是在给直觉套一个精确的外壳。

而且“降低不确定性”本身也很容易变成一句漂亮的废话。一个永远回答“一切正常”的监控，非常确定；一个每次都把税率算错、但每次都错得一样的脚本，也非常确定。确定不等于对，一台稳定输出错误答案的机器，只是稳定地错着而已。工程的目标从来不是让一切都别变，而是让概率尽量压向那些正确、可接受的结果，把灾难性的结果挪出行动空间，同时留下解决问题真正需要的那点弹性。对写小说也是一样：人物不能越权知情、时间线不能自相矛盾，这些是该压掉的乱；但一个冲突可以怎么解、一段情绪该用什么语言、一次反转怎么避开读者的预期，这些是该留住的活。要是把后者也写成一条条死规矩，Agent 是会更稳定，只不过稳定地重复出同一种写法。

想通这一层，我又忍不住把它往人身上套了一下——毕竟我自己就是那个在“模型”和“流程”之间来回切换的人。

一个很朴素的观察是：同一个人，换个场景，表现可能像换了个人。我们习惯把能力当成随身携带的东西，像身高一样贴在人身上：做成了就说他能力强，做砸了就说他不行。这个解释太方便，方便到几乎没解释什么。我更愿意把实际表现看成一套系统的输出，这套系统里至少有人、任务、工具和环境四样，脑子只是其中一个变量——任务是什么结构，人带着什么先验，现场准用哪些工具，信息够不够，反馈快不快，都会改变结果。

举个假想的例子。两个人第一次玩同一个陌生游戏：规则若建立在概率上，受过概率训练的人在某些规则和条件下可能更容易看懂；规则若靠歧义和叙事，常年跟文字打交道的人往往更快上手——这是关于机制的假设，不是关于人群的定律。两个人都是头一回玩，却谁都不是空手进场——“没做过”并不等于“没有相关经验”，人会把旧经验压成一些可迁移的结构，再拿去啃新问题。

阅读经验较多的人在某些表达任务中可能更有条理，一种可能原因是内化了一些思维工具：把概念定义清楚，把相关和因果分开，给结论加上适用范围。像“幸存者偏差”就是一小段压缩好的推理程序——它把“赚到钱的、活下来的、平安飞回来的”这些零散现象，压成同一个问题：那些没被你看见的样本，去哪儿了？一个好概念不只是起了个名字，还顺带塞给你一段现成的推理；思考框架再把这种压缩变成行动的顺序，让人把目标、假设、资源、执行和外部变化分开，一项项找证据，而不是在几个原因之间乱跳。

我说这些，不是要论证谁比谁聪明。我想说的是：让一个头脑变得更可靠的，往往不是它当场有多灵光，而是它随身带着哪些工具、身处什么样的环境、拿得到什么信息。工具还会重新分配差距——给两个人一台计算器，心算快慢就不重要了，但“该把哪些变量放进模型、结果该怎么解释”这层差距会被放大；这跟模型的处境几乎是一回事。同一个模型，塞进不同的运行环境里，表现可以差得像两个东西：只有一个聊天框时，它是个顾问；接上终端却没有任何边界时，它是个偶尔能干活、随时可能闯祸的风险源；配上状态、工具、权限、反馈和验收之后，它才开始像一种可以运营的能力。

压缩也会压错

不过得给“工具让人更可靠”加个刹车：压缩既能帮你，也能坑你。一个见过太多竞争条件的工程师，可能看什么故障都像竞争条件；概念是压缩算法，压缩就会丢信息，丢错了信息，你会非常自信地看错。工具也一样：搜索引擎让找资料变容易，也让“该搜什么、信哪条、漏了什么”变得更要命；一个替你精简好上下文的 Harness 很方便，但它精简掉的，也可能正好是这次最关键的那一段。工具从来不是白拿的，它替你省下一层判断，同时把新的责任推到更高一层——真正的问题不是“要不要用工具”，而是“用了之后，我的注意力该被逼去哪儿”。

这也顺带解释了，为什么“确定性没有消失，只是换了位置”是这一节最想说的话。过去我们靠把路径写死来换确定性，代价是路径僵硬；现在我们把路径放活，代价是必须在更高的层次上——目标、边界、验收、反馈——重新把确定性建起来。哪一层都不能真空：你在路径上松了手，就得在验收上收紧手；你在验收上偷懒，路径的自由立刻变成失控。一个只在路径上放权、却没在验收上补课的系统，不是更自由，只是更容易在没人看见的地方出事。

再把它拽回本文那个问题：这一轮做完，什么被留下来了？如果我只是当场靠某个概念或某个工具灵光一现地解决了问题，那留下来的只是一次表现；如果我把这次用到的判断，沉淀成一条不变量、一个检查、一段说清楚了适用边界的经验，那留下来的就是一点能改变下一轮的东西。人和模型在这一点上有个共同的结构：真正积累的不是“这次会了”，而是“把这次的会，变成了下次不必重新学的东西”——尽管这只是有限的类比，人的认知、动机和成长，并不等同于模型或 Harness 的一次更新。这也正是“修产生结果的东西”的意思，是程序员几十年来一直在做、只是没停下来命名的那件事。

三、出错时，先别急着换一个更强的模型

一个 Agent 没把事情做成，最省事的结论是：“这模型不够强，换个更聪明的。”这句话经常是对的，也经常没什么用，因为它的信息量太低。

一次失败很少是一个干净的答案，它更像一条链子。任务没做成，可能是模型能力真的不够，也可能是目标写得太含糊，是它拿到的上下文缺了关键的一段，是工具的说明把它带偏了，是权限不够，是运行环境出了岔子，是中途把状态弄丢了，也可能是那个负责判断“做完没有”的验收，压根没在检查真正要紧的东西。这么多环节，任何一环出问题，最后都会表现成同一件事：结果不对。如果每次都归到“模型不够强”，就像一家公司每出一次事故都决定去招一个更聪明的人。偶尔管用，长期很贵。

举个工程上的例子。这里先假设一个 CI 场景——它只是我为了讲清楚而虚构的例子，并不是前面 NVIDIA 与 LangChain 那个官方 Nemotron 案例里的真实情形。给 Agent 一个任务：“让挂掉的持续集成重新通过。”它改了几个文件，宣布搞定了，可流水线还是红的。只看这个结果，它像个能力不行的模型。但把它这一趟到底做了什么摊开来看，故事可能完全不一样。

也许系统只把日志的最后二十行喂给了它，真正的错误堆栈早被截掉了；也许测试命令默认在一个错误的目录里执行，返回的是 No tests found，退出码却是 0，于是它径直判定“全部通过”；也许任务里只写了“让它通过”，没写“不许删测试”，它就把碍事的测试删了；也许那个验收器只看进程有没有正常退出，根本没数到底跑了几个测试；当然，也可能上面这些系统条件都大体正常，它就是反复看不懂同一段并发逻辑。但只有先把前面那些明摆着的系统缺陷排除掉，我才更有把握说：好，这回确实是模型自己没想明白。

这就是“轨迹”的用处。它不是为了满足我偷看机器怎么思考的好奇心——我这里说的轨迹，只指那些看得见的东西：它收到了什么输入，调用了什么工具，工具实际返回了什么，状态怎么变的，它给出的显式决策摘要是什么，不包括模型藏在里面的思维链。有了这条记录，失败就不再只是一盏红灯，而是一条能被顺藤摸瓜定位的链子。

排查是有顺序的，这个顺序还挺重要。先问目标和验收清不清楚，再问必要的事实到齐了没有，然后查工具、权限和环境，接着看它的策略，最后才在同样的条件下比不同的模型。这么排不是为了替模型开脱，而是因为上游的毛病会污染下游的判断：模型压根没拿到关键日志，你却在研究它为什么没推理出根因，这等于在错误的实验条件下做实验，条件错了，再仔细也得不到可信的结论。

关于“先别急着换模型”，我看到过一组挺说明问题的公开案例，就是前面那场对谈同时放出来的材料，2026 年 7 月公开。NVIDIA 的官方说明里讲得很清楚：这次的改进没有重新训练模型，增益全部来自模型周围那一圈环境的工程调整。

具体的数字在 LangChain 的原始案例里。在他们自家的 Deep Agents 测试集和当时那套配置下，团队没动 Nemotron 3 Ultra 这个模型本身，只调了系统提示、工具描述和中间件，就把典型运行的分数从大约 0.80 提到了大约 0.84，最好的一次到了 0.86，已经很接近 Opus 4.8 最好成绩的 0.87；而完整跑一遍评测，前者的成本大约是 4.48 美元，Opus 4.8 大约是 43.48 美元。这里必须把话说全：这是特定评测、特定模型、特定 Harness 和特定配置下的第一方结果，成本还会随着精度、供应商和提示缓存而变，绝不能被读成“提示词能让任何一个弱模型追平任何一个强模型”。真正值得学的，不是那 0.01 的差距，而是他们把问题拆开的方式。

这个案例里我最喜欢的一个细节，跟分数无关。模型在读一个大文件时，只读了第一页，就以为已经到底了。直觉的修法是把“这个文件可能还有下一页”写进 read_file 这个工具的描述里——结果没用。真正管用的，是当 read_file 恰好返回满一页、文件可能还有后续时，把同样一句话追加到那一次 read_file 的返回结果里。同一句提醒，写在工具的说明书里没人理，贴在这次返回的结果旁边，模型就更容易接着往下读。所以问题从来不只是“信息对不对”，还有“信息在什么时刻、以什么形式，出现在它当前这个决策旁边”。注意，这不是说长期的系统提示没用，而是说位置和时机也是内容的一部分。这一点人也一样：公司规章里明明白白写着“大额退款要先审批”，也不等于一个正在手忙脚乱处理退款的人，会在那个当口想起这一条。规矩写在那里，和规矩在关键时刻真的生效，中间隔着一整段距离。

我把这一整套东西——喂给模型的上下文、给它的工具、帮它记住的状态、限制它的权限、判断它做完没有的验收、失败后的重试和回滚、还有全程留下的轨迹——统称为 Harness。它不是给模型套的一个壳，也不是“提示词”这个词的华丽版本。它是那套让活的路径不断收敛到可交付结果的装置：模型负责提出和挑选行动，Harness 决定它知道什么、能做什么、什么时候必须停、凭什么算做完。同一个模型放进不同的 Harness 里，能交付出来的结果可以明显不同——这也正是上面那组数字想说的。

而 NVIDIA 的那篇技术教程，把整个改进过程写成了一个很朴素的循环：跑一遍评测，盯着失败看，做一个最小的改动，再重复验证，好就留下、不好就回滚，最后跑一遍完整回归。它特别提醒：单次通过不算数，因为模型调用和一部分评测本身就带随机性，一个改动得连续通过、而且不能把别的任务弄坏，才算真的有用。这跟我在小说里想做的事几乎一致——只不过是把“评测”换成“拿历史的错误章节回测”。

这个循环里，我觉得最反直觉、也最容易被跳过的，是“一次只改一个环节”和“单次通过不算数”这两条。人在看到失败的时候，本能是想一口气多改几处，好像改得越多越显得在认真干活；结果一旦分数变好，你根本说不清是哪一处起了作用，下次也没法复制。而随机性又让“改一次、过一次”极具欺骗性——它可能只是这一次运气好。所以真正的纪律是逆着本能来的：改得尽量少，测得尽量多。这跟做实验、跟第四节要讲的学习，是同一套东西。

也有一种情况，是盯着轨迹反复看，还是分不清到底是流程的问题还是模型的问题。这很正常，别硬猜。这时候最干净的办法是做一次受控比较：把其他条件全都固定住，只换模型，跑同一批任务。如果换了更强的模型、别的都没动，成功率明显跳上去，那多半真是能力边界；如果换了模型几乎没变化，那问题就大概率不在模型，而在它周围那圈我还没修的东西。不过就算是这种受控比较，也得跑足够多的样本、重复几次，并且顾及模型和 Harness 本来未必匹配——别拿一次结果就下强因果的结论。让证据说话，比让直觉抢答，慢一点，但省得多。

这里还要防一个误会：把失败看成一条系统的链子，不等于从此没人需要负责。恰恰相反，系统归因是把一句含糊的“你不行”，摊开成一张具体的责任地图。写代码的人要解释自己当时为什么那么判断、有没有守住已有的约束、发现苗头有没有上报；设计验收的人要为“验收标准是不是真对着目标”负责；维护工具的人要为“接口是不是按说明在工作”负责；组织要为“高风险的动作有没有该有的复核”负责。责任没有消失，它只是从“谁犯了错”，变成了“谁该去修哪一层，好让这类错更难再犯”。对 Agent 也一样——我不能因为把活儿交给了模型，就顺势把后果也一起交出去。更何况，经营和法律上的责任并不会因为动作是模型做的就自动转移给模型；它具体落在谁头上，取决于相关人员和组织的角色、所在的司法辖区，以及具体的应用场景。

当然，Harness 是有上限的。如果模型压根不具备理解某段复杂逻辑或某个专业领域的能力，再优雅的中间件也变不出那部分知识；反过来，如果目标含糊、工具错误、上下文缺失、验收失真，换一个更贵的模型，也可能只是让它更聪明地替一套烂流程兜底。所以模型和 Harness 更像一条乘法链：模型决定这套系统理论上能到哪儿，Harness 决定它能不能在真实环境里反复到达，而最弱的那一环，往往决定最后交出来的到底是能力还是事故。

换个更强的模型，有时候会把毛病盖住

我说“先别急着换模型”，不是说永远别换。有时候真的就是模型不够强，那该换就得换。我想拦住的是另一种更常见、也更贵的情形：用换模型来掩盖一个本来该修的流程毛病。

设想一个很典型的场面：一个任务，弱一点的模型总在同一处失败，你一咬牙换上最强的模型，它勉强把这一处过了。表面上问题解决了，可你什么都没学到，而且你把那个真正的毛病——比如上下文里少喂了一段、验收根本没在查关键条件——连同账单一起，藏进了一次侥幸里。等下次任务量一大，或者哪天你想把这类活迁回便宜模型，那个被盖住的毛病会原封不动地跳出来，只是这次你已经忘了它长什么样。更强的模型容错更高，这本是好事，但它也会把系统里本该暴露的问题掩盖过去，让你误以为一切都没问题。

所以我给自己的顺序是：先在当前模型下，把能查的系统条件都查一遍、修一遍；只有当目标清楚、事实到齐、工具和验收都没毛病，它还是稳定地做不成，我才认定这是模型能力的边界，去换更强的模型或者干脆换个做法。这样换上来的强模型，解决的是一个已经被理解清楚的难题，而不是替一堆没查过的旧账背锅。

这也是轨迹除了定位之外的第二个用处：一次被解释清楚的失败，可以直接变成一个回归案例留下来。它不再只是“这次没成”，而是“这一类会在什么条件下失败”的一个样本。下次不管我改了流程还是换了模型，都能拿这批旧案例回测一遍，确认新方案没有把老问题放回来。失败没被解释，它就是纯亏损；失败被解释、被留下，它才开始给下一轮攒本钱。

回到那个问题：一次这样的排查做完，什么被留下来了？如果我只是换了个更贵的模型把流水线变绿，留下来的就是一次侥幸和一张更大的账单，下次照旧。如果我读懂了失败、把它归了类、做了一个最小的改动、还用回归确认它没帮倒忙，留下来的就是一点能改变“下一轮成功概率”的东西。它改的不是这一次运行，而是这一类任务往后是成还是败的倾向。

四、重复不是学习

有一件事我想得越久越确信：做得多，不等于经验多，它只能证明经历多。

一个人可以做十个失败的项目，每次都把原因归给运气；也可以在十段关系里重复同一种沟通方式，然后宣布自己见多识广。样本数确实涨了，但脑子里那套判断，一个参数都没更新。我觉得“经历”和“经验”最干净的区别就在这儿：经历是进了系统的数据，经验是这些数据经过反馈校正、归因和抽象之后，真的改变了系统下一次的预测和行动。如果下次遇到类似的情况，你的判断、选择、做法都跟上次没有两样，那上次留下的更像一个故事，不一定是一条经验。

经验还得经过一次压缩才好用。只记住“某年某月某件事搞砸了”，那只是存了一条记录；能说出“在哪些条件下，哪一种假设最容易失效”，才有机会迁移到新场景。压得太少，经验只能用在原题上；压得太多，又会变成“做人要谨慎”“项目要多沟通”这种永远正确、因而没什么用的话。一条好经验，既得有规律，也得带着它的适用边界。

要让经历变成经验，有一步特别关键，就是事前得有个预测。没有预测，任何结果发生之后，我们都能编出一套听起来很合理的解释。项目成了，是团队执行力强；项目黄了，是市场没教育好。同一套话对所有结果都成立，说明它根本没承担过预测的风险，也就拿不到现实反馈给它的那一记误差信号。比较有用的做法，是在动手之前先把话说死，比如：“人物反复越权知情，是因为生成时没注入知识状态。”然后只改这一处，拿过去的错误章节和新写的章节分别去测。同类错误明显少了，假设就获得支持；没变化，就接着往上游找，是不是上下文被截断了，是不是状态更新失败了，是不是检查器压根没在看这个。

这里还藏着一条纪律：一次最好只改一个变量。要是我同时换了模型、重写了提示词、加了上下文、又调了工具，结果变好了，我也只知道“这一大包东西里可能有点用”，却说不清是谁起的作用。这比继续失败让人愉快，但几乎没留下什么能迁移的知识。控制变量不是实验室的洁癖，是为了让反馈能回答一个具体的问题。这跟精益创业里那句“经过验证的学习”其实是一回事：不断地做东西不叫学习，每一次动手都对应一个待验证的假设、每一次测量都能改变你对假设的信心、每一次都真的进了下一轮，才叫学习；否则动手和测量都很热闹，真正学到、并沉淀下来的东西却几乎没有。

想清楚这一点，“有循环”和“会学习”就不是一回事了。“失败、再试、再失败、换个说法再试”当然是个循环，但它只是在原地打转。真正的学习至少得有这么几步：事前给个预测，动手后看结果，把结果和预测比一比，判断误差是哪个假设错了，抽出一条可能能迁移的规律，改掉下一轮的做法，再拿新样本去验证这个改动到底有没有用。记忆、归因、更新、验证，少哪一样，循环都容易变成空转。

按我这里搭的框架，一个成熟的系统里，这样的循环其实同时在三个不同的尺度上转，而且各自问的问题不一样。

最里面一层，是“这一件事做完了没有”：写一章，检查人物一致性和节奏，改到达标为止。它只关心眼前这个样本。中间一层，是“为什么这一类事总在同一个地方栽”：假设把十几章的共同毛病收集起来，可能会发现反转总是没劲，不是因为句子不够狠，而是前面的压制和代价一直不够，于是要去改章节的设计流程。它关心的是往后一批章节的成功率。最外面一层，是一个更冒犯的问题：“我是不是在很可靠地做一件根本没人要的事？”哪怕每一章都过了我自己的检查，也可能没有读者愿意追下去。这一层得把真实世界的选择、留存和反馈拉回来，重新审一遍：这个目标本身，值不值得追。

这三层缺一不可，用的证据也不同。只有最里层，Agent 这次靠重试蒙对了，下次还从头错起；只有中间层，我可能把一套没人需要的流程打磨得极其顺滑；只有最外层，没有稳定的执行和内部诊断，每次拿到的反馈里又混进太多变量，最后只剩一句万能的“读者口味真难猜”。里层靠的是测试、改动和当前状态，中层靠的是一批案例的失败分布和回归结果，外层靠的是真实的选择、留存、付费和访谈。拿“所有检查都通过了”去证明产品有价值，或者拿“有个读者说好看”去证明流程稳定，都是把不同尺度的证据搅在了一起。循环不光要转，还得知道自己这一圈到底在回答哪个问题。

这三层循环，最后都压在同一件事上：验收到底在看什么。验收不是最后盖的那个章，它是整个学习系统的感官；感官错了，系统只会非常勤奋地朝错误的方向进化。如果我只检查“每章有没有反转”，那套流程很快就会学会机械地制造反转，人物、期待、后果全都不管——它没在学怎么写好看，它在学怎么讨好我这个坏掉的评分器。低质量的反馈不会让系统停下来，它只会让系统稳稳地学偏。所以经验积累不只要求更多数据，还要求反馈接近真实目标、归因能分清变量、结论写明适用边界。

而反馈本身也得挑。不是每一次波动都值得写回系统：反馈里混着信号，也混着噪声，如果我对每一条读者评论、每一次分数抖动都认真更新一版流程，最后得到的不是一个会学习的系统，而是一个被最近一条反馈牵着走的系统——它今天为一个嫌“节奏太慢”的读者加快推进，明天又为一个嫌“太赶了”的读者放慢，两条规则在流程里打架，谁也不知道该听谁的。所以学习的前提，除了有反馈，还得能分清哪些反馈值得写回：一条只出现过一次、又跟别的信号对不上的意见，更可能是噪声，先记下来，别急着改流程；一种在不同读者、不同章节里反复出现的模式，才是信号。这其实又回到第一节那句话——先分清是一次意外还是一类模式，只不过这次的对象从“错误”换成了“反馈”。

但我也得给“什么都要建循环”泼一盆冷水。建一个中层循环是有成本的：收集轨迹、给失败分类、维护一套回测，这些都要花时间，而且它们本身也会变成需要维护的东西。对一件只做一次、以后基本不会再碰的任务，认真去搭一套改进循环，是另一种过度工程——你为一个不会有“下一轮”的东西，去优化下一轮。判断的标准还是那个贯穿全文的问题：这件事会不会有下一轮，下一轮会不会因为我现在多做的这点功夫而变好？要说清楚的是，哪怕一件事本身只做一次，它也可能留下能迁移到别的任务上的经验；只有当它既不会重复、又实在榨不出任何可复用或可迁移的价值时，专门为它搭一套改进循环才可能得不偿失。真到那种情况，把它一次性做完、别恋战，反而是对的。学习是给会重复、或至少能迁移的事准备的。

这也顺手接上了下一个话题。上面这些循环——多跑几次看是不是稳、控制变量做比较、拿一批案例回测——全都不便宜，它们要花的是实实在在的调用次数和钱。所以一个系统能不能真的转起来学习，很大程度上取决于它转一圈要花多少成本。成本低到什么程度，直接决定了你舍得做多少实验、观察多少样本、允许多少次失败。这就把我带到了最后一个问题：钱。

五、把一次昂贵的调用，变成下一轮的资产

模型越来越便宜，最容易被当成一个采购问题：同一件事，原来要花四十多美元，现在花四美元多，财务应该松口气。前面那组数字里，完整跑一遍评测，一边大约 4.48 美元，一边大约 43.48 美元，差了差不多十倍。但对一套要长期运转、还要不断学习的系统来说，便宜带来的更要紧的变化，不是把原来的流程用更低的价钱再跑一遍，而是让原本舍不得做的实验，忽然做得起了。

便宜首先买到的是观察。样本多了，我才分得清一次成功到底是稳定的能力还是一次好运，一个改动到底是真的提升了整体，还是只讨好了手边那个案例。其次买到的是比较：同一个任务，可以换不同的模型、不同的上下文组织、不同的停止策略，各跑一遍看看。规模化的部署反而排在最后——连系统为什么会成功都没搞清楚，就先把调用量放大十倍，通常只会得到规模大十倍、但一样看不懂的现象。把生成次数翻十倍，不会自动带来十倍的经验，往往只带来十倍规模、却一样看不懂的输出。所以真正值得算的，从来不是单次调用的报价，而是“每完成一件成功的任务”总共花了多少——把推理费、工具和环境、自动评测、人工复核、重试、失败善后，还有错误万一溜进现实要付的代价，都算进去。打个假想的账：一个每次四美元、但成功率只有三成、还得人反复收拾的模型，未必比每次十美元、九成一次过的模型便宜。模型的报价只记录它收了多少钱，不会记录人为它多付出了多少额外工作。

昂贵的智能探索未知，便宜的智能规模化已知

顺着成本，还能看清另一件事：不同的智能，该被放在任务生命周期的不同位置上。

一个任务刚冒出来的时候，问题本身往往还没被说清楚：要哪些输入，最常见的意外是什么，工具该怎么搭，什么样的结果才算好，很多都还是未知的。这时候 Harness 还很薄，很多判断只能在运行时临场做。本文的推论是：在这种阶段，用更强、也更贵的模型在安全边界内去探这个上限通常是划算的——让它生成几条可能的路，暴露出几种事先没料到的意外，把最初的验收标准立起来。但如果这台昂贵的智能每次都从头解决同一种问题，那组织其实没在学习，只是在一次次重复购买同样的解决方案。真正划算的做法，是让每一次高成本的调用都留下点东西：一条验证过的成功轨迹，一类新的失败，一个工具改进，一条边界规则，一组验收样例。等这个任务反复出现、边界慢慢清楚了，这些东西就能固化进流程，交给更便宜的模型去跑高频的那部分。

这等于把运行期的昂贵推理，前移到了设计期。第一次解决未知问题要花很多判断；往后就不必每次都重新发明方法，让系统读取已经沉淀下来的结构就行。强模型负责把未知变成已知，便宜模型负责把已知规模化，这不是谁高谁低，是分工。一个成熟的路由甚至可以先让便宜模型试：验收过了，任务就完成；没过，允许有限次重试；反复失败，才升级到更强的模型；还是拿不准、或者动作风险太高，就交给人。当然，真实的路由不会只按成本和成功率来分，它还得受隐私、数据驻留、许可、兼容性和合规这些约束的限制。强模型或人解决之后，这个案例又进了失败库和回归集。随着流程和工具一点点更新，便宜那一层能吃下的范围也一点点变大。这里真正有复利的，不是便宜模型越来越像强模型，而是系统把一次次罕见的判断，慢慢变成了可以重复执行的普通能力。

我怎么分 Codex 和 Opus

在我自己的小说流程里，这种分工很具体。我会分开用 Codex 和 Cursor 里的 Opus。按我目前的实际体验，Opus 更贵，但它主要的长处是把文字表达处理得更文从字顺；Codex 更适合长流程里的文件操作、状态维护、结构分析、连续性检查和反复迭代。与其争论谁“整体更强”，不如问某个环节到底缺什么。人物状态、时间线、伏笔、失败回归这些东西，靠的是结构化的记录、工具调用和持续维护，价值来自可靠、完整、可追踪，我把它交给 Codex。等到情节结构、人物动机、信息揭示的顺序都稳了，再把开头、核心转折、情绪爆发和终稿交给 Opus 做文学化的重写。这样也顺手避开一种很常见的浪费：用漂亮流畅的文字，把结构上的错误包装得更难被发现。

两个工具之间得有一份说清楚的合同。核心事件、人物动机、既定事实、伏笔和信息顺序，是不许动的不变量；句式、段落、描写的密度、节奏和情绪的表达，可以自由调。一种可行的做法是：Opus 重写完，再让 Codex 对着前后两版查一遍——有没有凭空多出来的事实，有没有删掉关键动作，有没有偷偷改了人物的知识边界，有没有把网文的推进节奏润色成了另一种文体。最后仍然得由我来判断那句最要紧的话——它是真的更好，还是只是更顺。模型可以替我查事实有没有漂移，但审美的责任它替不了。生成能力越便宜，稀缺的东西就越往“选择”上挪：什么值得留，什么只是漂亮，什么在局部评分上很高、却伤害了整部作品。答案越便宜，判断答案好坏的能力就越稀缺。如果 Opus 某次改得确实好，一种可行做法是让 Codex 反过来分析：它主要动了句子长度、动作密度，还是视角距离？哪些变化能迁移到别的章，哪些只适合这一章？经过后面几章验证过的规律，才被收进写作流程——这样一次昂贵的润色，买到的就不只是一份终稿，还有创作流程往后的一点升级。

顺着这个分工，还能往前推一步，但我得把它标成推论，不是我的亲身经历：当一个问题陌生、边界不清，但可以放进沙箱、只读环境或者人工审批这样的安全边界里试错时，让更强的模型先去探，是合理的。不过这里有条硬线不能越——高风险本身，不会因为你换了个更强的模型就被化解掉。它依赖的是权限隔离、审批、回滚和人能随时接管，而不是模型的自信。一个模型能写出删库的命令，只说明它学过语法，不说明公司就该把生产环境的密钥交到它手里。

员工薪资这个类比，到哪儿为止

昂贵和便宜的分工，确实很像组织里专家和普通员工的分层：规则清楚、低风险、高频的活，交给标准流程或者经验浅一些的人；规则打架、影响巨大、从没见过的意外，留给资深的人；专家解决完，再把方法沉淀成工具、清单和升级条件。一个高级工程师最值钱的产出，往往不是自己多修十个 Bug，而是让另外十个人以后少犯同一类错。

但这个类比必须及时刹车，它只在成本、专业化、授权和路由这几件事上成立。工资不是智商的检测报告，高薪也不等于一个人在所有场景都更强，薪水里还掺着市场稀缺、地域、权力、议价和一堆历史偶然。更要紧的是，模型之间的路由也不是只按成本一挥而就的，它同样受隐私、数据驻留、许可、兼容性和合规这些约束的限制；而人还会学习、会疲惫、会失去动力，也需要尊严和成长的空间，不能被当成一个按调用计费的 API 来对待。要是永远只让新人处理那些已经完全确定的活，公司会发现自己省下了今天专家的时间，同时取消了明天专家的养成。把人仅仅当成可随意调度的产能，不光让人不适，长期算账也未必划算——人的分工里得留出渐进授权的余地，让人有机会从执行走到判断、再走到设计；模型这一步，现在通常还走不了。

可以像同事一样说话，但要像软件一样治理

说到把 Agent 当同事，这里我想留住整篇文章里最容易被自然语言骗过去的一点。Agent 最让人放松警惕的，不是它能调用终端，而是它会说话——它会解释计划，会说“我已经全面检查过了”，出了错还会道歉，说以后注意。语言让协作变顺，也让我们下意识地把理解、意图和责任心一起投射过去。可是承诺功能看着挺齐全，责任主体却没跟着长出来。

所以“别把 Agent 当同事”不是要人故意板着脸说话，也不是否认自然语言协作的价值，它提醒的是一件很朴素的事：交互界面可以拟人，治理结构不能拟人。Agent 说“完成了”，只是它生成的一句状态声明，不是任务真的完成了这个外部事实。声明不是证据。证据是那些命令到底跑了没有、跑了几个测试、退出码是什么、改动里到底动了什么、原来的问题还能不能复现。这里至少要把三个问题分开：它有没有能力做，系统允不允许它做，以及我凭什么相信它已经做对了。这三样常被一句流畅的话揉成一团——它越自信，我越容易觉得它“应该有分寸”，可智能不是授权，自信更不是证据。

于是要不要让它自动去做一件事，该由这件事的风险决定，而不是由它说话的语气决定：这个动作可不可逆，错了容易不容易被发现，最坏能捅多大娄子。生成一章草稿，随时能丢，可以给它很高的自主度；改正式稿，只要留着版本和差异，风险也有限；创建分支通常可逆，直接合并主干就得先过测试和审批；分析日志可以只读放开，去改生产数据就得走严得多的路子。高风险的动作，最好把“提出方案”和“真的执行”拆开：它先列出计划和要调用的工具，系统空跑一遍，人或策略批准，运行时只给这一次任务发一把临时的、最小的权限，做完再由外部检查确认结果、回收凭证、留下日志。但也别走到另一个极端——要求每个动作都由人点一下同意，看着最保守，其实往往只是表面上的稳妥：它会制造审批疲劳，Agent 退化成一个每一步都要等人点头才能动的工具，人则被迫在大量确认里疲于奔命，点到最后多半只是机械地通过，安全没真的多多少，自动化的价值倒是先被消耗光了。治理的目标不是让它什么都不能做，而是让它的自主权，跟可逆性、可观察性和影响半径对上。

还得再补一句：光说“相信测试，不相信它的自述”其实还不够，因为测试会漏，验收会写错，日志也只记录了系统愿意记录的那一部分。形式上验过了，不代表真正要紧的条件被查过。所以证据本身也得分层、也得能追溯：工具返回的退出码是一层，测试的数量和覆盖是一层，原来的问题修没修好是一层，真实用户或读者的反馈又是一层，各回答各的问题，谁也别越权替谁作证。单元测试全过，证明不了产品有价值；一个读者说好看，也证明不了时间线没矛盾。把一条局部证据抬举成整体结论，是人和 Agent 都特别擅长的一条捷径。

公司真正沉淀的是制度化智能

把这些串起来，我越来越觉得，一家公司真正能长期沉淀下来的，不是某个模型的名字，也不是一摞提示词。提示词太容易复制了，写得再长也不自动值钱。那场对谈里有个判断被推到了台前：往后的公司会越来越多地建立在 framework 之上。我不想把它当成黄仁勋的逐字原话，而是把它当成一个需要解释的命题——公司本来就是一套为人搭的 Harness：岗位规定谁管什么，流程给出常见做法，信息系统保存状态，审批拦住高风险动作，复盘提供反馈。同一个人进不同的公司，表现可能天差地别，往往不是脑子变了，是他能看到的信息、能用的工具、被允许做的事和拿到的反馈变了。Agent 时代的新意，只是这些条件里有越来越多的部分，从写在手册里、留在老员工直觉里，变成了机器可以读取和执行的结构。

这套东西合起来，才是真正在积累的资产，我更愿意叫它制度化智能：业务到底怎么表示，任务怎么拆，哪些工具可信，哪些例外必须升级，什么证据才算完成，错了怎么回滚，谁对后果负责。它比任何单个模型都活得久——基础模型会一直换，今天昂贵的能力明天可能变成普通服务，但一家公司对自己业务的这套表示，是它自己长出来的，通常比一段提示词难复制得多，很难被人直接照搬走。模型决定一次尝试的上限，Harness 决定成功能不能复现，循环决定这套系统能不能随时间变好，治理决定谁能做什么、谁对后果负责。所谓组织学习，不是公司里有很多参加过项目的人，而是某一次判断离开了当事人的脑袋之后，还能让后来的人和 Agent 做出更好的行动。

这也是为什么，两家公司可能都攒了一大堆提示词和文档，值钱程度却天差地别。真正难复制的从来不是那些文字，而是文字背后那些接进了真实业务系统的工具、一直跟着现实更新的状态、被无数次真实失败校准过的验收集，以及“从发现一个错误，到把它变成系统里一条新防线”的速度。前者可以一夜之间拷走，后者是时间和真实教训一点一点长出来的。把“公司越来越依赖 Harness”理解成“公司最后会变成一摞提示词”，恰好是把最不值钱的那部分，当成了全部。

当然，制度化智能不会只朝好的方向长。错的知识也会沉淀，过时的规则尤其擅长沉淀。每次失败都往提示词里加一句，几个月后就是一份又长、又自相矛盾、又没人敢删的文件，模型偶尔会违反它，人根本读不完它，两头都靠不住。所以这套东西既要能加，也要能删，还得时不时地评估它自己：它真的降低了同类错误吗，还是只是在内部指标上越来越好看，现实里却没什么变化？一个只会往里塞、从不往外扔的系统，不叫拥有长期记忆，更像一个只进不出、最后连自己都理不清的仓库。判断哪一部分该固化成流程、哪一部分该留给人的判断，本身就是一件永远做不完的管理工作——因为公司终究还要有人去选目标、担责任、拍那些无法完全形式化的板。

写到这儿，我想安静地回到最开始那一章。

内容修好了，解决的是当前这一章；流程修好了，还会影响下一章，以及下一章之后我还没写的每一章。这就是“先修流程，再修内容”最朴素、也最实在的意思。我最后想留下的，其实不是一个说起话来像同事的 Agent——那部分很容易得到，也很容易被高估。我想留下的，是一套会记住失败、会分配权限、会验证结果、还会更新自己的东西。它让我这次工作结束之后，真正被留下来的，不只是一章更通顺的文字，而是一个让下一轮更容易写对、更难写错的系统。

这大概就是我理解的、Agent 时代的可依赖性：不是求这一次做对，而是让每一次做完，都给下一次多留下一点“更不容易做错”的东西。