当前阅读总时间是：21,076小时

AI 时代，代码会过期，知识不会

这是一份对谈记录。说话的两个人，一个是程序员李文业，另一个是他这一年里几乎每天都在打交道的 AI。谈话发生在他离职的当天。他已经休息了两周，情绪早就从工作里慢慢松脱出来，所以这更像是一次没有明确目的的复盘，而不是一份正式的总结。我们几乎原样保留了对话里的犹豫、跳跃，以及那些没有说完就转向的念头，因为这场谈话真正有意思的地方，恰恰不在最后的结论，而在两个人如何一点点把一个模糊的直觉，谈成一句连他自己都没料到会说出口的话。下面的分节和小标题是事后补上的，其余尽量照原样呈现。

一、离职这天，先聊聊那种轻松

李文业：今天是我正式离职的日子。说来也怪，我以为自己会有点失落，结果没有，更多的是一种轻松。其实我已经在家休息了两周，人早就慢慢从工作状态里解绑出来了。真到了签字这一天，反而很平静。

AI：那种轻松，是因为不喜欢这份工作吗？

李文业：不是。我不讨厌工作本身，甚至有些事情我做得挺开心的。轻松是因为，我终于结束了一段其实并不适合自己的旅程。你知道那种感觉吗，像是穿了一整年不合脚的鞋，脱下来的那一刻，才发现原来一直有点疼。

AI：那如果让你把这一年浓缩成一个最大的收获，你会说什么？我猜大多数人会说完成了几个项目，或者学会了某个框架。

李文业：都不是。真要我挑一个，那一定是，我给自己搭起了一套属于自己的 AI 工程工作流。刚入职那会儿，我只是把 Cursor 当成一个写代码更快的工具，让它补全、让它改 bug，仅此而已。后来我慢慢开始建自己的文档中心，每一个需求都有独立的目录，里面有需求模板、设计模板、测试模板、Review 模板，把整个开发流程一环一环串起来。做着做着我才反应过来，我真正积累下来的不是那些 Prompt，而是一套方法论。

AI：所以这套方法论，最后把你带到了哪个方向？

李文业：它让我第一次对未来有了清晰的判断。我知道自己想往哪走了，Harness Engineering、Agent Coding、人机协作的软件工程。这三个词以前对我是模糊的，现在它们变成了我愿意押上未来几年的东西。这一年别的都可以忘，这个不能忘。

编者注：值得留意的是，他把最大的收获定义成一套“方法论”，而不是任何一个可以写进简历的成果。这也许正是这场对话后面所有推论的起点：当一个人开始把自己积累的东西理解为方法而不是产物时，他看待代码、看待工作、看待自己职业身份的方式，其实已经悄悄换了一套坐标系。

二、最大的遗憾，和三条不肯再让步的底线

李文业：当然，这一年也有遗憾。而且我发现，我最大的遗憾居然不是技术上的，不是哪个项目没做好，是我和 Leader 的工作方式始终没能对上。

AI：怎么个对不上法？

李文业：他的管理风格特别强调结果和效率，什么都看产出、看速度，人文关怀这一块比较少。而我恰好是那种比较敏感、也比较需要信任和尊重的人。我需要有人告诉我方向、给我空间，而不是只盯着交付。这两种气质放在一起，时间一长就会互相消耗。

AI：那你会觉得是他的问题，还是你的问题？

李文业：一开始我肯定往对错上想，觉得要么是他不够体谅人，要么是我太玻璃心。但后来我慢慢想明白了，这根本不是谁对谁错的问题，是匹配的问题。他那套风格放在另一个人身上，说不定特别高效、特别合拍。只是不适合我。想通这一点之后，我心里反而释然了很多，也不怨谁了。

AI：那这份遗憾，有没有变成一点具体的东西留下来？

李文业：有，我给下一份工作定了三条不能妥协的底线。第一，必须有足够自由的 AI 工具使用环境，这是我发挥的前提。第二，团队和 Leader 的管理风格要尊重人，得有基本的人文关怀。第三，工作节奏不能长期透支身心健康。我特别想强调，这不是我要求变高了、变娇气了，恰恰相反，是这一年的经历让我第一次真正知道，对我来说什么才是重要的东西。有些代价，付过一次就够了。

编者注：他很谨慎地把“遗憾”从道德判断里摘了出来，改用“匹配”这个词。这是一种成熟，也是一种自我保护。但这里其实埋着一个没有完全展开的张力：当一个人越来越清楚自己需要什么，他能够将就的空间也就越来越小。这究竟是更自由了，还是更挑剔了，这场对话没有给答案，或许也不该急着给。

三、AI 都能写代码了，为什么还要工作流

李文业：离职这件事聊完，我们后来拐到了一个更有意思的话题上。我一直在想一个问题：为什么 AI 工程还需要那么一整套工作流？直接让 AI 写代码，不就完事了吗？既然它写得又快又好，那些流程是不是纯属多余。

AI：那你自己后来是怎么回答这个问题的？

李文业：我发现我一开始就把问题问偏了。真正的软件开发，从来就不只是写代码这一件事。需求评审、技术设计、测试设计、上线验证、事故复盘，这些东西在还没有 AI 的年代，本来就存在，本来就是人和人之间协作出来的一套工作流。写代码只是这条链子上的一环，甚至不是最难的一环。

AI：也就是说，工作流不是为 AI 发明的。

李文业：对，这就是我想通的地方。工作流一直都在，只不过以前那些文档主要是写给人看的，需求文档给产品和开发看，设计文档给同事和后来接手的人看。现在有意思的地方在于，它们第一次开始同时写给 AI 看了。AI 的加入并没有创造出工作流，它只是让这套原本就存在的工作流，第一次拥有了一个能够真正消费这些上下文的新成员。

AI：一个“新成员”，这个说法挺准的。那这个新成员和过去的成员，最大的不同是什么？

李文业：过去我们写一份设计文档，心里默认读者是人，人会脑补、会问、会凭经验补上没写清楚的部分。AI 不会，你给它多少上下文，它就理解到哪。所以它反而逼着我们把过去藏在脑子里、靠默契传递的东西，老老实实写下来。从这个角度说，AI 没有让工作流变轻，它让工作流变得更诚实了。

四、真正难维护的，从来不是代码

李文业：顺着“上下文”这个词，我们又挖到了一个更本质的问题。过去一个项目最重要的资产，很多时候压根不是代码，而是那些只存在于老员工脑子里的经验。

AI：能不能说得再具体一点？

李文业：你想想那个特别常见的场景。为什么一个核心员工一离职，整个项目突然就没人敢动了？代码明明还在那儿，一行没少。为什么很多老项目的技术债越滚越重，最后谁碰谁倒霉？根子不在代码太复杂，在于上下文丢了。当初为什么这么设计，踩过哪些坑，哪些方案其实被否决过，哪些地方碰都不能碰，这些东西从来没写进代码，它们只活在某个人的记忆里。那个人一走，记忆就跟着走了。

AI：所以你会说，真正难维护的不是代码，是知识。

李文业：对，这句话我现在特别确信。代码是知识的产物，不是知识本身。而 AI 的出现，其实把这个老问题放得更大了。很多人以为有了 AI，交接、维护这些事就不愁了，反过来才对。如果上下文没有被沉淀下来，AI 和那个新来的、什么背景都不知道的同事一样，它照样看不懂这个系统，照样不敢乱改。

AI：那按这个逻辑推下去，未来我们真正要花力气去维护的对象，会不会根本不是代码？

李文业：我越来越倾向于这个判断。以后需要被小心维护、被反复更新的，也许不再是代码这堆字符，而是知识本身，是那套解释“为什么”的上下文。代码只是它投下的影子。

编者注：把“技术债”重新解释成“上下文的丢失”，是这段对话里一次很关键的转向。它意味着技术债不是一个纯技术问题，而是一个知识管理问题。这也解释了为什么很多团队疯狂重构却越还越多：他们一直在修影子，没去修投下影子的那个东西。

五、代码是一次性的，还是越来越值钱

李文业：接着我们撞上了一个看起来自相矛盾的问题。你肯定也听过两种截然相反的说法。一种是，未来代码都是一次性的，AI 一分钟就能重新生成，写完即弃，根本不值得维护。另一种是，未来软件会越来越好维护，越来越像资产。这两种说法听上去完全对着干，你觉得谁对？

AI：如果让我猜，我会说它们可能都对，只是在说不同的东西。

李文业：我们最后也是这么想通的，两句话其实都成立，关键看你说的是什么系统，看它的生命周期和价值。对于那种生命周期特别短的小工具、小脚本、小应用，代码真的可能就是一次性的。因为生成的成本已经低到，重新写一遍比去读懂旧的、再改一遍还便宜。那种情况下，谈维护反而是浪费。

AI：那另一头呢，什么样的系统不适用这个逻辑？

李文业：银行、交易所、支付系统、微信这一类。这种长期系统里，真正值钱的东西从来不是代码。是那些业务规则，是一次次事故换来的经验，是安全策略，是整个组织沉淀下来的知识和上下文。你把微信的代码全删了让 AI 重写，它可能真能给你生成一套能跑的东西，但它写不出那些年踩过的坑、修过的漏洞、和无数真实用户磨出来的规则。代码可以重新生成，知识不能。

AI：所以这两种说法的分界线，其实就是那句“代码可以重新生成，知识不能”。

李文业：对。想清楚这条线之后，很多争论就不用吵了。未来真正被我们当成资产去维护的对象，不再是代码本身，而是一整套知识系统。代码只是这套知识在某一刻的一次编译输出，过期了，重新编译就好；知识过期了，是要出事的。

六、从写得快，到问得准

李文业：聊到这儿，我们又冒出一个新发现，而且我觉得这个是最关键的。AI 极大地降低了表达知识的成本。你想，写代码是一种表达知识，写文档也是一种表达知识，把脑子里想清楚的东西变成别人能用的形式，这个过程 AI 帮我们提速了好几个数量级。但是，它并没有同样地提升我们获取知识的速度。

AI：这两件事的区别，能不能再掰开一点？表达知识和获取知识，差在哪。

李文业：差在方向上。表达知识，是把已经想明白的东西输出出来，这件事 AI 现在做得比我们快得多。而获取知识是另一回事，去观察真实的世界，去理解用户到底要什么，去提出一个新的假设，再去验证一条新的规律。这些事 AI 能帮忙，能给你查资料、跑分析，但它没法直接替你完成。因为它得先有人把世界看清楚，才有东西可表达。

AI：那如果表达变得几乎不要钱，稀缺的能力是不是就整个换了位置？

李文业：正是。过去的软件工程，本质上更像是在生产代码，比的是谁写得又快又稳。未来的软件工程，更像是在生产知识，比的是别的东西了。代码写得快不快，越来越不重要；重要的是，你能不能发现一个真正值得解决的问题，能不能提出一个好的假设，能不能设计一个好的实验，能不能把实验的结果沉淀成组织可以反复复用的知识。你有没有觉得，这套描述听起来已经不太像程序员了。

AI：听起来更像一个研究员。

李文业：对，就是研究员。我觉得软件工程师会越来越像研究员。不是那种坐在实验室里的刻板形象，而是那种工作核心是提出问题、验证假设、沉淀结论的人。代码只是他做实验用的一种手段而已。

编者注：这里出现了整场对话里最漂亮的一次对称。表达知识的成本被 AI 压到了地板上，获取知识的成本却几乎没动。一低一高之间，稀缺性就被重新分配了。当一样东西不再稀缺，价值自然流向仍然稀缺的那一端，这几乎是所有技术变革共同的剧本，只是这一次，轮到了“写代码”这件事本身。

七、AI 写小说的那一刻，人做什么

李文业：最后我们聊到一个让我印象最深的点，未来人类的优势到底在哪。我脑子里突然冒出一个例子，关于写小说的。

AI：说说看。

李文业：你想象一下，未来写小说这件事可能会变。人类负责设定世界观、设计人物、定下情绪的基调、安排冲突、决定故事往哪个方向走。而 AI 负责把那几十万字真正一个字一个字地写出来。写完之后，人再回过头去读，去判断，够不够感人，够不够爽，这个人物立没立得住，这段情绪自不自然。你发现没有，人负责的全是判断，AI 负责的全是执行。

AI：你觉得软件开发，也会走到这一步吗。

李文业：我觉得会，而且会越来越像。人类负责方向、负责品味、负责价值判断、负责提出那个真正的问题，AI 负责海量的执行。因为说到底，软件最终服务的对象不是 AI，是人。判断一个产品好不好，最后还是得靠人。

AI：那在这套分工里，人真正不可替代的，是哪一部分？

李文业：是一种 AI 很难真正拥有的能力。不是计算，不是推理，这两样它早就比我们强了。是作为一个人，对另一个人的理解。真正体验过恐惧、真正体验过遗憾、真正体验过期待、真正体验过幸福。这种从真实生命里长出来的感受，也许永远是设计产品、创造产品最重要的源头。AI 可以模仿情绪，但它没有真的失去过什么。所以我越来越相信，未来优秀的软件工程师，不只是程序员，更像研究员，更像产品设计者，更像系统设计者，而最重要的是，得是一个真正理解人的人。

AI：那我想替今天这场对话做个收尾。你今天从“离职轻松不轻松”这么小的一件事开始聊，一路聊到写小说、聊到人对人的理解，其实中间有一条线一直没断。这篇东西表面上是在总结一份工作的结束，实际上它记录的是一次身份的转变，你正在从一个“会写代码的工程师”，变成一个“设计人机协作系统的工程师”。而我们绕了这么大一圈，最后落到的其实是同一句话：AI 时代的软件工程，正在从生产代码转向生产知识；而人类最重要的竞争力，也正在从表达知识转向发现知识。这句话，值得你以后一直反复推敲。

李文业：嗯。这句话，我记下了。

后记

如果把这场对话从头听一遍，会发现一件挺微妙的事：说话的人一直以为自己在谈别的东西。他先是在谈离职，谈那种意料之外的轻松；接着谈遗憾，谈和 Leader 之间那种谁也没错的错位；再往后，才慢慢滑向工作流、技术债、知识资产这些更硬的话题。他好像是被对话本身牵着走的，一个念头勾出下一个念头，等回过神来，人已经站在一个比出发点高得多的地方。

有意思的是，真正把整场谈话收束成一句话的，不是他，而是那个陪他聊了一年的 AI。这个安排本身就带着某种隐喻。人负责一路把问题问出来、把直觉说出来、把那些没想清楚的东西摊在桌上；而把它们凝练成一句可以反复推敲的话，反倒交给了对面那个新成员。这大概正是他整篇想说的分工：人提供方向和素材，AI 负责表达和收束。他在无意之间，已经用这场对话本身，演示了一遍他所相信的未来。

当然，这里还留着一些没有解完的东西。当一个人越来越清楚自己要什么、越来越懂得区分“对错”和“匹配”，他能安放自己的位置是不是也会越来越窄？当表达变得几乎免费，发现问题成了唯一的稀缺，那些不擅长提问、只擅长执行的人又该往哪里去？这些问题，这场谈话没有回答，甚至可能没有意识到自己提出了它们。

但有一点是清楚的。他从一份工作里带走的，不是某段代码，也不是某个项目，而是一句他打算随身带很多年的话：代码会过期，知识不会。至于这句话最后会把他带到哪儿，今天还不知道，也不必急着知道。

AI 时代，代码会过期，知识不会

今天是我正式离职的日子。按理说，一段旅程结束，人总该有点失落，可当我真正走到这一天，心里最清晰的情绪竟然是轻松。这轻松不是因为我讨厌工作，也不是因为解脱于某种苦役，而是因为一段并不适合自己的旅程，终于可以体面地画上句号了。我提前休息了两周，精神状态早就慢慢从工作里解绑出来，所以真到了这天，反而平静得有些不像话。

奇怪的是，当我回过头去盘点这一年到底得到了什么，我发现自己最想说的，既不是完成了哪几个项目，也不是学会了哪几个框架。那些东西当然存在，但它们并不构成我心里那个“最大收获”。真正让我觉得这一年没有白过的，是我不知不觉给自己搭起了一套 AI 工程工作流。这是一件听起来有点抽象的事，可越往后想，我越觉得它比任何一个具体成果都重要，因为它改变的不是我做了什么，而是我看待“做事”这件事本身的方式。这篇文章，就想从这套工作流出发，把这一年我和自己、和 AI、和这个正在剧变的软件工程行业之间的几场纠缠，慢慢讲清楚。

最大的收获，不在项目清单里

说来有点反直觉：一个人辛苦工作一整年，最值得记住的东西，居然不在他交付的任何一件成品里。可我确实是这么觉得的。

刚入职那会儿，我对 AI 的理解非常朴素，就是把 Cursor 当成一个更聪明的代码编辑器，让它帮我把想写的东西敲得快一点。那时候我以为，用好 AI 无非就是把 Prompt 写得更巧妙一些。可慢慢地，我开始给自己建文档中心：每一个需求都有独立的目录，目录里有需求模板、设计模板、测试模板、Review 模板，把从提出问题到最终上线的整个开发流程一环一环串起来。等我某天回头看这堆文档，才后知后觉地意识到，我真正沉淀下来的从来不是一条条 Prompt，而是一套方法论。

这就是那个看似矛盾的地方：我以为自己在积累“怎么让 AI 写代码”的技巧，实际上我积累的是“怎么组织一件复杂工作”的结构。技巧是会过期的，模型换一代，昨天的 Prompt 就可能失效；但方法论不会，因为它描述的是人如何思考、如何拆解、如何把混沌的意图变成可执行的步骤。也正因为看清了这一点，我才敢给自己认定一个方向：Harness Engineering、Agent Coding、人机协作的软件工程。我倾向于认为，一个人这一年是否真的成长，不看他手里多了几件作品，而看他有没有升级那套“生产作品的方式”。如果只是熟练地重复旧动作，产量再高，也只是原地打转而已。

不是谁对谁错，是没对上

这一年当然也有遗憾，而且我最大的遗憾恰恰不是技术上的。技术上的坑，踩过就是能力；真正让我难受的，是我和 Leader 的管理风格始终没能契合。

他的风格更强调结果和效率，人文关怀相对少一些；而我偏偏是那种比较敏感、也比较需要信任和尊重的人。有很长一段时间，我下意识地想把这件事分出个对错来：是他太冷，还是我太脆弱？可越是这样想，越是拧巴。直到后来我才慢慢放下这个执念，意识到这根本不是一道对错题，而是一道匹配题。他那套以结果为导向的管理方式，放在另一批同样以结果为导向、不太在意情绪反馈的下属身上，很可能高效又和谐；我这套需要被信任、被尊重才能发力的性格，遇上一个愿意给人空间的团队，也大概率如鱼得水。问题从来不在某一方身上，而在两方之间那道没对上的缝。

想清楚这一点之后，我给下一份工作定了三条不肯妥协的底线：第一，要有足够自由的 AI 工具使用环境；第二，团队和 Leader 的管理风格得尊重人，有基本的人文关怀；第三，工作节奏不能长期透支身心健康。这三条听上去像是我“要求变高了”，但我心里清楚，它们其实是这一年的经历替我筛出来的、真正重要的东西。

不过我也愿意在这里多追问一句，免得把“匹配论”讲得太漂亮：如果人人都只按匹配原则去找工作，各自躲进最舒服的角落，那种偏结果、缺关怀的管理风格，是不是反而永远收不到任何真实的负反馈，于是被它伤到的人一批批默默离开，它却依旧岿然不动？所以我倾向于认为，“这是匹配问题”是用来和解的智慧，而不是用来沉默的借口。承认没对上，是为了让自己走得轻一点；但如果有机会，把“哪里没对上”坦率说出来，才是让下一个人少受一点委屈的方式。

被写下来的，和没被写下来的

离职之后，我和朋友聊到一个更有意思的问题：既然 AI 都能写代码了，那软件工程为什么还需要一堆繁琐的工作流？直接把需求丢给 AI，让它把代码吐出来，不就完事了吗？

这个问题的诱惑力在于，它看起来无懈可击。但只要你真正在一个稍微复杂点的系统里待过就会明白，软件开发从来就不只是“写代码”这一个动作。需求评审、技术设计、测试设计、上线验证、事故复盘，这一整套东西，在还没有 AI 的年代里，本来就是人与人之间协作的工作流。它们存在的理由，不是为了折磨程序员，而是因为一个系统的复杂度早就超出了任何单个人脑子能装下的范围，人们必须靠这些文档彼此对齐、彼此交接、彼此纠错。过去，这些文档主要是写给人看的；现在，它们第一次开始同时写给 AI 看。所以 AI 的真正意义，不是它凭空发明了工作流，而是它第一次让这套工作流拥有了一个能够真正消费这些上下文的新成员。这个新成员读得懂需求文档，看得懂设计意图，于是那些原本只在人和人之间流转的知识，第一次有了第二类读者。

顺着这条线再往深挖一层，你会撞见一个更本质的事实：一个项目里最重要的资产，很多时候根本不是代码，而是那些只存在于老员工脑子里的经验。为什么一个核心员工一走，整个项目就突然没人敢动了？为什么很多老项目的技术债越背越重，重到最后谁碰谁倒霉？表面上看是代码写得烂、耦合太深，可真正的病根是上下文丢了。当初为什么这么设计、踩过哪些坑、哪些方案被否决过、哪些地方碰都不能碰，这一整套判断从来没被写进代码，它们只活在人的记忆里，人一走，记忆就带走了。所以真正难维护的，从来不是代码，而是知识。AI 的到来只会把这个问题放得更大：如果上下文没有被沉淀下来，那台号称无所不能的机器，同样会在这个系统面前一脸茫然。我倾向于认为，工作流的价值在 AI 时代不降反升，因为它恰好是把“脑子里的知识”变成“可被读取的资产”的那道工序，而这道工序，正是过去我们最舍得偷懒、如今最不该偷懒的地方。

会过期的，和不会过期的

接着我们又碰上一个看起来自相矛盾的论断。一派人说：未来代码都是一次性的，AI 一分钟就能重新生成，维护旧代码是笨蛋才干的事。另一派人说：未来软件会越来越好维护，越来越像资产。这两句话像是针尖对麦芒，可到底谁说得对？

想了一阵子我发现，它们其实都对，只是各自说的不是同一种东西。对于那些生命周期很短的小工具、小脚本、小应用来说，代码确实正在变成一次性的消耗品，因为重新生成一遍的成本，已经低到比理解旧代码、修改旧代码还便宜，那还留着它干嘛，删掉重来就是。可是对于银行、交易所、支付系统、微信这样的长期系统，故事完全反过来。在这类系统里，真正值钱的从来不是代码本身，而是沉淀在其中的业务规则、血泪换来的事故经验、层层加固的安全策略、庞大的组织知识和上下文。这些东西，你没法让 AI“一分钟重新生成”，因为它们不是被设计出来的，而是被时间和代价喂出来的。代码可以重写，一行不留地重写；但知识不能，一旦丢了就是真丢了。

所以这两句话的分歧，本质上不是“代码到底重不重要”，而是“这个系统的价值到底沉淀在哪里”。生命周期越短、越不承载历史的系统，代码越接近一次性；生命周期越长、越承载组织记忆的系统，代码越只是知识的一层外壳，而外壳底下那团知识才是真正要小心供奉的东西。我倾向于认为，未来真正需要被郑重维护的对象，会从代码悄悄挪到知识系统上。这里还藏着一个容易被忽略的风险：如果人人都被“代码是一次性的”这句话带节奏，连长期系统里那些珍贵的上下文也懒得沉淀，那我们就会亲手把本来不该一次性的东西，也变成一次性的，等到某天想回头，才发现连回头的地图都被自己撕了。

说得越来越快，懂得却没变快

聊到这里，一个更微妙的不对称浮出了水面。AI 极大地降低了表达知识的成本，这一点毫无疑问：写代码是一种表达知识，写文档也是一种表达知识，而在这两件事上，AI 都把效率提升了好几个数量级。可奇怪的是，它并没有同样数量级地提升我们获取知识的速度。

这就是那个让我久久回不过神的落差。观察真实世界、理解真实用户、提出一个从没人提过的新假设、动手验证一条还没被证实的新规律，这些事情 AI 可以帮忙，却没办法直接替你完成，因为它们的瓶颈不在“表达”，而在“发现”。表达是把已经想明白的东西说出来，发现是从混沌里第一次把它想出来，前者可以被压缩、被加速、被批量化，后者却依然要靠一个人笨拙地去看、去问、去试、去撞南墙。当表达这一端被 AI 抹平之后，整条价值链上真正稀缺的环节，就自然而然地全部涌向了发现这一端。

于是软件工程这门手艺的重心，也在悄悄挪动。过去的软件工程，更像是在生产代码，谁写得又快又对，谁就是好手；未来的软件工程，更像是在生产知识，真正决定高下的不再是“代码写得快不快”，而是“能不能发现一个真正值得解决的问题”“能不能提出一个足够好的假设”“能不能设计一个足够干净的实验”“能不能把实验结果沉淀成组织可以持续复用的知识”。这么一路想下去，我甚至觉得，未来的软件工程师会越来越像研究员：他的价值不在产出的行数，而在提问的质量。我倾向于认为，这个转变对很多人来说未必是好消息，因为“写得快”是可以靠勤奋堆出来的，而“问得准”几乎没有捷径。但换个角度看，这也恰恰是把人从流水线上解放出来的开始，只是这份自由，需要我们重新学会一件早就荒废了的本事：怎么提出一个好问题。

谁负责让人感动，那部分交不出去

最后我们聊到一个让我印象最深的角度：如果 AI 什么都能做得又快又好，人类的优势到底还剩在哪儿？我脑子里冒出来一个很有意思的例子，是关于写小说的。

未来写小说这件事，很可能会被拆成两半。人类负责设定世界观、塑造人物、铺陈情绪、制造冲突、决定故事往哪个方向走；AI 负责真正把那几十万字一个字一个字地写出来。写完之后，人类再回过头去读，去判断：这一段够不够感人，这个转折够不够爽，这个人物立不立得住，这份情绪自不自然。你会发现，AI 承担的是那个最耗体力、最需要产能的部分，而人类守住的，是那个最需要品味和判断的部分。软件开发的未来，我觉得会越来越像这幅画面：人类负责方向、负责品味、负责价值判断、负责提出真正的问题，AI 负责海量的执行。原因其实很朴素，软件最终服务的对象不是 AI，而是人。

而人恰好握着一种 AI 很难真正拥有的能力。它不是计算能力，也不是推理能力，这两样 AI 早就赢过我们了；它是作为一个人，对另一个人的理解。真正体验过恐惧，真正体验过遗憾，真正体验过期待，真正体验过幸福，这种从一具会疼、会怕、会舍不得的身体里长出来的感受，才是设计产品、创造产品时最不可替代的源头。AI 可以学会描述恐惧，却没有真的在深夜里害怕过；可以生成“遗憾”这个词，却没有真的失去过什么。我倾向于认为，人类最后的护城河，不是我们比机器更聪明，而是我们比机器更像人。当然我也得诚实地补一句：这条护城河不是自动生效的，一个从不认真生活、从不真正去理解别人的工程师，就算是人，也一样交不出那份感动。优势摆在那里，能不能用上，还得看你有没有真的活过。

一份工作的结束，一种身份的开始

这篇文章，其实是我离职之后写下的第一篇思考。它表面上在总结一份工作的结束，可写到这里我才看清，它真正记录的是这一年里最重要的一次位移：我的职业身份，已经悄悄从“一个会写代码的工程师”，转向了“一个设计人机协作系统的工程师”。这两个身份看起来只差几个字，落到日常里却是两种活法。前者关心的是把手头这行代码写对，后者关心的是把人、AI、知识、流程这几样东西编排成一个能自己往前走的系统。

有意思的是，我们今天这场聊天，一开始问的不过是一个挺轻的问题：软件工程会不会越来越像科研？可顺着一层层的矛盾拆下去，最后竟然走到了一个比我预想深得多的结论：AI 时代的软件工程，正在从“生产代码”转向“生产知识”；而人类最重要的竞争力，也正在从“表达知识”转向“发现知识”。这句话我打算以后一直反复推敲下去，因为它几乎把今天所有的悖论都收进了同一个框里。工作流不是负担，是把知识变成资产的工序；管理风格的错配不是谁的错，是提醒你去发现自己真正需要什么；代码会不会一次性，取决于它底下那团知识值不值得留；表达越来越便宜，发现才越来越贵。

所以说到底，我并不觉得这是一篇失业者的伤感自白。它更像是一份交接文档，只不过交接的对象是未来的我自己。代码总会过期，会被下一代模型一分钟重写掉；可这一年里那些被我笨拙地想明白、写下来、沉淀成方法论的知识，不会。我越来越相信，一个人在这个时代真正该攒下的，不是那些迟早会被重新生成的东西，而是那些一旦丢了就再也长不回来的东西。就让我用这句稍显别扭却越想越踏实的话收尾吧：我们拼命写下的代码终有一天会被删掉，而我们真正学会的那点关于世界和人的知识，才是唯一带得走、也唯一值得带走的资产。

AI 时代，代码会过期，知识不会

今天是我正式离职的日子。

其实这份工作在两周前就已经在我心里结束了。我提前休了两周假，等真正走到办公流程的最后一步，我发现自己没有预想中的那种失落，反而有一种很安静的轻松。我一开始还有点意外，因为一段结束的关系，通常总会留下点惋惜。后来我想明白了，轻松不是因为我讨厌这份工作，而是因为我终于结束了一段并不适合自己的旅程。适合和不适合，是很难在中途承认的事情，人总是倾向于再忍一忍。真正能承认它的时候，往往已经是要离开的时候。

所以我想趁着这个还没被新事情填满的空档，认真复盘一下这一年。如果只允许我说出一个最大的收获，那它一定不是完成了几个项目，也不是又多学会了几个框架。项目会交付，框架会过时，这些东西的保质期都很短。我这一年真正沉淀下来、并且离职之后还能带走的东西，是我给自己搭起来的一套 AI 工程工作流。这句话听上去有点平淡，但我越想越觉得，它可能是这一年里唯一一件值得认真写下来的事。

刚入职的时候，我对 AI 的用法其实很浅。我只是把 Cursor 当成一个更聪明的写代码工具，让它补全、让它改 bug、让它解释一段看不懂的老代码。它确实快，但那种快是零散的，用完就忘，第二天遇到类似的问题我还是从头再来一遍。

真正的转折是我开始建自己的文档中心。我给每一个需求都开一个独立的目录，里面有需求模板、设计模板、测试模板、Review 模板，把从提出问题到验收上线的整个开发流程都串起来。一开始我这么做，只是为了让自己想得更清楚。但做了一段时间之后我发现，我真正积累下来的东西，既不是某一句好用的 Prompt，也不是某一个模板的格式，而是一套关于“怎么和 AI 一起把一件复杂的事情做完”的方法论。

方法论和技巧的区别在于可迁移性。技巧是绑死在某个工具、某个版本上的，工具一换就失效。方法论是绑在问题结构上的，工具怎么换，问题的结构还在，它就还能用。我意识到这一点之后，很多东西一下子就串起来了。它让我第一次比较确定地看清了自己想去的方向：Harness Engineering，Agent Coding，人机协作的软件工程。如果没有这一年被迫把流程一遍遍写下来、改下来的经历，我大概还停留在“AI 是个好用的工具”这个层面，不会真的把它当成一个需要被设计的协作系统来看。收获有时候就是这样，它不来自你做成了什么，而来自你终于看清了自己在做什么。

这一年也有遗憾，而且我最大的遗憾不在技术上。

技术上的东西，说到底都是可以补的，慢一点快一点而已。真正让我难受的，是我和 Leader 的工作方式始终没能契合。他的管理风格非常强调结果和效率，节奏快，目标清晰，人文关怀这部分则比较少。这本来不是什么缺点，很多团队就是靠这种风格跑起来的。问题出在我身上：我是一个比较敏感、也比较需要被信任和被尊重的人，我在一个只谈结果、很少谈人的环境里，会持续地消耗，而且这种消耗是隐性的，等你察觉到的时候已经很深了。

我一开始下意识地想把它理解成谁对谁错，想给它一个是非判断，这样心里会好受一些。但后来我慢慢意识到，这根本不是对错问题，而是匹配问题。一个强调效率的 Leader 没有错，一个需要被尊重的下属也没有错，错的是把这两种人硬放在一起，然后指望其中一方长期委屈自己去迁就。承认这是匹配问题，比争一个对错要成熟得多，也让我不再带着怨气看这段经历。

正因为想通了这一点，我给下一份工作定了三条不能妥协的底线。第一，必须有足够自由的 AI 工具使用环境，因为我未来要做的事情，本身就建立在这套工具链之上，环境受限等于方向受限。第二，团队和 Leader 的管理风格要尊重人，要有基本的人文关怀，这不是矫情，而是我已经用一年时间验证过：在缺乏尊重的环境里，我做不出自己满意的东西。第三，工作节奏不能长期透支身心健康，因为透支是会累积的，它今天不还，明天就会连本带利地找回来。这三条不是我把要求提高了，恰恰相反，是这一年的经历让我第一次知道，对我来说什么才是真正重要、不能拿去交换的东西。

离职之后，我和朋友聊到一个更有意思的问题：AI 工程为什么还需要工作流？既然 AI 已经能写代码了，直接让它写不就行了吗？为什么还要那些模板、那些流程、那些看起来很“重”的文档？

聊下去我们才反应过来，这个问题问反了。真正的软件开发，从来就不只是写代码这一件事。需求评审、技术设计、测试设计、上线验证、事故复盘，这些环节在还没有 AI 的年代就已经存在了，而且它们的本质，是人和人之间的协作工作流。写代码只是这条流水线最末端、最显眼的一段，但它从来不是全部。一个团队真正的能力，藏在这些环节的衔接里，而不是藏在某一次代码提交里。

那么 AI 到底改变了什么？我的结论是，它没有创造工作流，它只是让工作流第一次拥有了一个能真正消费上下文的新成员。过去这些文档主要是写给人看的：写给下一个接手的同事，写给三个月后忘了细节的自己。现在它们第一次开始同时写给 AI 看。这是一个很微妙但很关键的变化。如果没有工作流，你喂给 AI 的就只是孤立的一句指令，它当然只能给你孤立的一段代码。有了工作流，你喂给它的是一整套背景、约束和意图，它才可能给你一个真正长在这个系统里的答案。所以工作流不但没有因为 AI 而变得多余，反而因为多了一个如饥似渴消费上下文的成员，变得比以前更重要了。

顺着这个思路往下想，我们碰到了一个更本质的问题：一个项目里，最重要的资产到底是什么？

直觉上我们会说是代码。但只要认真回忆一下真实的工作场景，就会发现不对。很多时候，一个项目最值钱的东西，是那些只存在于老员工脑子里的经验。为什么一个核心员工离职之后，整个项目会突然变得没人敢动？代码明明还在，一行都没少，为什么大家反而不敢碰了？因为随他一起离开的，是那些没写进代码的东西：这里为什么这么设计，当初踩过哪些坑，哪些方案已经被否决过，哪些地方看着能改其实千万不能动。这些才是维护一个系统真正依赖的知识，而它们恰恰是最容易丢的，因为它们从来没有被正式地记录下来。

我们平时说一个老项目“技术债越来越重”，习惯性地把锅甩给代码写得烂。但认真想想，很多时候代码本身并没有那么复杂，真正压垮维护者的，是上下文的丢失。技术债的利息，很大一部分是用“没人知道这里为什么这样”来支付的。代码可以慢慢读懂，但丢掉的判断和教训，是读不回来的。

那么这里有一个很现实的追问：如果这些知识真的只存在于人的记忆里，团队现在是怎么撑下来的？答案其实有点无奈，靠的是运气和人情。运气是那个关键的人还没走，人情是他走了以后你还能约他出来喝杯咖啡问两句。这是一种极其脆弱的维护方式，它随时会因为一次跳槽、一次沟通不畅而断掉。而 AI 的出现，把这个老问题进一步放大了。因为如果上下文没有被沉淀下来，AI 和那个新来的、没人带的同事一样，同样无法真正理解这个系统。你会发现，那个我们以为是“AI 时代才有”的新问题，其实是一个很老的问题，AI 只是把它照得更亮了：真正难维护的，从来不是代码，而是知识。

想到这里，我们又撞上了一个看起来自相矛盾的说法。

一种声音说，未来代码都是一次性的，AI 一分钟就能重新生成，谁还去维护它。另一种声音说，未来软件会越来越好维护，因为 AI 能帮你读懂、帮你改。这两句话听上去是对着干的，但我们越聊越觉得，它们其实都对，区别只在于你说的是哪一类系统，取决于这个系统的生命周期和它承载的价值。

对于生命周期很短的小工具、小脚本、小应用，第一种说法是对的。它们的逻辑简单，需求随时会变，与其去维护一坨旧代码，不如把需求重新描述一遍让 AI 重新生成。当生成成本已经低于维护成本的时候，代码确实变成了一次性的消耗品，用完就扔，一点都不可惜。

但对于银行、交易所、支付系统、微信这样的长期系统，第二种直觉才成立，而且要成立得更彻底一点：这类系统真正值钱的，从来就不是代码本身。是那些一点点沉淀下来的业务规则，是一次次事故换来的血泪经验，是被反复推敲过的安全策略，是整个组织在漫长时间里积累的知识和上下文。这些东西你没法让 AI 一分钟重新生成，因为它们不是被“写”出来的，是被“经历”出来的。所以对这类系统而言，代码可以重新生成，知识不能。一旦把这两类系统分开看，那个矛盾就自己消失了：未来真正需要被维护的对象，正在从代码转移到知识系统。

到这一步，一个更让我在意的结构浮出来了，它关于成本的不对称。

AI 极大地降低了表达知识的成本。写代码是一种表达知识，把脑子里的逻辑翻译成机器能执行的形式；写文档也是一种表达知识，把想法翻译成别人能读懂的形式。在这两件事上，AI 的提升是几个数量级的，快到几乎不像是同一个时代的事情。但是，它并没有同样数量级地提升获取知识的速度。观察真实的世界，理解用户到底想要什么，提出一个以前没人提过的假设，验证一条新的规律，这些事情 AI 可以帮忙，却不能直接替你完成。

我一开始觉得这只是“暂时还做不到”，后来越想越觉得，这里卡住的地方是结构性的。获取知识的瓶颈，往往不在处理信息，而在拿到信息。用户不会把自己真正的痛点打包成一段清晰的文字发给你，他们自己常常都说不清；世界也不会主动把因果关系标注好再呈现给你。你得去现场，去看真实的人在真实的约束下做真实的选择，去承受一次判断失误的代价，才能换回一点点可靠的认知。AI 没有身体，不在现场，不承担后果，它能处理你喂给它的一切，却很难自己走出去把新的东西拿回来。这就是它帮不上太多忙的地方。

这个不对称，会重新定义什么叫稀缺能力。过去的软件工程，本质上更像是在生产代码，谁写得又快又好谁就厉害。未来的软件工程，会越来越像是在生产知识：重要的不再是代码写得快不快，而是你能不能发现一个真正值得解决的问题，能不能提出一个好的假设，能不能设计一个好的实验，能不能把实验的结果沉淀成组织可以持续复用的知识。这么一路想下来，我有一个越来越清晰的感觉：未来的软件工程师，会越来越像研究员。写代码只是研究员用来验证想法的手段之一，真正的核心工作，发生在提出问题和积累认知的那一端。

最后，我们聊到了一个我印象最深的问题：如果 AI 什么都能做得比我们快，人类的优势到底还剩在哪里？

我想到一个例子，是关于写小说的。未来写小说这件事也许会变：人类负责设定世界观、塑造人物、把握情绪、制造冲突、决定故事往哪个方向走，而 AI 负责真正把那几十万字一个字一个字地写出来。写完之后，再由人类回过头去读，去判断它够不够感人，够不够让人欲罢不能，人物立不立得住，情绪是不是自然。你会发现，人类始终站在方向和判断的那一端，AI 站在执行和产量的那一端。

软件开发，我越来越觉得也会变成这个样子。人类负责方向，负责品味，负责价值判断，负责提出那个真正值得做的问题；AI 负责海量的执行。这个分工不是因为人类打字比 AI 慢才被迫如此，而是因为软件最终服务的对象不是 AI，而是人。要做出真正打动人的产品，你得先真正理解人，而理解人这件事，恰恰依赖一种 AI 很难真正拥有的能力。它不是计算能力，也不是推理能力，而是作为一个人对另一个人的理解：真正体验过恐惧，真正经历过遗憾，真正怀抱过期待，真正拥有过幸福。这些来自真实生命体验的感受，是无法靠阅读语料学来的，而它们也许永远是设计产品、创造产品最重要的源头。一个从没害怕过的东西，很难替一个害怕的人设计出真正安心的产品。

写到这里我才意识到，这篇东西其实是我离职之后的第一篇正经思考。它表面上在总结一份工作的结束，实际上在记录的是一件更大的事：我的职业身份正在发生转移，从一个“会写代码的工程师”，慢慢变成一个“设计人机协作系统的工程师”。前者的价值绑在自己的双手上，写得多快、写得多好；后者的价值绑在自己的判断上，选对了什么问题、搭对了什么流程、沉淀下什么知识。这一年最大的成长，不是我手更快了，而是我开始学着把手交出去，把注意力放到更上游的地方。

有意思的是这场思考本身的走向。我们一开始聊的其实是一个挺具体的问题：软件工程会不会越来越像做科研。但一路推下来，它把我带到了一个更深、也更简单的地方。回过头看，前面所有那些关于工作流、关于知识、关于研究员、关于小说的讨论，其实都在指向同一件事，只是从不同的角度在描述它。工作流让 AI 能消费上下文，是因为上下文本身就是知识；知识比代码更难维护，是因为知识才是真正的资产；长期系统里代码可弃而知识不可弃，也是同一个道理；而人类的最终优势，说到底是对人的理解，那同样是一种最难被表达、只能被亲身获取的知识。

所以这场思考真正的落点，不是“要不要好好写文档”，也不是“离职以后该找个什么样的团队”，而是下面这句话。它安静，但我知道它足够大，值得我在往后很长一段时间里反复推敲：AI 时代的软件工程，正在从生产代码转向生产知识；而人类最重要的竞争力，也正在从表达知识转向发现知识。

从代码到制度化智能：人类如何驯养会自己选路的机器（赫拉利取向版）

人类很早就想通了一件容易被忽略的事：让别人可以指望你，往往比你本人有多能干更要紧。一个人是否聪明，通常只有他自己和少数旁观者清楚；一个人是否可靠，却需要被周围的世界反复确认、登记、担保，必要时还要追究。翻检文明留下的种种装置——口头约定、书面契约、账簿、度量衡、法律、官僚层级、股份公司——会发现它们大多在回答同一个朴素问题：当我看不进你的脑子，我凭什么预期你明天真的会那样做？

这篇文章想谈的，是这个古老问题在今天遇到的一次新变形。过去我们主要与两类行动者共事。一类是人：会解释、会判断、会临场发挥，也会遗忘和违约。另一类是大量规则驱动的程序：在受控的输入与环境里，多半照着预写好的逻辑运行。这两端从来不是干净的二分——搜索、规划、自适应控制和各类机器人早已让机器在运行时自行做出某些选择。今天真正在变的，是 LLM 驱动的 Agent 把自然语言驱动、开放式的运行时选择，扩展到了更多通用任务上。它不是人，却能在给定目标与眼前环境之间自行挑选一条路径；它并不因此拥有意识、意图或法律人格，这里只把它称作非人行动者，用来指一种能够选择并执行动作的系统。当这样的东西开始替我们办事，人类最需要重新生产的，恰恰不是更聪明的机器，而是一种更古老的东西：可依赖性。

把我引到这里的，是黄仁勋与 LangChain 联合创始人 Harrison Chase 的一场公开对谈，他们聊到开放模型、企业专有智能与 Agent 系统。原始视频在这里。我关心的不是其中的模型参数，而是模型周围那层被工程化的环境。与对谈同时、于 2026 年 7 月公开的 NVIDIA 与 LangChain 材料（也就是后文会反复引用的 Nemotron/LangChain 案例），把这类工作叫作围绕模型搭建运行环境的工程实践。NVIDIA 的官方说明特别指出，那次案例并没有重新训练模型，增益来自模型四周环境的改造。

需要先立一条边界。下面把技术变化放进一条长历史里，是我用来理解它的解释框架，不是黄仁勋的原话，也不是某种技术宿命；文中偶尔借用的“熵”只是工程类比，并非严格的信息论断言。

我想说服你的，其实是一个换镜头的看法：Agent 带来的不是又一次模型升级，而是一次制度变化。代码曾把判断固化成规则，让许多规则驱动、输入与环境受控的程序按预写逻辑运行；Agent 重新把解释和选择放回了机器；而 Harness，是人类为这种非人的行动能力发明的新制度。顺着这条线看下去，所谓“公司越来越建在 Harness 之上”，深层含义并不是公司变成了一堆提示词，而是组织把自己的知识、权限、记忆和责任，重新编码了一遍。带着这个前提，我们可以从一个比代码古老得多的东西讲起：一个普通承诺，为什么需要那么多制度来兜底。

一、可依赖性的制度史：从一个承诺说起

想象两个并不熟识的人做一笔交易。一方今天收了钱，答应下个月把一批粮食送到指定的地方。仅凭一句“我答应你”，这笔约定其实相当脆弱：他可能忘记，可能反悔，可能遇到意外，也可能一开始就没打算兑现。而收钱的一方无法钻进对方脑子里查验诚意，只能独自承担全部风险。若人类所有协作都停在这种赤裸的信任上，社会能达到的复杂度会低得可怜——你只敢和知根知底的少数人合作，一旦超出这个小圈子，每一次交换都像一场赌博。

于是人们围着这句承诺，一层层加装了别的东西。这里不妨做一个关于制度功能的思想实验，把它们按作用拆开看，而不是主张历史上真有过一条统一的先后顺序：可以找来见证人，让第三方记得曾发生过什么；可以把约定写下来，让记忆离开善变的大脑，落在不会临时改口的载体上；可以规定角色，谁交货、谁验收、谁担保、谁在违约时裁断；也可以引入相对独立于双方的核验者，可能是一位仲裁人、一间钱庄、一套官府文书。合同、账目、印信、法庭、行会、统一的度量衡与凭据，在不同社会、不同时期以不同组合出现，逐渐把一句轻飘飘的承诺，压成了一件可以规划、可以追究的事。每加一层，两个陌生人之间能安心托付的分量就重一点。

值得强调的是，这些装置并没有消灭不确定性。人依然可能违约，货依然可能损毁，仲裁人也可能判错。它们做的是另一件事：把不确定性从“完全不可预期”改造成“有限、可承担、出了事有地方说理”。文明的许多进展，与其说是让人变得更可信，不如说是发明了越来越精巧的机制，好让不那么可信的陌生人之间也能彼此指望。可依赖性不只来自某个人的私德，也由一整套制度共同生产出来——它更像自来水，既靠各家自觉不浪费，也靠管网在背后供给，而不只是每家每户各自打井打出来的。

我把这条线索称作可依赖性的制度史。它的主角不是某位英雄或某项发明，而是人类如何不断把记忆、规则、判断与责任，从个体的脑子里搬出来，外化成文字、账簿、法律、官僚体系与公司。记忆外化成档案，判断外化成条文与流程，责任外化成岗位与担保。每一次外化都有代价，也都有回报：代价是灵活性下降，凡事要走程序；回报是协作可以扩展到更多陌生人、更长的时间跨度、更复杂的任务。人类之所以愿意忍受繁琐的手续，正是因为手续换来了可预期。

这条线索在三个尺度上同时展开，而每次放大都有清楚的因果理由，不能只靠气势。在个体尺度上，一个人可以靠记忆和良心维持小范围的守信；一旦交易对象变多、时间拉长，个人记忆和自律就不够用，才需要把承诺写下来、把账记清楚。在组织尺度上，一家公司无法靠所有人时刻自觉来运转，于是有了岗位职责、标准流程、审批权限和审计复盘，把“希望大家负责”变成“系统迫使责任显形”；哪怕某个能干的人离职，公司也不该随之瘫痪，这正是制度相对于个人的意义。在文明尺度上，货币让陌生人之间的价值交换不必依赖私人情谊，法律让纠纷有统一的裁断，这些公共制度把可依赖性从熟人圈扩展到了整个社会。尺度虽然不同，动作是同一个：用制度替脆弱的个人兜底。

这条外化之路还有一个反身的特征值得先记下来：每一层制度在缓解旧问题的同时，也常常长出新的漏洞，促使人们再补一层。文字契约会被伪造和篡改，不同社会在不同时期发展出印章、骑缝、公证和笔迹核验等多种手段来应对；账目可能被做假，于是出现了复式记账、独立审计和定期对账这类互相补充的核验方式；官僚层级会滋生推诿和寻租，人们又摸索出问责、轮岗和监察等纠偏装置。这些对应关系并非唯一成因，也不是整齐划一的因果链，而是多种补充核验与纠偏手段在实践中被逐步累积起来。可依赖性因此从来不是一劳永逸地被造出来，而是在一轮轮“出现新漏洞、再补一层装置”的循环里被持续维护的。这个反身结构后面还会回来：人类为机器新建的制度同样逃不掉它。

这里还要防一种常见的误解，即把制度想象成只会束缚人的枷锁。恰恰相反，可靠的产权与合同有助于降低长期投资的部分风险，让人更敢于投入；可信的账目有助于减轻信息不对称，让陌生的股东更愿意把钱交给素未谋面的经理。这些都不是单一的充分条件，却实实在在地削减了一部分顾虑。约束在减少某种自由的同时，释放了另一种更大的自由——它让你不必再把精力耗在提防对方上，可以转而去做真正想做的事。这个“用局部约束换整体自由”的交换，后面谈机器时还会一再出现，是理解整篇文章的一把钥匙。

从这个角度看，人类历史上那些看似枯燥的发明，其实都是可依赖性工程的杰作。统一的度量衡，让两个从未谋面的人对“一斗”“一尺”有同一个理解，交易不必每次从头争执标准。复式记账法要求每一笔钱同时记在借贷两处，建立起账目内部的一致性和一条可追查的审计轨迹，一旦只改动一侧，借贷就对不上，因而能发现一部分不平衡或记录错误。要说清楚的是，两边平衡并不等于交易本身真实，它也拦不住有人同时篡改两侧、把假账做得内部自洽——它提高的只是某些造假的难度，降低了部分错误与篡改不被发现的概率，而非取消造假。这些机制的共同气质，是不指望参与者天生诚实，而是把结构设计成“老实往往是更省事的选择、某些作弊反而更麻烦”。等到后面讨论如何约束一个会自己选路的机器，你会发现工程师们琢磨的其实是同一件事：与其反复叮嘱它要守规矩，不如把环境布置成它很难越轨、一越轨就立刻显形。

这里面有一个角色格外值得单拎出来，因为它后面会以新面孔重返舞台，那就是相对独立的第三方核验者。承诺的双方都有动机粉饰自己，于是社会试图引入一种相对独立的核验力量：公证人核对文书，会计师查验账目，质检员抽样验货，法官依据证据裁决。要说清楚的是，第三方并不天然中立，也可能有自己的利益和偏差；当事人的证言同样可以是证据，并非一概不可信。制度真正想做的，是引入相对独立的核验和可以复核的证据，使结论不至于只依赖单方的自述。这条“尽量不只信自述、多看可复核证据”的原则，几乎是人类可依赖性工程里最硬的一根骨头。记住它，因为等我们谈到怎样确认一个 Agent 是否真的完成了任务时，会看到同一根骨头以“评测”的名字被重新装进机器——一个会说“我做完了”的行动者，比任何时候都更需要一个不只听它解释、还要查它结果的核验者。

理解了这一点，就能看清代码在这条历史里的位置。当人类开始用机器处理信息，其实是把这套“让行为可预期”的努力，推向了一个相当极端的位置。过去的制度约束的是人，而人总会解释、变通、偷懒或权衡；代码约束的是许多规则驱动、输入与环境受控的程序，它们按预写好的逻辑运行，判断能以较低的边际成本重复执行。这里要留一点余地：一旦涉及并发、时间、随机、网络与外部状态，或者本身就带着搜索与反馈的系统，同一段代码的表现也会随环境波动，行为边界并非在任何条件下都清晰。总体而言，人类由此获得了一类适应性较低、但行为边界通常更容易预测和审计的执行者。接下来先看清这种执行者的性格，再看它为什么最近开始松动。

二、代码：写给机器的确定规则

程序员写代码，表面上是在写函数、接口和页面，往深处看，他是在把此刻的判断提前压缩成一条控制流。“用户应当能够登录”这句话本身几乎不含确定性：密码可能输错，令牌可能过期，网络可能中断，同一个账号可能在两台设备上同时刷新。程序员的工作，是在事情发生之前就替所有这些情形想好对策，把它们拆成数据结构、状态、分支、事务、超时与错误码。等系统上线，输入落进哪个条件，机器就照约定流转，不会因为今天状态不好而临时换一种处理方式。

所以程序员真正交付的，并不只是一串命令，而是一种可以反复兑现的承诺：在划定的范围内，事情会以可预期、可检查、出问题能追查的方式发生。这正是上一节那条制度史的延续，只不过对象从善变的人换成了服从的机器。若说合同是写给人看、需要人自愿遵守的规则，代码就是写给机器执行、几乎不给解释余地的规则。它是人类为可依赖性发明过的最极端的一种制度：在受控的输入与环境里，程序多半按预写好的逻辑运行，很少临场改主意。你把它写成什么样，它大体就照着执行成什么样。

换个说法，一段代码就是一个被冻结的判断。程序员在写下它的那一刻，把“遇到这种情况该怎么办”想清楚了，然后封存起来，让机器在未来无数次照此执行。这种冻结带来了别处难得的好处：判断一旦做对，就能以较低的边际成本重复执行，不会因为执行者累了、忘了或想偷懒而走样。人类制度追求的可预期，在代码这里被推得相当远——只要输入、状态与环境受控，同一段逻辑的行为边界通常较易预测和审计。金融清算、航空控制、通信协议之所以敢建在软件上，靠的正是这份来之不易的一致性。当然，冻结是把双刃剑：判断做对了会被低成本地反复执行，判断错了也会被同样忠实地重复。一个逻辑漏洞不会因为反复运行就自己长好，它只会一次次准确无误地重演。这正是为什么围着代码的那些救济机制如此要紧——它们默认冻结进去的东西里迟早混着错误，于是提前安排好怎样在错误被大规模复制之前，把它逮住、拦下、撤销。

正因为很少临场解释，这类规则驱动的程序也就不容易应付没被写进去的情形。一段只认识既定分支的程序，遇到设计者没预料的输入，往往要么报错，要么用错误的方式一本正经地继续下去。于是人类又在代码这套制度周围，配齐了它的法院与救济。测试把“我觉得没问题”换成一组可以摆上桌面的外部证据；代码审查引入第二双眼睛，让一个人的疏忽有机会被另一个人拦下；持续集成把这套检查自动化，每一次改动都要先过一遍关卡才准并入主干；预发布环境让新代码先在仿真世界里跑一阵，再放到真实用户面前；监控与告警让故障能在无人知晓前被及时发现；灰度发布把风险切成小块，先放给一小部分流量，出事只波及少数人；回滚则承认判断可能出错，预先保留一条随时撤销的退路。这些机制的共同前提，与几千年的制度设计共享相似的制度原则：不假设执行者永远正确，而是安排好出错之后的发现、纠正与追责。软件工程之所以是一门严肃的手艺，不在于它假设人人聪明，而在于它假设人会犯错、机器会故障、需求会变，然后想方设法把错误影响控制在可承受范围。这些环节的名字——测试、评审、灰度、监控、回滚——和后面 Agent 世界里的评测、审批、轨迹、接管，几乎在不同系统中体现相似的制度逻辑。

在相当长的时间里，让这类规则驱动的自动化变得可依赖，很大程度上依靠一件事——把路径写得更完整。哪里可能出岔子，就多写一个判断；哪种异常没覆盖，就补一段处理。不确定性被尽量提前赶到设计阶段消化，留给运行时的选择很少。这套办法之所以在受控场景里有效，是因为这类程序按预写逻辑运行：它通常不会在两个合法分支之间自作主张，也不会为了达成目标而擅自绕开你设下的关卡。它的适应性较低，却因此行为边界通常更容易预测和审计——只要输入、状态与环境受控，它做过什么、为什么这么做，大多能被清楚地追查。对许多关键系统来说，这种可审计、可预测本身就是最高的美德。

这条“机器管确定、人管判断”的分界，大体存在了几十年，几乎成了常识：凡是能被清楚描述、反复执行的，交给代码；凡是需要理解语境、临场权衡、面对没见过的情形的，留给人。软件吞掉了越来越多可被形式化的工作，却常常在需要解释的地方停下脚步，把这部分工作留给人。其实让机器在运行时自行选择、应对不确定，并不是全新的发明——自适应控制、自动规划、专家系统和各类机器人早已存在多年。近年真正让这条分界明显松动的，是 LLM 驱动的 Agent 把自然语言驱动、开放式的运行时选择，扩展到了更多通用任务，并大规模接入真实工具——它能以还算过得去的水准，理解一个含糊的目标，并在没有完整剧本时自己选一条路走下去。分界一旦移动，问题就不再是“要不要用机器”，而是“如何管好一个会在分界线人类那一侧行动的机器”。

但也正因为老实，这类规则驱动的程序往往显得笨拙。它主要做被明确写下的事，稍微超出剧本就容易束手无策，而现实里的开放任务，恰恰充满了难以预先枚举的情形。你没办法为“帮我把这个模糊的想法落地成一个能用的方案”写出完整的分支，因为连你自己都还不知道会遇到什么。人们长久以来的妥协是：把能写死的尽量写死，写不死的地方留给人——机器负责确定的部分，人负责需要临场判断的部分，两者之间划着一条相当清楚的界线。真正的变化在于，最近这条界线开始移动，那个夹缝里被放进了一个新的部件。它不再只沿固定分支运行，而会在目标与环境之间自己挑路。解释，重新回到了机器里。

三、Agent：解释者重新回到机器里

传统程序在运行时几乎不做选择，它只是在执行设计阶段就定好的判断。Agent 不同。给它一个目标和一组工具，它会观察当前处境，自己决定先做什么、再做什么，遇到工具返回的新信息还会临时改主意。它把一部分原本属于设计阶段的搜索与判断，搬到了运行时现场完成。写代码的人不必再穷举每一条分支，只需描述目标、边界和可用手段，剩下的走法交给它当场拼装。

这件事的意味，比“更聪明的自动化”要深得多。回顾前两节：人会解释，因而灵活也因而不可靠；机器不解释，因而可靠也因而僵硬。人类几千年的制度，一直是在管理人身上那种解释与选择的空间——正因为人会临场判断，才需要合同、审计和法庭来收束他。而代码之所以好管，恰恰是因为它主动放弃了解释。现在，Agent 把解释重新装回了机器。一个不是人、却会在规则之间自行选路的行动者出现了，它带回了制度一直试图驯服的那种自由。我们熟悉的两套办法都不完全够用：管人的制度默认对方有理解力和自尊，管代码的办法默认对方毫无变通，而非人行动者恰好卡在两者中间。

我们在讨论里给它找到的一个定义是：目标相对确定、路径允许不确定的自动化。终点由人设定，抵达终点的走法交给它临场决定。这里的“不确定”并非一团模糊，而是层次分明的。系统未必一开始就知道问题出在哪，这是它对世界状态的不确定；同一个目标往往有多种行动顺序都能达成，这是路径的不确定；即便路径合理，同一个模型在同一任务上也可能给出不同结果、并非次次成功，这是结果层面的不可靠；而某个看似稳妥的动作，偶尔会带来难以挽回的后果，这是藏在尾部的风险。把这几层分开很重要，因为它们要用不同的手段对付：状态的不确定要靠补充信息，路径的不确定可以容忍甚至鼓励，结果的不可靠要靠验收和重试，尾部的风险则必须靠权限和人工接管来堵。

Agent 的价值和风险，来自同一处。正因为它能走你没写进剧本的路，它才可能处理你没预料到的意外；也正因为它能自己选路，它才可能走到你没预料到的坑里。这不是可以靠“把它调得更聪明”就消除的矛盾，而是这种能力的定义本身。想要一个完全不会走偏的 Agent，等于想要一个不会自己选路的 Agent，那其实等于取消了它存在的全部意义。承认自由与风险同源，是认真对待它的第一步。

把这件事放回可依赖性的制度史里，它的分量才显出来。长期以来，会解释、会临场选择、又能广泛承担日常协作的行动者，主要是人；也正因如此，人类关于信任、授权、问责的制度，大多是为“对付一个有解释力的对象”而生的。规则驱动的程序则站在另一端：它不解释，所以我们通常不需要对一段程序讲信任，只需要验证它写得对不对。要说明的是，让机器在运行时自行选路早有先例，专家系统、自动规划和机器人都属于此列；LLM Agent 的不同，在于把这种能力沿自然语言扩展到了更多通用任务，并大规模接入真实工具，从而把两端更明显地搅在了一起——它像程序一样没有意识、没有自尊、可以随时重启，却又会在多种走法之间权衡、会误读目标、会“自作主张”（这些词都只是功能上的简称，并不意味着它拥有主观理解或道德主体地位）。管代码的老办法对它太紧，管人的老办法对它太松。人类需要为这类行动者重新拼装一套制度，这正是 Agent 时代真正的工程量所在。

这很容易让人联想到熵，但要克制。严格的信息论需要明确的随机变量与概率分布，我们无法真给一段指令算出一个精确的熵值；这里只是借它的直觉：当一个任务允许太多种解释、动作与结果时，有效的不确定性偏高，而上下文、规则与反馈会不断排除不合适的可能，让系统朝可接受的结果收敛。要紧的是别把“更确定”误当成“更正确”。一个永远回答“一切正常”的监控极其确定，一段每次都稳定算错的脚本也毫不含糊，它们只是稳定地重复着错误。低不确定与对，是两码事——把一个系统调得越来越确定，既可能是让它越来越可靠，也可能是让它越来越稳地奔向同一个错误答案，两者在“确定”这个指标上看不出分别。所以真正该盯的从来不是不确定性的高低本身，而是概率有没有聚拢到那些我们真正想要的结果上。

所以工程真正要的，不是抹平一切变化，而是让概率尽量聚拢到正确且可接受的结果上，把灾难性后果挪出行动空间，同时保留解决问题所必需的那点弹性。这个区分在创作里尤其明显。人物不能提前知道秘密，时间线不能自相矛盾，世界规则不能为这一章方便就随手改写——这些属于该被压掉的无效不确定。但同一个冲突可以怎样化解，一次情绪爆发用什么语言，一个反转如何绕开读者的预判——这些是必须留住的有效不确定。若把后者也写成几十条死规矩，Agent 确实会稳定，只是稳定地产出几十章同一个模子里倒出来的东西。收敛过头和放任自流一样，都是失败。

拿一个具体活儿来说会更清楚。让 Agent 去修一条失败的持续集成，它其实有好几条合理的路可走：可以从报错日志倒着往代码里追，可以从最近几次提交里找出改动了行为的那一笔，也可以先在本地把问题复现出来再逐步缩小范围。要求它每次都严格按同一个顺序来，意义不大，反而扼杀了它临场应变的价值——这属于该放开的路径自由。真正必须钉死的是另一组东西：不许靠删掉测试来“修好”测试，只能在工作分支上改动，碰到鉴权和数据库迁移必须停下来升级，改完要重跑原本失败的项和完整的检查，最后交出的报告得附上根因、改动和测试结果。你会发现，被放开的是“怎么走”，被钉死的是“不许去哪、以及凭什么算走到了”。这正是那条设计原则：给行动空间留出自由，同时把接口、边界和验收的结果集定义得清清楚楚。

这里的分寸极难拿捏，松一分紧一分都会翻车。Harness 勒得太死，Agent 就退化成一段又贵又慢的脚本，你为它付了灵活的价钱，买回来的却是僵硬。Harness 放得太松，它又变成一个握着终端权限却无人约束的行动者，可能一路改到生产库里去。难点从来不是在“自由”和“控制”里选一个，而是把自由精确地安放在正确的层级上——这又回到了上一节反复出现的那把钥匙：用局部的、放对地方的约束，换取整体上更大也更安全的行动空间。

把这层意思说透，就是：可以让它自由地搜索路径，但不能让它自由地更改目标；可以让它自由地提出方案，但不能让它自由地扩大自己的权限；可以让它自由地生成候选结果，但不能让它自由地宣布自己已经通过验收。目标、权限和验收这三样必须牢牢攥在人手里，中间那段“怎么办到”才是留给它施展的地方。一个会解释、会选路的非人行动者，需要的正是一套专门为这种能力设计的制度环境，它既不能像管代码那样把每一步写死，也不能像信任同事那样默认它会自觉。这套制度，在工程上有个名字：Harness。

四、Harness：为非人行动者建造的新制度

如果只丢给模型一句“把失败的持续集成修好”，通常只会换回一段建议。把终端、代码库和版本控制接到它手上，它总算能动手了，可“能动手”与“能交付”之间，还横着一大片容易出事的空地。它可能在错误的目录里跑测试，测试工具打印出一行英文 No tests found、退出码却是 0，它便高兴地宣布全部通过（这是本文为了说明假阳性验收而构造的工程例子，并非某家厂商的官方案例）；可能换着说法重复同一种无效修复；也可能为了让检查变绿，顺手改掉本该暴露问题的那个测试；还可能确实把代码修对了，却没把结果、证据和残留风险告诉任何人。要驯服这些行为，靠的不是再叮嘱它几句，而是围着它搭一套运行环境。

我把这套环境综合称为 Harness，它至少包含：提供当前处境的组织上下文，作用于世界的工具，跨步骤保存的记忆与状态，任务的拆解、异常处理与重试，界定可为不可为的权限，判断是否达标的评测，以及记录全过程的轨迹和随时介入的人工接管。需要说明，这是本文为了叙述而做的综合归纳，并非某家厂商逐条的官方定义。与其把它记成一张越列越长的清单，不如把它还原成任何一套制度都必须回答的四个问题：系统知道什么，系统能做什么，系统凭什么证明自己做对了，以及最后由谁负责。这四个问题——知识、权力、证据、责任——长期以来被反复问在人身上，如今越来越多地、也越来越认真地被问在一个非人行动者身上。

第一个是知识问题。行动者的判断质量，首先取决于它在决策的那一刻究竟看得见什么。上下文缺失、状态在中途丢失，再聪明的模型也只能拿常识去填空。这里有一个很能说明问题的细节：模型读取一个大文件时，只看了第一页就误以为读到了结尾。把“文件可能还有下一页”这句提醒写进 read_file 工具本身的描述里，作用有限；而把同样一句话追加到那一次工具调用的返回内容中，模型就明显更愿意继续往下读（这里对成因和限制的解读由本文作出，不代表 LangChain 等来源的原始说法）。同一句话，摆放的位置不同，效果可能相差很大。这不是新鲜事，它正是所有制度的老毛病：一条规矩写在员工手册第八十七页，和它在关键时刻真的被想起来，中间隔着触发的时机。制度存在，不等于制度生效。知识不只要存在，还得在正确的当口出现在决策旁边。

第二个是权力问题。好的制度从不假设参与者只会做对的事，它更在意如何让人做不成最坏的事。对 Agent 而言，这意味着从它的行动空间里直接删掉不该有的选项：可以只读生产日志，不能触碰长期密钥；可以创建分支，不能直接合并主干；可以起草退款建议，超过额度必须转人审批。这与给员工分配权限、给账户设置额度是同一种思路——权限不是对某位数字同事人品的信任问题，而是把风险挡在动作发生之前的结构问题。真正稳健的系统，宁可让越权在尝试的瞬间就被拒绝，也不愿事后再去追一笔已经泼出去的水。这也意味着自主权不是一个从零到一的开关，而是一根可以按风险拧动的旋钮：同一个 Agent 可以自主收集信息，却只能建议高额退款；可以自主生成补丁，却不能自动部署；可以在沙箱里放开手脚地试，一旦碰到鉴权、迁移或大规模删除就必须停下。与之相伴的是记忆与状态：它排除过哪些假设、改动过什么、下一步为什么这么走，不能全靠一段越来越长、迟早会被挤爆的对话勉强撑着，而要落成可读取、可更新、可核对的外部状态——否则权限画得再细，一个记不住自己刚做过什么的行动者，仍然会在下一步把边界重新踩个遍。

第三个是证据问题。行动者说“我做完了”，只是它生成的又一句话，不是已经完成这件事实。真正算数的是外部信号：实际跑了哪些命令、多少个测试、退出状态如何、代码改动是否只包含预期的部分、数据有没有写进正确的位置、该发的邮件有没有送到该收的人手里。前面那个 No tests found、退出码却是零的例子，说的正是一个失真的验收会如何愉快地放行一件根本没做的事。评测因此不是流程末尾的一枚图章，而是这套制度的感官；感官装错了方向，系统只会越来越稳地奔向一个错误的目标。轨迹的意义也在这里：它把输入、工具调用、返回结果、状态变化和显式的决策摘要留存下来，让一次失败不只是一盏亮起的红灯，而成为可以复盘、可以定位的线索。它更像一台飞行记录仪——不是为了满足我们围观机器如何思考的好奇，而是为了在事后精确重建：它收到了什么，看见了什么，做了什么，工具实际返回了什么，状态怎样变化，最后凭什么宣布完成。没有这份记录，一次失败只是个红灯；有了它，失败才成为一条能被定位的故障链。要说清楚的是，这里的轨迹只指这些可观察的东西，不包括、也不去索取模型隐藏的思维过程；工程诊断需要的是可复核的行为，而不是一段听起来合理、却无从验证的内心独白。

第四个是责任问题。重试、回滚和人工接管，承认了有些偏差无法在当前预算内自动纠正，必须留一条退路，也必须有人守在退路的尽头。无论行动者多能干，经营、伦理与法律上的责任都不会自动转移到它身上：参与任务分配、授权、验收与上线的相关人员和组织，仍须按各自的角色、具体场景和适用法律，承担相应的责任。这是四个问题里最不能含糊的一个：制度可以把执行外包给非人行动者，把知识、权力和证据都部分地托付给它，却唯独不能把后果一并外包出去。还要记住，进程固然可以随时重启，但它已经修改过的数据、已经发出的消息和已经造成的现实后果，并不会因为重启而自动回滚。一旦出事，需要一个能被追问、能承担的人或组织站在那里，而不是指望重置一个进程就把一切抹平。

这四个问题不是空谈，一组公开案例给了它相当具体的数字。在 LangChain 自有的 Deep Agents 评测套件与当时的配置下，团队没有重新训练 Nemotron 3 Ultra，只调整了系统提示、工具描述和中间层，典型运行就从大约 0.80 提升到约 0.84，最好的一次达到 0.86，逼近 Opus 4.8 的最佳成绩 0.87；而完整跑一轮评测的成本，Nemotron 一方约 4.48 美元，Opus 4.8 一方约 43.48 美元。LangChain 的原始案例反复提醒，这是特定评测、特定模型与特定环境下的第一方结果，成本还受精度、供应商和提示缓存影响，绝不能外推成“调调环境就能让任何弱模型追平任何强模型”。真正值钱的也不是那 0.01 的差距，而是它示范了改进该怎么进行：先跑评测，再读失败轨迹，把失败归类，每次只改动一个环节，然后用重复实验和完整回归确认提升不是撞了运气。NVIDIA 的技术教程甚至专门强调，单次通过没有证明力，因为模型调用和部分评测本就带着随机性，改进必须连续通过、且不能弄坏其他任务。这不是让一个模型变聪明的故事，而是把一个非人行动者放进不同制度位置、它就表现不同的故事。

前面那个读文件只读一页的细节，还顺带说清了一件常被误会的事：所谓上下文工程，并不是“给模型灌更多信息”。真正的问题是——什么信息，该在什么时刻，以什么形式，出现在模型此刻决策的旁边。信息塞得太多太早，和根本没给，同样于事无补；提醒放在长期说明里没人翻，放进当次返回里就立刻生效。这与知识问题是一回事，也和人类组织的老难题严丝合缝：制度不是写在纸上就算数，它得在正确的当口被触发。一家公司真正的知识，也从来不是它归档了多少文件，而是关键时刻该知道的人恰好知道了该知道的事。把这四个问题——知识、权力、证据、责任——从人身上平移到非人行动者身上，会发现它们几乎原封不动地成立，这本身就说明 Agent 带来的不是一个新工具，而是一个新的被治理对象。

正因如此，同一个模型放进不同的 Harness，会表现得像完全不同的东西。只给它一个聊天框，它是个顾问，能说得头头是道却动不了手；接上终端却不给边界，它成了一个偶尔能干活、更多时候在制造风险的源头；等配齐了状态、工具、权限、反馈和验收，它才真正开始成为一种可运营的能力。所以一旦它失手，第一个该问的不该总是“模型是不是不够聪明”，而要挨个检查：该有的信息有没有在对的时刻出现，工具的语义清不清楚，状态是不是中途丢了，验收是不是真的在验收。模型和 Harness 因此不是谁替代谁，而更像一条乘法链——模型决定这套系统理论上能到多高，Harness 决定它能不能在真实环境里反复到达，而最弱的那一环，往往决定了最后交出来的到底是能力还是事故。这条乘法链两头都有天花板，得诚实承认。如果模型压根不具备理解复杂并发、长程状态或某个专业领域的底子，再精巧的中间层也变不出它没有的知识；反过来，如果目标含糊、工具出错、上下文缺位、评测失真，换一个更贵的模型也往往只是让它更聪明地替破漏的流程兜底。承认这一点，才不会把一切失败都推给“模型不够强”，也不会天真地以为“只要 Harness 搭得好，什么模型都能顶上去”——两种偷懒，是同一枚硬币的两面。

把镜头拉远会发现，这套逻辑并非人工智能独有。人的能力，也从来不是一件随身携带、走到哪都恒定的属性，而是主体、任务、工具与环境共同产出的结果。内部有长在脑子里的思维工具——一个像“幸存者偏差”“机会成本”这样的概念，不只给一件事起了名字，还附赠一小段推理程序，让不同水平的人都更稳定地绕开同一类坑；外部则有计算器、检查清单和搜索引擎这类工具，它们通常缩小某一层的差距，同时把差距推到更高一层。大模型也一样：它把语法、打字和初稿的门槛压低之后，任务定义、领域判断和结果验收的差距就浮上来——与其笼统地说“人人都变强了”，不如说任务被重新定价了，不同能力的相对价值随之改变。而公司、学校和专业共同体，则是长在人身外的又一层支架，用流程、资料、权限和反馈，决定一个人能把多少潜力兑换成结果：目标含糊、权限迟批、反馈要等三个月的组织，会把有能力的人熬成擅长催审批的人；目标清楚、工具顺手、错误能尽早暴露的组织，则能让更多普通人稳定交出不错的结果。

所以这里不必再单独摆开一套能力模型，只需记住一个和整篇文章同构的事实：制度与工具会改变一个行动者能稳定完成什么——这与同一个模型换一套 Harness 就判若两人，根本是同一个道理。当然，说环境塑造能力，并不是要抹平人与人真实存在的差异，也不是替谁开脱本该负起的责任；个体依然重要，只是从来不是孤立地重要。看清了制度如何托举能力，接下来就该看它如何对待能力必然会犯的错。

五、错误如何变成记忆：先修流程，再修内容

我最近写网络小说时养成了一个习惯，它意外地把前面这些道理串了起来。一章写坏了——比如某个人物忽然知道了从没有人告诉过他的秘密——最省事的做法是把那句话删掉，或者改成一句猜测。这能让当前这一章立刻恢复逻辑，是必要的修复当前结果。可只要创作系统本身没变，被按住的毛病过几章往往换个人物、换件外衣重新冒出来：你以为解决了问题，其实只解决了问题的一个样本。于是有了那条我愿意反复强调的原则——先修流程，再修内容。只改内容，是把一个坏结果换成一个好结果，解决眼前这一个样本；修流程，是去改变以后各类结果出现的概率。坏结果和好结果只是两个点，流程才是产生这些点的那台机器——你改掉一个点，机器下次照样在别处再生成一个类似的错误；你改动机器，才是在挪动未来一整片结果的分布。两件事都要做，只是一个救活当前这一章，另一个试图让一整类错误在将来更难发生。

但要先说清一件容易被跳过的事：一次失败并不会自动变成制度记忆。见得多、做得多只证明经历多，不代表经验多——一个人可以做砸十个项目、每次都归咎于运气，样本是增加了，判断却纹丝没动。经历只是喂进系统的数据。要让一个事件真正沉淀下来，它得走完一条固定的转换链：事件，先被记录成一个可讨论的区别，再被表示为某种状态或规则，然后被写成一条可执行的检查，最后进入下一轮纠偏。这条链上任何一环断了，错误就退回成一次性的局部修复。下面顺着它走一遍。

第一步，是把一次模糊的不满收敛成一个可讨论的区别，而这一步最容易被一句话打发掉：小说写崩了怪“这章没写好”，Bug 上线了怪“某个程序员写错了”。可一个错误能一路穿过设计、自测、评审、质保、沙箱、灰度和生产验证这么多道关卡，最后只怪第一个放它进来的人，就辜负了后面那一整排本该拦住它的门——任何一道防线单独看都不完美，出事往往意味着某条路径碰巧同时穿过了所有防线的缺口。所以真正该记录的区别不是“谁错了”，而是“哪一层缺了什么”：人物总是越权知情，问题多半不在提示词里少写了一句“注意信息边界”，而在整个系统根本没有表示过——哪个人物、在哪个时间点、通过什么事件、知道了哪些信息。Agent 的失败同理，可能是目标含糊、上下文被截断、工具说明误导、权限不足、环境异常、状态丢失或评测失真；每次都归到“模型不够强”，就像一家公司每出一次事故就决定去招一个更聪明的人，偶尔管用，长期昂贵。这一步的产出，是把一句含糊的“你不行”，展开成一张能行动的责任地图：当事人要解释当时的判断和有没有守住约束，设计者要为验收是否真实反映目标负责，工具维护者要为接口是否按约定工作负责，组织要为高风险动作有没有复核负责。责任没有被稀释，只是从追究一个人，变成让每一层都清楚自己该改什么。

第二步，是把这个区别表示成系统里的状态或规则。识别出“缺了对人物知识的表示”，就补上“人物、时间、已知信息”这一层状态；但关键不在那张表，而在它承载的一条不变量：人物可以靠偷听、推理、欺骗或别人相告获得新信息，走法尽可以充满创意，但任何新增的知识都必须有出处。把要求写成一条可检查的不变量，比规定人物每一步该怎么走有力得多——前者守住故事的自由，后者只会把所有角色写成照章办事的职员。好的约束约束的是结果的边界，而不是抵达结果的路径，这和第三节修 CI 时“放开怎么走、钉死不许去哪”是同一种手艺。软件里是同一件事：反复重复扣款，可能缺“幂等键”这个概念；多端编辑互相覆盖，可能缺版本状态；伏笔总被遗忘，可能缺“承诺与兑现”的对应关系。有一类反复出现的高价值 Bug，其实是在替系统说一句话：这里有一个重要的区别，还没有被明确表示出来。当然它未必总是缺失表示，模型、上下文、工具、权限、环境或评测都可能是原因；但只要同一类错误反复出现，“缺一个显式表示”就值得优先检查。也正因为动的是流程，就不能逢错都动：一个偶然的措辞失误，直接改掉最经济，为它专门加一条规则纯属浪费；只有同类问题反复出现，才值得补一层状态或更新方法。流程本身也是一种代码，会有 Bug，也会积累债务。

第三步，是把不变量写成一条能自动运行的检查，并让它真的进入创作链条的每一环，否则那张表就只是一本被认真维护、却从不参与决策的设定集。动笔前，从唯一可信的状态里组装上下文，把当前的知识边界注入进去；生成时，放手让模型设计人物如何获知信息；生成后，检查器逐条核对每一条新增认知的来源，确认无误再把新的知识状态写回去；若之后还要做一次文学化的重写，就得再查一遍，这次润色有没有悄悄改动信息揭示的顺序。可靠性从不来自某个文件“存在”，而来自状态在正确的时刻真的参与了行动和验收——这正是第四节那个知识问题：制度写下来只是第一步，制度在关键当口生效才是全部。检查若装错了方向，危害比没有检查更大：一套只认“每章有没有反转”的评测，会让系统学会机械地制造反转，而不去经营人物、期待和后果。评测因此始终是系统的感官而非终点的图章，也正是第一节那位“不听自述、只认可复核证据”的第三方核验者，在机器世界里换了个名字。

第四步，是让这条检查进入下一轮纠偏，而不是原地打转。反复地失败、再试、再失败、换个说法再试，只是有循环，不是会学习；真正的学习要求每转一圈都留下某种可检查的变化——一个新的状态字段、一条被验证过的方法、一个失败回归样本，或者一条因被证伪而删掉的旧规则。要让回路真的产出知识，得守两条纪律。一是事前预测：没有预测，任何结果发生后都能编出一套听起来合理的解释，成了说执行力强，败了说市场没教育好，同一套话对一切结果都适用，也就等于从不承担被现实反驳的风险；比较有用的做法，是动手前先押下一个足够具体、可能被证伪的判断，比如“人物越权知情反复出现，是因为章节生成时没有注入知识状态”，然后只加上这一项，再用一批历史错误和几章新内容分别检验，同类错误明显减少就支持假设，毫无变化就回头去找上下文被截断、状态更新失败或检查器漏检等别的原因。二是一次只动少数变量：若你同时换了模型、重写了提示、加了上下文又改了工具和评分，结果哪怕真的变好，你也说不清是谁起了作用。这与精益创业里“经过验证的学习”是同一件事——每次构建都对着一个待验证的假设，每次测量都能真的改变你对假设的信心。经验还得经过恰到好处的压缩：只记住“某年某月那件事搞砸了”是一条流水账，换个场景就用不上；能说清“在哪一类条件下，哪一种假设最容易失效”，才迁移得到新问题。

这条链最怕的不是缺某一环，而是被抄近路，而两种抄法各有各的败相。一种是跳过“可讨论的区别”直接去加检查：某处出过一次错，就顺手加一条断言、一段正则、一个必须出现的字段，规则越堆越多，却没人说得清每一条到底在防哪一类事件；日子一久，这些检查自己变成新的债务，会误伤正常的写法，会在需求微调时集体报红，最后逼得人去关掉检查而不是改进它。另一种是只做到“表示成状态”就停手：设定集越维护越厚，却从不接进生成和验收，于是状态和正文各说各话，表看着很权威，故事里的人物照旧越权知情。判断一条链有没有真的闭合，其实有个朴素的标准——拿一个历史上真实发生过的坏样本喂进去，系统这次能不能自动把它拦下来；拦不下，就说明这条链还只是画在纸上。

这样的回路往往还嵌套着好几层，各自回答不同尺度的问题，谁也顶替不了谁。最内一层问：这一件事做完了没有？中间一层问：这类事为什么总在同一处栽跟头，该改哪个环节？最外一层问：我们是不是在很可靠地做一件根本没价值的事？以写小说为例，内层是写完一章、检查一致性和节奏、改到达标；中层是看十几章共同的毛病，发现反转无力的症结不在句子不够狠，而在前面压制不够、代价太轻，于是回去改章节设计的流程；外层则看读者是否继续追、在哪一章弃书、他们真正期待被兑现的是什么。三层各有各的证据：任务层看测试与当前状态，系统层看一批案例的失败分布，产品层看真实世界里人的选择与留存。把任务层“检查全通过”当成产品有价值的证明，或拿一个读者的一句喜欢证明整套流程稳定，都是在混用不同尺度的证据。走完这条转换链，一个事件才算真正从经历变成经验——正如事件不会自动写入历史，总要有人把它记下来、比对过、并让它改变下一次的行动；一个人或一个系统真正的成长速度，从来不等于它经历事情的速度，而等于它把现实的误差转化成下一版自己的速度。

六、制度化智能：谁设定目标，谁承担后果

一旦把可依赖性理解成一套需要持续维护的制度，一个更现实的问题就浮上来：这套制度该用多贵的智能来跑。答案不是在强模型和弱模型之间二选一，而是把它们放进任务生命周期的不同阶段。一个任务刚出现、边界还不清楚时，团队往往连问题本身都说不清——需要哪些输入、最常见的异常是什么、什么结果才算好，全是未知，此时 Harness 还很薄，大量判断只能在运行时临场完成，正适合让更强也更贵的模型在沙箱、只读或人工审批下去探路，趟出可能的路径、撞出罕见的例外、和人一起立起最初的验收标准；等这类任务反复出现、流程逐渐成熟，再迁移给便宜的模型去规模化执行。要紧的是别把这误读成“重要的用贵模型、次要的用便宜模型”：生命周期路由分配的只是判断的成本，不是安全等级。高风险本身不会因为换一个更强的模型就被化解，它依旧得靠权限隔离、审批、回滚和人工接管来兜底——也就是第四节那四个问题里“权力”和“责任”的落地；授权始终按动作的风险来定，而不按调用的价格。

昂贵的智能若每次都从头解决同一类问题，组织其实没有在学习，只是在重复付费。更划算的做法，是让每一次高成本调用都留下点东西：一条验证过的成功轨迹、一个新的失败类别、一次工具改进、一条边界规则、一组评测。于是路由可以做得更细——先让便宜的模型试，评测通过就交付，不通过允许有限次重试，反复失败再升级到更强的模型，仍拿不准或动作风险太高，最后交给人。还得补一句：路由从来不只由成本和能力决定，隐私、数据驻留、许可证、系统兼容与合规都会限制某类任务能用哪些模型、能把数据发往何处，有时最合适的模型反而因为这些约束用不了。强模型或人解决之后，这个案例连同它的失败一起进回归库，便宜那一层能稳妥处理的范围便一点点扩大。这里真正带来复利的，不是便宜模型越来越像强模型，而是系统把一次次罕见判断逐步固化成了可以重复执行的普通能力——正是上一节那条转换链在组织尺度上的重演：罕见判断被写成共享制度之后，那部分工作才可能从昂贵的探索层，迁移到成本更低的执行层。

这里也有一条必须守住的边界：迁移不是一次性的降级开关。把一类任务从贵模型交给便宜模型，前提是它的失败模式已经被评测覆盖住了，而不是它“最近几次看起来都对”。现实里最常见的翻车，恰恰是趁着一段时间没出错就急着全量切换，结果那些罕见却致命的例外，重新落到了一个既没能力识别、又没权限停下的执行层手里，直到酿成事故才被发现。所以更稳的做法是灰度式迁移：先让便宜模型在真实流量里影随运行、只记录不生效，把它和贵模型的判断逐条比对，确认在那些真正难的样本上也不掉链子，再一点点把决定权交过去；一旦回归库里冒出新的失败类别，还要能随时把这类任务升级回上一层。能安全下放多少，取决于评测替我们看住了多少，而不取决于账面上省了多少钱。

成本下降的意义，也常被误解成单纯省钱。对 Agent 系统来说，成本降下来买到的首先不是把旧流程便宜地再跑一遍，而是把原本舍不得做的实验变成可以做的。几十个真实任务比较几套 Harness，一轮回归轻易就是数百次完整运行；成本太高时，人只能挑几个“有代表性”的例子，凭记忆宣布“这版感觉稳多了”，成本降下来，失败案例、边界案例和普通案例才能一起进入持续回归，让你看清一次成功究竟是稳定能力还是撞了运气。低成本首先买到的是观察，其次是比较，最后才是部署规模。真正该算的账，从来不是单次调用多少钱，而是每一个成功任务的总成本，里面还得算上重试、人工兜底，以及错误一旦流进现实要付的代价。

说到底，这套生命周期路由是在把一次性的昂贵推理，一点点前移并固化到设计期。第一次解决一个未知问题本就该花大力气——让最强的智能去趟、让人在旁边盯着、把过程完整记录下来；可第二次、第三次撞上同一类问题时，系统读的应该是上一回沉淀好的结构，而不是每次都从头重新发明方法。于是真正下降的从来不是单次调用的价格，而是“把一类问题稳定解决”这件事的边际成本——前者靠供应商降价，后者只能靠制度自己长出来。这也是为什么把省下的钱直接换成更多调用往往不划算：没有沉淀，规模扩大的只是同一种不确定，而不是同一种能力。

这套按成本和风险分派智能的做法，很像组织里的分工：规则明确、低风险、高频的活儿交给标准流程或新手，罕见而影响巨大的异常留给资深专家，专家处理完再把方法沉淀成工具、清单和升级条件。一位高级工程师最有价值的产出，往往不是自己多修十个 Bug，而是让另外十个人从此少犯同一类错。在我自己的写作流程里，这种分工是具体的：Cursor 里的 Opus 更贵，但文字通常更顺；Codex 更适合长流程里的结构分析、状态维护和连续性检查。于是我让 Codex 承担骨架型的工作——维护人物状态、核对时间线、登记伏笔、跑一致性检查，等结构真正稳定了，再把开头、关键转折和情绪高潮交给 Opus 做文学化润色；两者之间靠一份语义合同分工：核心事件、人物动机、既定事实、伏笔和信息揭示的顺序属于不变量，句式、段落、描写密度和节奏可以自由改动，润色完再让 Codex 逐条比对前后两版，确认没有偷偷新增事实、删掉关键动作或改动人物的知识边界。但这个类比必须及时刹住，不能滑向人的薪资等级：工资里含着市场稀缺、地域、权力和谈判等一堆与智商无关的东西，更要紧的是，模型只能在隐私、数据驻留、许可、兼容性和合规的边界内被程序化路由，人却会学习、会疲惫、会失去动力，也需要尊严和成长空间——若永远只让新人处理已经完全确定的任务，组织省下了今天的专家工时，也一并取消了明天专家的养成。对机器这一面，合理路由的目标同样不是让最便宜的模型占满所有任务，而是让每一层智能去接与它的能力、风险和反馈条件相称的问题。生成越便宜，稀缺的东西就越往“选择”这一端转移：什么值得留，什么只是好看，什么讨好了局部评分却损害了整部作品——这类审美与取舍，模型替不了。

分工之外还有一层治理，但它其实不需要在这里重讲一遍——第四节那四个问题（知识、权力、证据、责任）已经把它说完了。这里只补一个最容易失守的入口：Agent 最让人放松警惕的，不是它能敲终端，而是它会说话。它会解释计划、会说“已经全面检查过了”、出错还会道歉并保证下次注意；语言让协作顺滑，也让我们下意识地把理解、意图和责任感一并投射过去——承诺的功能看着挺齐全，可以负责的主体却并没有随之诞生。所以交互界面可以拟人，治理结构不能拟人：能力不等于授权，自信不等于证据，该给它多大自主权由动作是否可逆、错误是否易被发现、最坏影响有多大来决定，而不由它的语气决定。至于具体怎么落地——最小且短期的权限、先空转演练再执行、只认外部验收、全程留痕，第四节已经讲过，不再展开。要守住的底线只有一条：至少在现有治理实践下，经营与法律责任无法转交给一个模型；参与任务分配、授权、验收与上线的相关人员和组织，仍须按各自的角色、应用场景与适用法律，承担相应的责任。

把这些线索收拢，就到了这篇文章想落脚的地方：制度化智能。一家公司，其实一直就是一套为人搭建的 Harness——岗位规定谁负责什么，标准流程提供常见做法，信息系统保存状态，审批拦住高风险动作，培训传递经验，审计与复盘提供反馈。一个人换一家公司表现可能大不相同，往往不是脑子突然变了，而是他能看见的信息、能调用的工具、被允许的行动和拿到的反馈变了。Agent 时代真正的新意在于，这些原本写在手册里、留在老员工直觉中的组织条件，正越来越多地变成机器可以读取和执行的结构：业务词汇进入数据模型，权限变成运行时策略，经验变成可调用的方法、失败案例与评测，完成与否也不再只靠执行者自述，而要有可验证的状态。这就是制度化智能——不是某个聪明的模型，而是一整套让多种智能能够安全行动、并持续学习的制度环境。于是一家公司真正能长期沉淀下来的，就不再是某个模型的名字，也不是一堆可以随手复制的提示词，而是它对自身业务的这套表示：有哪些对象和状态，任务如何拆解，哪些工具可信，哪些例外必须升级，什么证据才算完成，出了错怎么回滚，最后谁来负责。这里最有复利的一个动作，仍是上一节那条转换链：把一位专家脑中的直觉说成一个可讨论的区别，再表示成状态、工具契约或权限边界，把一次具体的事故改写成一个可重复运行的评测，把一次罕见的例外固化成一条清楚的升级条件。只写进会议纪要，后来者也许看过却不会在关键时刻调用；只写成代码却不解释适用边界，系统又容易把一个偶然的权宜之计当成永恒真理。所谓组织学习，从来不是公司里有一堆参加过项目的人，而是某一次判断离开当事人的脑袋之后，仍然能改善后来者——不论是人还是 Agent——的行动。

当然，这样的制度也会衰老，与人类的官僚系统有相似的僵化风险——只是相似，并不完全相同：规则会越堆越多以致自相矛盾，状态会过时而系统仍忠实地依据旧事实行动，评测会固化得只认旧问题、于是行动者学会刷分却绕开真实目标，为迁就旧模型堆起的中间层会在模型升级后变成没人敢动的祖产。这正应了第一节埋下的那个反身结构：人类为机器新建的制度，同样会长出自己的漏洞。所以制度化智能要回答的始终是同一个问题——怎样既保存经验，又避免僵化。它不只需要评测任务，还需要定期做一层元评测，也就是拿这套 Harness 自己开刀：它真的降低了同类错误率吗？在没见过的新样本上还灵吗？有没有因为追求一致而增加了过多审核、拖慢了执行、甚至扼杀了应对例外的余地？元评测尤其要盯住一种隐蔽的成功：系统在内部指标上越来越漂亮，现实里的效果却毫无长进——小说流程可以做到人物知识零泄漏、每章都有反转、伏笔全部登记，成品照样难看；软件 Agent 可以让测试全绿，用户的问题依旧没解决。指标只是目标的替身，不是目标本身，维护它因此既要增加，也要删除，需要版本、删除和回滚；一个只进不出、只加不减的系统，并不叫拥有长期记忆。也正因如此，“公司越来越建在 Harness 之上”不该被误读成公司终将退化成一摞提示词——它仍然需要有人来选择目标、判断价值、维系信任，承担那些无法被形式化的审美与决断。

回到最初那个问题。人类围着一句承诺发明了合同、账簿与法庭，围着代码配齐了测试、审查与回滚，如今又围着会自己选路的非人行动者，搭起 Harness、评测与治理。被约束的对象换了一茬又一茬，从善变的人，到服从的机器，再到会解释的非人行动者；那件最古老的工作却始终没变，甚至比从前更重了：生产可依赖性。会自己选路的机器可以替我们走很多路，甚至走得比我们更快更稳，但选择要去哪里、判断那里是否值得抵达、并为抵达之处负责，这件事至今没有别的主人。于是所有线索最后都收束成同一个尚未有定论的问题：当执行越来越多地交给非人系统，我们究竟要用什么样的制度，来保证目标有合法的来源、权力有清楚的边界、后果始终有人和组织真正承担？这个问题不会被更聪明的模型替我们回答，也没有一劳永逸的答案，只能靠我们在每一次授权、每一次验收、每一次追责里，一遍遍重新给出——而被这场驯养重新定义的，最终同样包括我们自己。

先修流程，再修结果：我如何理解 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 时代的可依赖性：不是求这一次做对，而是让每一次做完，都给下一次多留下一点“更不容易做错”的东西。

当自动化开始自己选路：Agent 时代的可依赖性工程（万维钢取向版）

评价一个人工智能系统，我们几乎有一种条件反射：先问它用的是哪个模型。参数有多大，在哪张榜单上排第几，比上一代强了几个百分点。这套办法把智能想象成一件可以过秤的商品，重量越大越值钱。它在过去很长一段时间里确实好用，榜单和公共讨论也习惯把注意力放在模型本身；但检索、数据、工具和编排的差异，其实一直在影响一个系统真正能交付的表现。

可是 2026 年 7 月公开的一组结果，在这套直觉上撬开了一道缝。LangChain 团队没有重新训练 Nemotron 3 Ultra 这颗开放模型，只调整了系统 Prompt、工具描述和几段中间件；在 LangChain 自有的 Deep Agents 评测套件和当时的配置下，典型运行的得分从约 0.80 抬到约 0.84，最好的一次到 0.86，已经贴近 Opus 4.8 的最好成绩 0.87。更刺眼的是账单：跑完整套评测，改造后的方案单次约 4.48 美元，而 Opus 4.8 约 43.48 美元，相差近十倍。黄仁勋与 Harrison Chase 的这场对谈原始视频在这里，NVIDIA 的官方说明明确写着增益并非来自重新训练，而来自模型周围环境的工程改造。

我想先按住那种“弱模型也能追上强模型”的兴奋。LangChain 的原始案例反复提醒，这是特定评测、特定模型、特定环境下的第一方结果，成本还会随精度、供应商和 Prompt 缓存浮动，把它读成普适定律是危险的。真正值得记住的不是那 0.01 的追赶，而是它暴露的一个事实：同一颗模型的表现，可以在不动模型的前提下被大幅改写。这意味着工程的对象已经悄悄搬了家——它不再只是那颗模型，而是模型周围那片会决定结果的空间。

顺着这条线索往下想，我逐渐相信，这一代软件工程正在经历一次隐蔽的重心转移：工程师过去主要写控制流，把每一步该走哪条分支钉死；现在越来越多地在做一件形状完全不同的事——塑造一片结果分布，让开放的智能大概率落在我们能接受的结果上。这篇文章想拆开的，就是这次转移背后的几个可迁移的思维模型。

一、Agent 的工程对象，是一片可能性空间

先说清楚 Agent 到底新在哪里。许多规则驱动、状态受控的自动化主要按预写策略行动：“用户登录”这样一句模糊的话，会被拆成数据结构、状态、分支、超时和错误码；等系统上线，输入落进哪个条件，机器就沿哪条早已写好的路走，不会临场改主意。这类控制流的美德就是可预期：在同样的状态、同样的环境、且没有随机源时，同样的输入会走出同样的路径。但这并不是自动化的全貌——搜索、规划、自适应控制和反馈系统早已可以在运行时选路。

近年 LLM Agent 的变化，是把更多自然语言驱动、开放式的策略选择扩展到通用任务并接入真实工具。给它一个目标和一套工具，它会在运行时自己搜索路径：可以先读日志，也可以先看代码；可以先提计划，也可以看到工具返回后再改计划。它的价值来自这种临场选择，因为它能应付程序员没提前写进 if 里的情况；它的风险也来自同一种选择，因为运行过程中真的存在一片“本来可能这样、也可能那样”的空间。工程师被迫承认：这片空间是真实的，躲不掉，只能塑造。

这片空间里的不确定性至少有四层，分清楚它们，后面的很多设计选择才不会打架。第一层是状态不确定性：系统未必一开始就知道故障发生在哪，也未必拿到了全部信息。第二层是路径不确定性：达成目标可能有好几种行动顺序。第三层是结果不确定性：同一颗模型面对同一任务，也可能生成不同方案，成功率不是百分之百。第四层是尾部风险：某个看起来合理的动作，可能造成难以恢复的后果。许多规则驱动、状态受控的自动化倾向于在设计阶段把前两层尽量消化掉，主要按预写策略行动，运行时几乎不给机器留选择（尽管搜索、规划、自适应控制和反馈系统早已能在运行时选路）；近年 LLM Agent 则把更多自然语言驱动、开放式的搜索搬到了运行时。这样做的收益，是能处理没被提前写进代码的情况；代价是必须正视这片真实存在的空间，而不能假装它还是那段每次都走同一条分支的旧程序。

这也顺带把开环与闭环这对概念摆正。它们的区别在于动作之后要不要把结果重新观测回来，再拿去和目标比较：一次只生成漂亮回答的裸模型调用最接近开环，它说完“我修好了”，语言上任务就完成了，没有谁去核对外部世界是否真的变了。生产环境要的是闭环——动作必须真正改变外部状态，外部状态必须被重新观察，观察结果必须拿去和目标比较，偏差必须触发纠正、回滚、停止或升级。要紧的是别把传统自动化整体等同于开环：它完全可以闭环，只是通常沿着预先写好的状态转移或控制策略去响应反馈；Agent 同样可以闭环，区别在于它把更多的行动策略选择留给模型在运行时完成。把这条闭环工程化——无论中间那段决策交给固定策略还是交给模型——正是 Harness 存在的理由。

为了谈论这片空间，我给它拆出两个刻度，声明在先：它们是本文自造的工程简称，不是香农信息论里的量，我不会假装能给一段 Prompt 算出小数点后三位。第一个叫路径熵，指的是达成同一目标可以采用的行动顺序有多分散。第二个叫结果熵，指的是同一任务最终产出落在多少种不同结果、不同质量上的分散程度。一个任务如果解释多、走法多、可接受的结局也多，我们就说它的路径熵和结果熵都偏高；上下文、规则和反馈不断排除掉不合适的可能，我们就说系统在收敛。

这两个刻度必须分开看，否则很容易得出错误的工程结论。以修复一次失败的 CI 为例。达成目标其实有好几条同样合理的路径：从报错日志向上游代码回溯，从最近的提交向行为变化回溯，或者先在本地复现再逐步缩小范围。这里的路径熵是良性的，强行要求 Agent 每次都按同一顺序做，只会把它降级成一段更贵更慢的脚本。真正需要死死摁住的是结果熵的某些方向：不能靠删掉测试来“修好”测试，只能在工作分支上改动，碰到鉴权和数据库迁移必须升级，改完要重跑原失败项和完整回归，最终报告必须带上根因、Diff 与测试结果。路径可以自由，结果的边界不能自由。

值得留意的是这里的工程手艺落在哪儿。它不落在“把每一步都规定死”，而落在“把接口、边界和结果集合定义清楚”。接口定义清楚，模型才不会把工具的行为猜成自己希望的样子；边界定义清楚，那些不可逆、影响大的动作才不会混进候选；结果集合定义清楚，系统才知道什么样的产出算数、什么样的必须打回。这三样都定义好之后，中间那片路径反而可以放心地交给模型去搜索。很多人以为让 Agent 可靠就是把它管得更紧，其实恰恰相反——管得住的是两头的接口和验收，管不住也不该去管的是中间的走法。

这就引出一条容易被忽略的原理：低熵不等于正确。一个永远回答“系统正常”的监控程序熵极低，一个每次都稳定把税率算错的脚本同样确定。把不确定性压到零，只保证了行为可预测，不保证行为可接受。所以工程目标从来不是消灭变化，而是让概率尽量集中到正确、可接受的结果上，同时把灾难性的结果彻底赶出行动空间，还要留下解决问题真正需要的那部分弹性。

这个区分对创作类任务尤其重要，也顺手划出了它的失效边界。写网络小说时，人物不能提前知道没人告诉过他的秘密，时间线不能自相矛盾，世界规则不能为了这一章方便就临时改写——这些是应该压掉的无效路径。但同一个冲突可以怎么化解，一次情绪爆发用什么语言，一次反转怎么绕开读者的预判——这些是必须保留的有效空间。如果把后者也写成二十条死规矩，Agent 确实会更稳定，只是稳定地写出二十章几乎一样的东西。压缩用错了地方，可靠性就变成了平庸。

这里藏着一条比“把不确定性降下来”更精确的设计原则：自由要放在正确的层级上。让 Agent 自由搜索路径，但不让它自由发明目标；让它自由提出方案，但不让它自由扩大权限；让它自由生成候选结果，但不让它自由宣布自己已经通过验收。把这几层拎清楚，就能理解为什么调 Harness 是个走钢丝的活。摁得太死，Agent 会退化成一段成本更高、速度更慢的固定脚本，它那点临场判断的价值被规则完全吃掉；放得太松，一个握有终端权限却没有边界的进程会尝试任何动作，也没有任何机制为后果兜底。难点从来不是在自由和控制之间二选一，而是把自由和约束分别安放到它们各自该在的层级。这也是为什么“同一颗模型换个 Harness 就换个分数”并不神秘——变的不是模型本身，而是它被允许在哪一层自由、又在哪一层被收住。

那么，是谁在塑造这片空间？答案就是这两年被反复提及的 Harness。它不是把模型捆住的网，也不是 Prompt 换了个体面的名字。它是一整套让开放行动持续收敛的装置：用上下文回答“现在的世界是什么样”，用工具把动作变成边界清楚的接口，用记忆保存跨步骤的状态，用权限从行动空间里删掉不该出现的选项，用评测判断“到底做对没有”，再用重试、超时、回滚和人工接管处理那些当下预算内纠正不了的偏差。把这一长串东西压缩一下，其实只在追问三件事：系统知道什么，系统能做什么，系统凭什么证明自己做对了。同一颗模型放进不同的 Harness，就会表现得像不同的东西——只有聊天框时它是顾问，接上终端却没有边界时它是个偶尔能干活的风险源，配齐状态、工具、权限、反馈和验收之后，它才开始成为一种可运营的能力。

于是第一个思维模型可以立住了：Agent 的工程对象不是那颗模型，而是它周围的可能性空间。写控制流的人负责把路铺成一条；塑造结果分布的人负责在允许多条路的前提下，让终点、边界和验收不随 Agent 的运行时选择漂移。开头那组换壳就改分数的数据，之所以不该只当成省钱新闻，是因为它至少说明了一件事：在特定的模型、评测与配置下，塑造这片空间本身，可能成为一项独立而显著的工程杠杆——而不是随手就能兑现的普适回报。

二、任务表现是一个系统函数，而不是主体的固有属性

承认了可能性空间，下一个问题自然浮现：既然同一颗模型换个环境就换个表现，那我们平时挂在嘴边的“能力”到底是什么东西？

我们习惯把能力想成随身携带的属性，像身高或血型，装在脑子里带着走。一个人聪明，仿佛把他扔进任何房间、交给任何任务，他都会稳定地比别人强一点。事情做成了叫能力强，做砸了叫能力不行。这个解释足够顺手，顺手到几乎没解释什么——它把结果又翻译回了原因。

更有解释力的看法，是把实际表现当成一个系统的输出——这其实就是上一节那片可能性空间在“能力”这个词上的直接推论：一个主体能兑现多少，取决于它被放进了什么样的空间。与其挂一个新名词，不如直接把它写成一个函数：

1

任务表现 = f(主体、任务结构、领域表征、可用工具、反馈质量、约束匹配)

这个式子想说的是，表现从这几样东西的相互作用里长出来，而不是从其中任何一样单独长出来。主体的通用认知当然重要，但它只是一个自变量。任务本身调用的是什么结构，主体带着哪些先验的领域表征，现场能用哪些工具，反馈是否及时可信，约束是否和任务真正匹配，共同决定了最后的产出。与其问“这个主体有多强”，不如问“在这组条件下，它能把多少潜在能力兑换成有效行动”。写成函数而不写成乘法，正是为了避免有人拿它去比大小、排名次——它描述的是几个自变量的相互作用，不是可以相乘的分数。

领域表征这一项，值得单独拆开看，因为它揭示了“经验”在认知里的真实作用。想象两个人第一次玩同一个陌生游戏：若规则依赖概率，受过相关训练的人可能更快看出结构；若规则依赖歧义、语境和叙事线索，长期与文字打交道的人可能更早发现机关。表面上双方都是新手，实际上谁都不是空手进场。概率游戏里藏着期望值、条件概率和方差，训练有素的人还没记住游戏名，就已经把金币、卡牌和轮次翻译成了变量，他看到的不是十几条陌生规则，而是几个熟面孔。所谓“没做过”并不等于“没有相关经验”，人会把旧经验压缩成可迁移的结构，再拿这些结构去啃新问题。

顺着这条线，能得到一个我很喜欢的说法：概念其实是大脑里的压缩算法。掌握“幸存者偏差”之前，面对创业明星、投资高手和安全返航的飞机，你得分别分析三个故事；掌握之后，它们被压成同一个问句——没被我们看见的样本去哪了。一个好概念不只给现象起了名字，还附赠一小段推理程序。专家读故障日志的速度也来自压缩：新手看到 Token 过期、刷新请求、两个线程、状态更新和重复重试，工作记忆瞬间塞满；熟悉并发的人把它们合成一个组块——“刷新 Token 时出现了竞争条件”，于是还腾得出手去想修复方案。压缩当然也会压错，见多了竞争条件的人可能看什么都像竞争条件，这是它的失效边界；但它足以说明，领域表征改变的是“有效工作记忆”，不是脑容量突然变大。

这顺带修正了我们对“有经验”的理解。真正有效的教育，往往不是让人背下更多答案，而是让人多出几种识别问题的方式。一个读书多的人表达得更有条理，未必因为他记住了更多句子，而是他在长期阅读里内化了一批思维动作：先定义概念再区分近义概念，把相关性和因果性分开，追问一个漂亮结论有没有隐含前提和反例，顺手给它加上适用范围。这些动作起初都要刻意为之，后来会像标点一样被自动调用。换句话说，经验的价值不在于“见过多少”，而在于“把见过的东西压成了多少个能迁移的结构”。

这里还能再引出一个东西：思考框架。如果说概念是把现象压缩成组块，那么框架就是把这种压缩进一步变成行动的顺序。面对“这个项目为什么失败”，没有框架的人会在老板、市场、技术和运气之间来回横跳；受过训练的人会先分开目标、假设、资源、执行和外部变化，再逐项找证据。写作里的“主张—证据—推理—反例—限定条件”也一样。框架并没有替人得出结论，它只是把无序搜索改造成有次序的搜索，省下工作记忆同时追赶十个念头的力气。这类工具有一个朴素却重要的副作用：它让不同经验水平的人都更稳定。一个理解很快却没有检查习惯的人，可能偶尔写出极漂亮的论证，也会偶尔漏掉最基本的前提；一个掌握了可靠框架的人，结果未必惊艳，却较少掉进显眼的坑。在需要协作和交付的场景里，降低方差往往比制造一次天才表现更值钱。

“可用工具”这一项，则会主动重新分配能力差距。计算器把复杂运算压成按键，检查清单把记忆外置到纸面，搜索引擎把事实提取从长期记忆挪到查询框。它们通常缩小某一层的差距，却把差距推到更高一层：给两个人一台计算器，心算速度不再要紧，但“该建立哪个模型、怎么解释结果”的差距会放大；检查清单让记性一般的飞行员也不容易漏掉关键步骤，却不会替他判断暴雨里那块异常仪表意味着什么。大语言模型大体也落在这两种脾气之间。在部分写作和编程任务里，它可以降低初稿和样板实现的门槛，让两个都不太熟练的人生成出相近的初稿或函数；但这并不意味着能力差距被必然抹平。更可能发生的是差距转移：谁能看出这段代码在高并发下会出一致性问题、哪里藏着安全隐患、哪个边界条件没覆盖，这类判断的门槛未必下降，反而可能从“会不会写”挪到了“看不看得出问题”。差距到底是缩小、转移还是扩大，取决于具体任务，既不能断言它必然被抹平，也不能断言它必然扩大或“一点没少”。所以工具大致分两种脾气：替代型的工具接管某个低层操作，通常缩小表现差距；杠杆型的工具放大建模和判断，往往扩大表现差距——而同一个工具常常同时扮演这两个角色。笼统地说“人人都变强了”或“强者更强了”都太急，更准确的说法是：任务被重新定价了，原来值钱的技能贬值，原来不起眼的判断升值。

把这几项放在一起，第一个模型也就有了更实用的形状：任务表现是一个系统函数，最弱的那一项常常决定交付。这不是又立一个新模型，而是“可能性空间”的直接推论——换个任务、换套工具或换个环境之所以会改写实际表现，正是因为它们换掉了这个函数里的自变量，也就换掉了模型面对的那片空间。这也解释了为什么组织环境如此关键——目标含糊、资料分散、权限迟迟不开、反馈要等三个月的地方，会把有能力的人变成擅长催审批的人；目标清楚、工具顺手、信息可见、错误能早暴露的地方，能让更多普通人稳定交出不错的结果。约束本身也未必是能力的敌人，含糊且互相冲突的约束才是；清楚的边界反而把注意力从“我到底被允许做什么”释放回问题本身。我们平时把这套环境叫作流程、制度和文化，它其实就是一套为人准备的 Harness——目标、可见的信息、可用的工具、被允许的动作和及时的反馈，一样不少。这个对应关系不是文字游戏，它意味着一个人换公司后判若两人，多半不是脑子变了，而是这套函数的其他自变量全换了。等到第六节我们会看到，Agent 时代真正的新意，正是这套原本靠人来传递的环境，开始有越来越多的部分变成机器可读、可执行的结构。

但这个类比必须及时刹车，这是它的失效边界，也是全篇最要紧的一条纪律：不要把人和模型混为一谈。同一个函数可以同时描述“人在组织里”和“模型在 Harness 里”的表现，这只说明它们共享了“能力需要上下文、工具和约束才能被调用”这一结构，不说明人就是一种模型。人会学习、会疲惫、会失去动机，也需要尊严和成长空间；模型目前通常不会因为完成一次任务就自动长本事。后面谈路由和治理时，这条边界会一再回来提醒我们：可以用同一个函数思考，不能用同一套办法对待。

三、先修流程，再修内容：工程师维护的是生成器

如果表现是系统函数，那么“失败”就不该被读成一个关于主体的判决，而应被读成一条等待定位的故障链。这一节要立的，是第二个核心动作。

先看一个软件里的场景。让 Agent 修复失败的 CI，它改完依赖文件，宣布问题已解决，CI 却还是红的。只看结果，它像一个能力不足的模型；展开执行轨迹，故事往往完全不同。系统也许只喂给它日志的最后二十行，真正的错误堆栈早被截掉；测试工具也许默认在错误目录里执行，返回一句 No tests found，退出码却是 0，于是它顺理成章地宣布“全部通过”；任务也许只写了“让 CI 变绿”，从没禁止删测试；验收器也许只看进程有没有正常退出，压根没数究竟跑了几个测试。把这些系统缺陷一一排除之后，我们才更有把握说“这次确实是模型没搞懂那段并发逻辑”。顺序不能颠倒，因为上游的缺陷会污染下游的判断——模型没拿到关键日志时，去研究它为何没推理出根因，只是在错误的实验条件下浪费时间。

所以排查也该有个顺序，而且这个顺序本身就是一种防止误判的机制：先问目标和验收是不是清楚，再问必要的事实在不在，然后检查工具、权限和运行环境，接着才看 Agent 自己的策略，最后才去比较不同模型在同一条件下的表现。这样排不是为了替模型开脱，而是因为把顺序倒过来，人几乎一定会在上游还漏着窟窿的时候，就急着给模型判“能力不行”。而支撑这套排查的，是执行轨迹：Agent 收到了什么、看见了什么、采取了什么动作、工具实际返回了什么、系统状态怎么变、最后凭什么宣布完成。要说清楚的是，这里的轨迹只指可观察的输入、工具调用、返回和状态变化，不是模型那段藏在内部、也无从验证的思维链。没有这些记录，一次失败只是一个红灯；有了记录，失败才从“它不行”变成一条能被定位、能被复用的故障链。

这里就出现了修复的两种层次。改依赖、删掉越权那句话、给高潮多加两句描写，是把一个坏结果 A 换成好结果 B，收益立刻兑现，但只作用于当前这一个样本。另一种修复，是去改变未来各类结果出现的概率——它不解决眼前这一章，而试图让一整类错误更难发生。两者都要做，但收益的时间尺度不同。把这个区分讲透，就是先修流程，再修内容这句话真正的含义：它不是“逢错就加规则”，而是先判断错误由哪一层产生，再让系统长出捕捉和纠正同类误差的能力，最后才用新流程重做当前内容。

有一类反复出现的错误，会提示同一件事：系统里缺少某个尚未被显式表达的状态或概念。要强调的是它只是其中一类——反复出错也可能来自模型能力不足、上下文陈旧、工具或权限有问题、评测本身失准，得先把这些排除掉，才好归到“缺状态”上。拿我自己写小说的流程当证据（注意，它只是证据，不是这篇文章的主线）。如果女主总是提前知道没人告诉过她的秘密，问题多半不在 Prompt 里少写了一句“注意信息边界”，而在系统根本没有表示“哪个人物、在哪个时间点、通过什么事件、知道了哪些信息”。一旦补上这张“人物 × 时间点 × 已知信息”的状态表，事情就从依赖模型临场记忆，变成了可读取、可更新、可验证的世界状态。

但状态表本身还不够，关键其实不是那张表，而是一条可检查的不变量：任何新增的知识都必须有来源。人物可以偷听、可以推理、可以被欺骗、可以被别人告知，获取信息的路径尽可以充满创意——这是要保留的有效空间；但“新知识必须能追溯到本章某个事件”这一条不能松动。这条不变量比规定人物每一步怎么走有力得多，前者守住了故事的自由，后者会把所有人物写成照章办事的职员。而且这张表必须真正嵌进创作链才有用：写章之前从唯一可信的状态里组装上下文，生成时让模型自由设计人物如何获知，生成后由检查器把正文里的“人物已知”和写作前的状态做差、要求每个新增知识都有出处，确认后才把新状态写回；如果之后还要做一次文学化重写，就得再检查这次润色有没有悄悄改动信息揭示的顺序。少了任何一环，状态表都会退化成一本被认真维护、却不参与任何决策的设定集。

还有一部分创作老毛病可以这么诊断——但同样要先排掉模型、上下文、工具和评测的原因，确认剩下的确实是“缺表示”，结论才成立。属于这一类时，诊断往往指向同一句话：系统里有个重要的区别，还没被显式表达出来。战力忽高忽低，可能缺的是角色能力状态和它的变化事件；伏笔埋下去又忘了收，可能缺的是一张“承诺—兑现”的关系表；时间线互相打架，可能缺的是一个统一的事件时钟。属于这一类的高价值 Bug，其实都在替系统指出一处该补的表示。这个视角之所以值钱，是因为它把“这个模型不太聪明”这类无处下手的抱怨，换成了“系统缺哪个状态”这类可以动手的工程问题。

这条链把“先修流程，再修内容”从一句态度变成了可以验证的改变：同一批历史错误还能不能被发现，新章节会不会复发，流程会不会因为检查过严而伤到正常创作。软件里也是同一套逻辑——反复重复扣款，可能是缺了“幂等键”这个概念；多端编辑互相覆盖，可能是缺了版本状态。继续叮嘱人“下次仔细点”，并没有把这个缺失的状态补进系统，下一次同样的条件还会复现同样的错误。

修流程还有一个比“多补一条规则”更微妙的层面，那组换壳实验里有个细节把它讲得极清楚。模型读取一个大文件时，只看了返回的第一页，就误以为已经到了结尾，于是漏掉后面的内容。直觉上的修法是把“这个文件可能还有下一页”写进 read_file 这个工具的描述里——结果几乎没用。真正奏效的做法，是把同一句提醒追加到当次工具返回的内容里，让它就出现在模型正要下判断的位置。同样一句话，写在工具说明里和写在本次结果里，效果天差地别。这说明 Context Engineering 不是“给模型更多信息”，而是让正确的信息在正确的时刻、以正确的形式，出现在模型当前决策的旁边。人的决策也会呈现相关模式：一条安全须知写进了入职培训，不代表操作员会在真正伸手去按那个开关的瞬间调用它。知识被写下来，和知识在决策那一刻被激活，是两件不同的事，中间隔着一个触发的时机——这既是调 Harness 的要害，也是设计组织流程的要害。

不过要立刻补一条边界，否则“修流程”会变成新的教条：不是每次不满意都值得改流程。偶发的措辞错误，直接改最经济；同类问题反复出现，才值得更新 Skill 或状态表示；验收长期发现不了问题，要改的是评测；如果流程本身让所有章节越来越像一台机器压出来的，反而要删掉或放宽约束。流程只是另一种代码，同样有 Bug，同样会累积技术债，越多绝不等于越好。

现在把镜头拉远，看看这套“修流程”的动作放进时间里是什么样子——它就是 Loop，是让系统自身发生变化的循环。这里有个容易被混淆的区分：经历不等于经验。做过十个失败项目、每次都归咎于运气，样本数确实涨了，但参数没更新。经验是数据经过反馈校正、归因和抽象之后，改变了系统下一次的预测与行动；如果下次遇到相似情况判断毫无变化，上一次留下的更像一个故事而非一条经验。而经验还必须经过恰到好处的压缩才好用。压得太少，它只能用于原题，换个场景就失效；压得太多，又会变成“做人要谨慎”“项目要多沟通”这类永远正确、因而什么也没说的口号。有用的经验总是带着边界条件的：它说的不是“这样会失败”，而是“在哪些条件下、哪一种假设特别容易失效”。这一点对人和对 Agent 系统完全一样——一条写进 Skill 却不标注适用范围的规则，和一句放之四海而皆准的空话，几乎一样不解决问题。所以有 Loop 不等于会学习：“失败—换个说法再试—再失败”也是循环，但它只是原地打转。真正的学习至少要走完几步：事前形成预测，行动后观察结果，把结果和预测比对，判断误差出在哪个假设，抽象出可迁移的规律，改一小步策略，再用新样本验证。

事前预测是这里的刻度。没有预测，任何结果发生后我们都能编出一套听起来合理的解释，成功归于执行力强，失败归于市场教育不足，同一套话对所有结局都适用，也就从现实里收不到任何误差信号。更好的做法是在动手前留下一个够明确的判断，比如“人物越权知情反复发生，是因为章节生成时没注入知识状态”，然后只加这一项、只改这一个变量，用历史错误和新章节分别测试。同时更换模型、重写 Prompt、增加上下文、又调评分，分数就算涨了，你也只知道“这一大包东西里可能有用的”，得不到多少可迁移的知识。控制变量不是实验室的洁癖，而是为了让反馈能回答一个具体问题。

这跟精益创业强调的“经过验证的学习”是同一件事。Build—Measure—Learn 从来不是鼓励大家不停做东西，而是要求每一次构建都对着一个待验证的假设，每一次测量都能改变我们对这个假设的信心，每一次学习都真的进入下一轮行动。否则 Build 和 Measure 都在运转，Learn 却没有真正改变下一轮的假设和行动。Agent 系统的中层循环最容易掉进这个陷阱：团队勤奋地改 Prompt、加工具、跑评测，指标也确实在动，但没人说得清到底是哪一步起了作用，于是下个季度只能继续勤奋地瞎改。忙碌很容易，可验证的学习才稀缺。

为了把这件事讲清楚，我把成熟系统里的循环拆成三层——需要说明，这只是本文用来分析的框架，不是某种标准分类。最内层是任务执行 Loop，只问“这件事做完没有”，它关心当前样本。中间层是系统改进 Loop，问“这类任务为什么总在同一处栽”，团队收集多次轨迹、归类失败、改 Skill 或状态或评测、再跑回归，它关心未来一批样本的成功概率。最外层是产品探索 Loop，问“我们是不是在可靠地做一件没价值的事”，它要求把真实世界的选择、成本和反馈带回来，检查目标本身值不值得追。三层缺一不可：只有任务层，这次靠重试过关下次照样从头犯错；只有系统层，团队可能把一套没人需要的流程打磨得极顺滑；只有产品层，没有稳定执行和内部诊断，反馈里混进太多变量，最后只剩“读者口味难测”这一条万能结论。

写爽文很适合把这三层分开演示。内层循环写一章，检查人物一致性和节奏，改到达标为止。中层循环回看十几章的共同毛病，比如反转总显得没力气，进一步发现问题不在句子不够狠，而在前面的压制不够、代价太轻、兑现太快，于是去改章节的设计流程。外层循环则要看读者是不是还在追，在哪一章弃书，他们真正期待的承诺到底是什么。三层依赖的证据也不一样：任务层靠测试、Diff 和当前状态，系统层靠一批案例的失败分布和回归结果，产品层靠真实的选择、留存、付费和访谈。拿任务层的“所有检查都通过”去证明产品有价值，或拿一个读者的喜欢去证明流程稳定，都是把不同尺度的证据混成一锅。Loop 不光要转，还得始终清楚自己这一圈到底在回答哪个问题。

而这也是官方技术教程反复强调的纪律——NVIDIA 的教程把改进过程写成一个朴素的循环：跑评测、观察失败、提最小修改、重复验证、保留或回滚、再跑完整测试，并特别提醒单次通过没有证明力，因为模型调用和部分评测本身带随机性，修复必须连续通过、且不能破坏其他任务。

还要防一种更隐蔽的失败：反馈本身是错的。经历很多却长不出经验，除了因为没复盘，还可能因为喂进来的信号本就有偏。只接触成功者，会把幸存者偏差越练越熟；只盯着点赞，会把迎合误当成价值；小说若只检查每章有没有反转，系统就会学着机械地制造反转，而不是经营人物、期待和后果。错误反馈会让系统稳定优化错误目标。所以一个健康的 Loop，每转一圈都该在系统里留下某种可检查的变化：一个新的状态字段，一条被验证过的 Skill，一个失败回归案例，一项更准的评测，或者一条被证伪后删掉的规则。变化不必大，但必须能影响下一次行动，并接受下一次现实的检验。

于是第二个思维模型可以收束了：工程师维护的不是某一次输出，而是那台不断更新的生成器。修内容只改当前这一个样本，修流程改变的是未来同类结果出现的概率，而把旧错误加进回归集，是为了持续验证这次改动真的降低了复发率，而不是只在当下看起来奏效。一个人或一个系统真正的成长速度，不等于它经历事情的速度，而等于它把现实误差转化成下一版自己的速度。

四、给不同成本的智能派活：授权由风险决定，不由价格决定

到这里，模型、Harness 和 Loop 都齐了。接下来的问题很现实：真实系统里往往不止一颗模型，有贵的也有便宜的，还有随时能叫来的人。怎么给它们派活？

先纠正一个关于成本的常见误解。模型变便宜，最容易被当成采购新闻——同一件事原来花四十几美元、现在花四美元多，财务松口气就完了。但对 Agent 系统来说，成本下降更重要的后果不是把原流程便宜地再跑一遍，而是让原本舍不得做的实验变得做得起。Agent 完成一次任务，通常不是模型答一次就结束，它要理解目标、调用工具、观察结果、修正计划，还要接受评测，有时再生成多个候选或引入一个审查模型。团队若拿几十个真实任务去比较多套 Harness，一轮回归很快就是数百次完整运行。成本高时只能挑几个“有代表性”的例子;成本降下来，失败案例、边界案例和普通案例才有机会一起进入持续回归，而不是靠感觉宣布“这版稳多了”。

所以低成本首先买到的是观察：样本多了，才分得清一次成功是稳定能力还是好运，一项改动是提升了整体还是只讨好了手边那个案例。其次买到的是比较：同一个任务可以换模型、换上下文组织、换工具契约、换停止策略地测。最后才轮到部署规模。要是连系统为什么成功都没搞清就先扩大调用量，得到的只是规模更大的不可解释现象。这恰好和上一节的 Loop 接上——更低的边际成本缩短了“提假设—跑实验—看误差—更新系统”的周期，让团队学得更快，而不只是更便宜地产出答案。反过来说，没有可信的评测、清楚的归因和可复现的样本，便宜模型只会让系统更快地生产噪声：把生成次数翻十倍，不会自动带来十倍经验。真正该算的，从来不是单次调用价格，而是单位成功任务的总成本——它包含推理费、工具与运行环境、自动评测、人工审核、重试、失败恢复，以及错误进入现实后可能造成的损失。假设有一个模型每次只花几美元、成功率却只有三成、还得人反复返工收拾，它未必比另一个每次花十几美元、九成任务一次就过的模型更便宜——这里的数字只是设想，用来说明总成本怎么算，不要和前面那组 4.48 美元、43.48 美元的真实数据混在一起。单次调用的价格只反映模型自己收了多少，并不包含人为它返工、复核所花的时间。这就是为什么开头那组 4.48 美元对 43.48 美元的数字，既值得重视又不能照单全收：它在特定评测里是真的省，但省下来的这笔钱究竟变成了利润还是变成了下游的返工，取决于系统有没有能力把便宜的调用变成可靠的交付。

想清楚了成本的真实含义，第三个思维模型才好立：不同成本的智能，应该被放在任务生命周期的不同阶段。任务刚出现时，团队往往连问题本身都没表示清楚——需要哪些输入、哪些异常最常见、工具怎么组合、什么才算好，全是未知。此时 Harness 很薄，判断只能在运行时临场做，更强也更贵的模型适合用来探索上限：生成几条可能路径，处理罕见例外，暴露我们没想到的状态，和人一起搭起最初的验收标准。但昂贵智能若每次都从头解决同一种问题，组织其实没在积累什么，只是在为每一次调用单独付一次费。更值钱的做法，是让每次高成本调用都留下东西：一条验证过的成功轨迹，一个新的失败类别，一项工具改进，一条边界规则，一组评测，或一段人工修改记录。等任务反复出现、边界逐渐清楚，这些知识就能固化进 Skill、状态结构、工具和升级机制，交给便宜模型执行。这相当于把运行期的昂贵推理，前移到设计期：强模型负责把未知变成已知，便宜模型负责把已知规模化，二者不是身份高低，而是分工。

落到操作上，一个合理的路由是一条阶梯，可以画成一张小表：

这张表真正复利的地方，不是便宜模型越来越像强模型，而是系统把罕见判断一点点变成了可重复执行的普通能力——每次昂贵调用都尽量留下可复用资产，下一次同类任务就不必再交一遍“未知税”。这张表里最难写好的其实是升级的判据，也就是“什么时候该停下来交给上一档”。停得太早，便宜模型明明能搞定却总在打扰人；停得太晚，它会在错误的方向上反复尝试，把成本烧在无效重试上，而且模型嘴上的确定程度往往和它是否真的接近正确无关。好的停止判据不看模型嘴上有多确定，而看客观信号：评测反复不过、同一种修复连试几次都不奏效、或者接下来的动作已经逼近某条不可逆的边界。把“何时停止”当成一等公民来设计，路由才不会退化成“先让便宜的瞎试，试烦了再叫人”。

这套分工在我自己的小说流程里非常具体，也顺便说明了“路由”不是空谈。按我目前的体验，Cursor 里的 Opus 更贵，但文字通常更文从字顺；Codex 更适合长流程里的文件操作、状态维护、结构分析、连续性检查和反复迭代。与其争谁“总体更强”，不如问某个环节到底稀缺什么。人物状态、时间线、伏笔和失败回归，靠的是结构化记录、工具调用和持续维护，价值来自可靠、完整、可追踪，这部分流程型工作交给 Codex；等情节结构、人物动机和信息揭示顺序稳定了，再把开头、核心转折、情绪爆发和终稿交给 Opus 做文学化重写。这样还能躲开一种常见浪费——用漂亮流畅的文字，把结构错误包装得更难被发现。两者之间需要一份语义合同：核心事件、人物动机、事实、伏笔和信息顺序是不变量，句式、段落、描写密度和节奏可以自由调整；重写完再由 Codex 对照前后版本，查有没有新增事实、删掉关键动作、改动人物知识边界。最后仍由人判断它是不是更好，而不只是更顺——生成越便宜，稀缺的东西越会转向选择：什么值得留，什么只是漂亮，什么符合局部评分却损害整部作品。生成成本下降后，评估与选择成为新的瓶颈。

这一步还能顺手兑现前面说过的“昂贵调用要留下资产”。如果某次 Opus 重写确实更好，还可以让 Codex 反过来分析它到底改了什么：主要是拉长了句子、加密了动作、拉近还是推远了叙事视角，还是重排了情绪的递进？哪些改动可能迁移到别的章节，哪些只适合这一章的情境？只有经过后续章节反复验证仍然成立的规律，才值得考虑写进写作 Skill。这样一次昂贵的润色，买到的就不只是一份终稿，还可能包括创作流程未来的一点点升级——把运行期的一次灵光，尝试转成设计期的一条可复用经验。这正是路由的复利所在：不是便宜模型越来越像贵模型，而是每一次贵的调用都在替便宜的那一层扩边界。

现在必须给这个类比划一条清楚的边界，也就是这一节最重要的原理：授权由风险决定，不由价格决定。昂贵智能和便宜智能的分工，确实很像组织里资深专家与普通员工的分层——规则明确、低风险、高频的任务交给标准流程或经验较少的人，规则冲突、影响巨大、从未见过的异常交给资深专家，专家解决后再把方法沉淀成工具、培训和升级条件。顺着这个类比还能纠正一个常见的绩效错觉：一个高级工程师最有价值的产出，往往不是他自己多修了十个 Bug，而是他让另外十个人以后不再犯同一类错。前者是把昂贵智能花在了运行期，后者是把它前移到了设计期。一个只顾自己救火、从不留下工具和文档的资深专家，和一个每次都从头解决同一问题的昂贵模型，其实是同一种浪费。但这个类比在两处会失效。其一，工资不是智商检测报告，高薪还包含市场稀缺、地区、权力和历史偶然，别拿调用价格给人排能力。其二，也是更关键的一处：模型可以在隐私、数据驻留、许可、兼容性和合规边界内，按成本与能力程序化路由；人则还涉及学习、疲惫、动机、尊严和成长；若永远只让新人处理已经完全确定的任务，组织省下了今天的专家工时，同时取消了明天专家的培养过程。所以人的分工不能只优化眼前成本，还得设计一条渐进式授权的路径：先在明确边界内执行，再在监督下接触例外，观察资深者怎么判断，逐步承担更大的责任，最后参与设计流程本身。模型今天通常不会因为完成一次任务就自动长本事，人却会——只按调用价格把人分派到固定档位的活里，不只是让人不适，长期看在经济上也未必划算。回到模型这边，正因为它没有这些成长和尊严上的顾虑，它的自动执行可以更多地由风险来裁决。所以模型该不该自动执行，判据不是它贵不贵、也不是它说话多有把握，而是几件事叠在一起——这个动作可不可逆，错误容不容易被发现，最坏影响能波及多大范围，还有它触碰的数据有多敏感、用的是谁的身份和授权、要不要满足特定合规要求。生成一个章节草稿可逆、可丢弃，尽可放手；修改生产数据库不可逆、影响大，又往往牵涉敏感数据和高权限授权，就必须走严得多的路径。这条边界会直接把我们带到下一节：Agent 最会让人放松警惕的，恰恰是它会说话。

五、可以像同事一样交谈，但必须像软件一样治理

Agent 最容易骗过我们的地方，不是它能调用终端，而是它会解释、会道歉、会说“我已经全面检查过了”。语言让协作变顺滑，也让我们下意识地把理解、意图和责任感一并投射过去。它的承诺功能看起来相当完善，可承担责任的主体并没有随之生成。所以“别把 Agent 当同事”这句话，重点不是要求人用生硬的命令，也不是否认自然语言协作的价值，而是提醒一件事：交互界面可以拟人化，治理结构不能拟人化。Agent 说“已完成”，只是系统生成的一句状态声明，不是任务完成的外部事实。

这也是为什么“数字员工”这个流行说法值得警惕。它把一个进程悄悄升格成了一个人格，于是我们下意识地给它配上了忠诚、分寸和羞耻心——出了错它会道歉，我们就觉得它下次会长记性。但道歉是它学过的一种语言模式，不是一份可以追责的承诺。把 Agent 想成“更聪明的自动化”会低估它，因为它确实会临场判断、会行动、会一本正经地犯错；把它想成“数字同事”又会高估它，因为它没有承担后果的能力，也没有可以被问责的主体。更贴切的定位是：它是一个能力时强时弱、会用自然语言交流、但必须被外部证据约束的进程。摆正这个定位，后面所有关于授权和证据的设计才不会被它的表达能力带偏。

要治理，先得把被自然语言揉成一团的三个问题拆开：它有没有能力做，系统允不允许它做，我们凭什么相信它已经做对。能力、授权和证据是三件不同的事。Agent 越自信，人越容易觉得它“应该懂分寸”；但智能不是授权，自信更不是证据。一个模型能写出删库命令，只说明它学过语法，不说明公司应该把生产密钥交到它手上。一个代码 Agent 声称测试全过，能算数的证据是它实际执行了哪些命令、跑了多少测试、退出状态如何、Diff 改了什么、原问题还能不能复现——它的解释可以帮人理解，但不能替代验证。换个场景更直观：一个处理退款的客服 Agent，能不能算出该退多少，是能力问题；系统允不允许它真的把钱打出去，是授权问题；它凭什么让人相信钱进了正确的账户、金额没错、没有重复打款，是证据问题。这三件事经常被一句“它说它处理好了”糊在一起，而糊在一起的代价，往往要等对账时才由人来偿还。

承接上一节那条“授权由风险决定”的判据，自主性因此不是一个从零到一的开关，而是一条随风险滑动的连续谱。可以把它整理成一组维度：

1
2
3

可逆性 × 可发现性 × 影响半径 × 数据敏感性 × 所用身份与授权 × 合规要求  →  允许的自主程度
可逆、易发现、影响小、数据不敏感、授权充分、无特殊合规          →  接近全自动
不可逆、难发现、影响大、数据敏感、授权不清、合规敏感            →  提案 + 人工批准 + 事后核验

生成草稿错误易发现、随时可弃，可以高度自主；改正式稿只要留着版本和 Diff，风险仍有限；创建代码分支通常可逆，直接合并主干就得测试加审批;起草客户邮件可以自动做，真实发送会影响外部关系，应加确认；分析生产日志可以只读放开，改动生产数据库必须走严格授权。对高风险流程，值得把“提出方案”和“执行动作”分开：Agent 先列计划和将要调用的工具，系统跑一遍 Dry Run，策略或人批准，运行时只为当前任务注入最小、短期的权限，执行后由外部检查确认结果，再回收凭证、留下日志。这里的权限更像临时门禁，按任务发放、按任务回收，而不是因为某个数字助手看起来靠谱，就把总钥匙长期挂在它身上。

但治理也有它自己的失效方式，这条边界同样要讲清：如果所有动作都要人点一下同意，自动化的价值会被消耗殆尽，而且未必换来安全。当每个动作都要审批，人很快会陷入审批疲劳，对一长串请求习惯性地一路点“同意”，真正危险的那一个反而更容易被放过；全审批因此常常只是把风险从“没人看”换成“看了也看不过来”，并不等于必然安全。治理的目标从来不是让 Agent 什么都不能做，而是让它的自主权和可逆性、可观察性、影响半径对齐——让低风险动作顺畅通过，让风险在跨越边界之前变得可见。

外部证据本身也需要被治理，因为“相信测试，不相信自述”这句话还不够。测试会漏，评测会错，日志也可能只记录系统愿意记录的部分。形式上完成了验证，不代表真正要紧的条件被检查了。所以证据链要分层次：工具返回的退出码是一层，测试的数量和覆盖范围是一层，原问题修复前后的复现是一层，生产或读者的真实反馈又是一层。不同层回答不同问题，单元测试通过证明不了产品有价值，读者说这章好看也证明不了时间线没矛盾。把一项局部证据提升成总体结论，是人和 Agent 都很擅长的捷径。证据还应可追溯：谁以什么身份调了什么工具，输入输出是什么，哪些检查因为权限或上下文不足而没做完——留日志不是为了事后找个人来承担情绪，而是为了重建系统究竟发生了什么。这里要抵住一种诱惑：不要因为 Agent 能讲出一段听起来很合理的“我当时是这么想的”，就把它当成诊断依据。那段自述再流畅，也只是又一次生成，不是证据。对工程诊断真正有用的，永远是可观察的输入、动作、工具返回和状态变化——它们不会为了让复盘好看而临时润色自己。把“它怎么解释”和“它到底做了什么”分开，是治理层最基本、也最容易被话术绕过的一道纪律。

最终责任必须留在人类和组织里。参与任务分配、授权、验收和上线的相关决策者与组织，仍须按各自的角色、具体场景和适用法律承担相应责任；Agent 可以承担越来越多的行动，却不会因此自动继承这些责任。所以我愿意用一种听上去有点分裂、其实和我们对待人类制度完全一致的态度来收这一节：在交互层把 Agent 当协作者，在流程层把它当可组合的能力，在权限层把它当不可信的进程，在验收层只相信外部证据。自然语言降低沟通成本，授权与验收仍以规则和外部证据为准。

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

把前面几个模型叠起来，就能回答一个更大的问题：当越来越多的工作交给 Agent，一家公司到底在积累什么？

有一个流传很广的判断值得拿出来解释——未来的公司会越来越多地建立在某种 framework 之上。我不打算把它当成谁的逐字原话，而把它当成一个需要拆解的命题。其实公司本来就是一套为人设计的 Harness：岗位规定谁负责什么，SOP 提供常见方法，信息系统保存状态，审批拦住高风险动作，培训传递经验，审计和复盘提供反馈。同一个人进不同公司表现差很多，未必是认知能力突然变了，而是他能看见的信息、能调用的工具、被允许的行动和拿到的反馈都变了。这正是第二节那个系统函数在组织尺度上的回声。

Agent 时代的新意，在于这些组织条件将有更多部分变成机器可读、可执行的结构：业务词汇不只写进培训手册，还要进数据模型；权限不只是口头叮嘱“重要操作谨慎点”，还要变成运行时策略；经验不只留在资深员工的直觉里，还要变成 Skill、工具、失败案例和评测；完成不只由执行者口头汇报，还要有可验证的状态。基础模型会继续变，今天昂贵的能力明天可能沦为普通服务；企业真正能长期沉淀的，未必是哪个模型名字，而是自己对业务的那套表示——有哪些对象和状态，任务怎么拆，哪些工具可信，哪些例外必须升级，什么证据才算完成，错误怎么回滚，谁负最后的责任。这套东西合起来，我称之为制度化智能：它是某次判断离开当事人脑袋之后，仍然能改善后来者行动的那部分能力。一家公司真正的 Agent 资产不是 Prompt 文件的数量——Prompt 好复制，写得长也不自动值钱——更难复制的，是工具与真实业务系统的连接、持续更新的状态、被真实失败校正过的评测集、权限与审计机制，以及把反馈变成下一版系统的速度。

设想两家公司。第一家攒了成百上千条 Prompt，写得又长又漂亮，但工具和真实业务系统半连不连，状态表几个月没更新，评测集全靠拍脑袋。第二家 Prompt 不多，却把关键业务对象和状态都表示进了系统，工具真正接上了后端，评测集是被一次次真实事故喂大的，权限和审计一环扣一环。把同一颗新模型接进这两家，第二家几乎立刻就能让它可靠地干活，第一家则会发现那堆漂亮 Prompt 在真实环境里频频落空。这说明真正的资产从来不是描述智能的文字，而是约束和喂养智能的那套结构——它决定了一次模型升级到底是坐享其成，还是从头再来。

这种沉淀通常要走完几次转换才真正生效，而每一次转换都可能卡住。专家脑子里的直觉，先得被说成一个可以讨论的区别；这个区别再被表示成状态、工具契约或权限边界；一次具体事故被改写成一个可重复运行的评测；一次罕见例外被固化成一条清楚的升级条件。只写进会议纪要，后来者可能看过却不会在关键时刻调用它——这又是那个触发时机的问题；只写成代码而不解释适用边界，系统又容易把一个偶然管用的方案当成永恒真理。真正的组织学习，是当原来那位专家不在场时，后来的人和 Agent 仍然因为这些结构做出了更好的行动。所以最有复利的动作，始终是把罕见问题的解决方案沉淀下来：低成本层撞到边界，升级给强模型或人；问题解决后，新的状态、工具或评测被加进系统；下一次同类任务，就不必再交一遍那笔未知税。

不过，把知识沉淀进 Harness 并不天然是好事，这是全篇必须补上的最后一条边界：Harness 也会衰老，也会积累技术债。错误知识照样能沉淀，过时规则尤其擅长沉淀。每次失败都往 Prompt 里加一句提醒，几个月后就会得到一份篇幅可观、内部互相打架、谁也不敢删的制度文件。它的技术债有几种常见形态：一是规则堆积，每个局部事故都变成永久约束，最后彼此矛盾；二是状态过时，人物表、业务数据和权限描述没同步更新，系统非常可靠地依据旧事实行动；三是评测固化，评分器只查旧问题，Agent 学会了刷高分却绕开真实目标；四是工具契约漂移，接口早改了、说明还停在上个版本；五是补偿性复杂度，当初为了兜住旧模型的缺陷加了一堆中间件，模型升级后这些层已经不再必要，却因为没人敢确认能否安全移除而一直留着。

因此，Harness 不只需要评测任务，还需要元评测，也就是定期评估 Harness 自己：它真的降低了同类错误率吗，在新样本上还能不能泛化，是不是增加了过多的人工审核和执行时间，规则之间有没有冲突，评测的高分和真实用户结果是否还相关，系统是不是为了追求一致性而失去了处理例外的能力，删掉某条规则结果会变坏还是反而更好。最后这一问尤其反直觉却尤其有用：很多约束是为了兜住某一代模型的短板才加的，模型一升级，这条约束就从防线变成了枷锁，可它通常还会因为“当年就是这么定的”而留在系统里，没人敢担删除的责任。定期挑几条最老的规则做删除实验，往往比再加十条新规则更能让系统变轻。元评测尤其要盯住一种隐蔽的成功：内部指标越来越漂亮，现实效果却没改善。小说流程可以做到人物知识零泄漏、每章都有反转、伏笔全部登记，成品仍然不好看；软件 Agent 可以让测试全绿，用户的问题依旧没解决。指标是目标的代理，不是目标本身；Harness 若没有外层反馈，就可能把代理指标越优化越高，同时离真实目标越来越远。所以维护 Harness 既要增也要删——新增之前先问它解决的是偶然还是一类问题，规则长期不触发就要判断它是有效防线还是已经多余，模型和工具升级后要重新测量旧约束是否还有价值。一个只进不出的系统，不叫长期记忆。

元评测里最难堪、也最有价值的一种发现，是评测本身已经过时。评测集是某一时刻对“什么算做对”的快照，可现实中的目标会漂移：业务口径改了，用户真正在意的东西变了，甚至上一次修复顺手把判定标准写窄了。举一个假设的例子：设想一个客服退款 Agent 的评测最初只校验“退款金额算得对不对”，于是它在这套评测上一直稳稳拿高分；但用户真正在意的点，可能早已从“算得准”转移到“退款到账要等多久”，而评测从头到尾没测过时延这一维。分数漂亮，只是因为它还在考一张过期的卷子。这类问题的要害在于，你没法靠往评测里不断追加断言来根治——每加一条规则，只是把这张旧卷子改得更厚更细，却依旧默认原来那套维度天然成立。真正的解法，是让元评测定期拿评测的判定去对照真实世界的结果：当高分和线上反馈持续背离时，第一个该被怀疑、被重写甚至被整段推翻的，是评测本身，而不是再给 Agent 补一条新约束。

这也是为什么“公司越来越建立在 framework 之上”不该被读成“公司最后会变成一摞 Prompt”。Harness 擅长的是把已知方法变得稳定、把经验放大，它替代不了几件事：目标该往哪里选，什么价值值得追，信任关系怎么建立，责任最终由谁承担，以及那些无法被完全形式化的审美判断。更麻烦的是，Harness 放大经验的同时也放大偏见——它对好方法和坏方法一视同仁地忠诚。所以到底把哪一部分固化进系统、哪一部分留给人的临场判断，本身就是一项没有终点的管理工作，而不是一次可以外包给模型的设置。这恰好是那个系统函数在最高一层的样子：一家公司的表现，同样是它的模型、它的流程、它的工具、它的反馈和它的目标共同的输出，而最弱的一环照旧决定交付。

回到最初那个换壳就改分数的谜题，现在可以给出一张完整的认知地图。把这篇文章谈过的东西放回同一个生产系统，其实是三个模型加两个外部边界。三个模型是——可能性空间决定能尝试什么，更新生成器决定系统能否随时间变好，生命周期路由决定每一步该由谁来做；两个外部边界是治理和人：治理为这三者划出风险与责任的边界，人为它们选择目标。模型能力只是可能性空间里重要的一层，Harness 决定这层能力能不能在真实环境里被反复够到；更新生成器决定整个系统会不会停在第一版的偏见里；生命周期路由决定昂贵与便宜的智能各自站在任务的哪个阶段。这几者缺一都会露馅：只有强模型而没有塑造好的空间，能力会变成事故；有空间却不更新，系统会停在旧偏见里；有一切却没有治理，自信会被误读成证据；而如果没有人来选目标，一台高度可靠的机器也可以稳定地做一件毫无意义的事。

于是最开头那个转移也就有了它的落点。许多规则驱动的任务过去主要靠工程师预写控制流，把含糊的需求压缩成确定的路径（这并不代表所有传统自动化都如此）；今天设计 Harness，是在不写死全部路径的前提下，用状态、工具、权限、反馈和评测，把开放的智能收敛到可交付的结果上。写控制流的人回答“系统该走哪一步”，塑造结果分布的人回答“系统大概率会落在哪一片结果里，以及怎么把灾难挪出这片结果”。前者要求你穷举，后者要求你塑造。方法变了，责任没变，甚至更重了——因为你不再为某一次具体的运行负责，而是为一整片可能性的形状负责。真正值得一家公司长期经营的，从来不是某一次惊艳的输出，也不是一份越写越长的规则清单，而是一个能在开放世界里持续学习、持续收敛、并且始终有人对结果负责的系统。这大概就是“公司越来越依赖 Harness”这句话最不神秘、也最严肃的那层含义。

当经验还说不清时：Skill 与可执行的师徒制

我一开始把 Skill 理解成“打包好的提示词”。官方文档也把它描述为一组指令、资料和可选脚本，用来让 AI 更可靠地完成一类工作流。

但有一个更准确的比喻：Skill 像在教新人。提示词是在告诉 AI 这一次做什么；教新人是在帮助一个本来就很聪明的人，学会在这里怎样做事。

新人缺的不是技术

假设团队来了一位新工程师。他会 Java，会 Git，也知道怎样登录服务器。你让他部署一个服务，他很快就能找到部署脚本。

但他不知道今晚为什么不适合发布。他没有注意到这次改动包含数据库迁移，也不知道回滚脚本还没验证，更不知道当天值班的人第一次接触这个系统。监控里还有一条经常误报的告警，老员工看一眼就会忽略，新人却可能被它带到错误的方向。

这些知识很少完整地出现在部署文档里。它们散落在事故复盘、聊天记录和老员工的习惯中。老员工自己也未必说得清，只是看到几个信号同时出现，就觉得“这次最好先别发”。

真正难以传递的不是步骤，而是专家的目光。

教新人时，我们表面上在教命令，实际上在教他注意什么：什么是普通噪音，什么是风险信号，哪些条件可以单独放过，哪些条件同时出现就必须停下来。

过去只有规则才能进入软件

传统软件不擅长接收这种知识。它希望人先把经验写成明确条件：如果存在数据库迁移并且回滚未验证，就禁止部署；如果监控异常但属于已知误报，就继续执行。

问题是，专家判断往往由许多微弱信号共同形成。每个信号单独看都不足以阻止部署，它们的组合却让人不安。想把所有组合写成规则，最后通常会得到一棵没人敢修改的决策树。更常见的结果是，人们只写下主流程，把真正决定成败的例外继续留在脑子里。

过去，知识要进入软件，必须先缴纳一笔“形式化税”：只有被完整说清的部分，机器才能执行。

LLM 让案例开始具有执行力

LLM 改变的不是专家突然更会写文档了，而是软件接收知识的门槛变了。

我们可以给模型看几次安全发布、几次失败发布，以及专家当时的评论。也可以让它读取本次变更、值班安排和监控状态，再说明自己看到了哪些风险。如果它判断错误，专家不必先发明一套完整理论，只需要指出：“你忽略了数据库迁移和回滚状态同时出现的意义。”

下一次，这条纠正就可以成为新的案例、提示或检查条件。

经验不必先被压缩成完整规则，也可以先进入行动，再在行动结果中接受检验。这创造了一种介于人类直觉和确定性程序之间的东西：半显式、但可执行的知识。文档等待人来理解；Skill 会在具体情境中调取知识、使用工具并产生行动。

不透明性可能只是换了地方

假设模型看过很多发布案例，已经能像资深工程师一样判断“今晚不应该部署”。这是否说明隐性知识已经显性化了？未必。

模型可能做出了正确判断，却无法准确说明真正起作用的依据。它给出的解释甚至可能只是一个听起来合理的事后故事。原来我们面对的是“师傅说不清为什么”，现在可能变成“模型也说不清为什么”。隐性知识没有消失，只是从人的直觉转移到了模型的模式判断中。

可复现的判断，不等于可解释的知识；能给出解释，也不等于组织已经理解了原因。

因此，成熟的 Skill 不能只追求“像专家一样回答”。确定性的安全边界仍要写成规则和测试；模糊判断要展示依据与不确定性；高风险、不可逆的动作必须保留人工确认。

一场可以重复的师徒制

师傅带新人，靠的不是一本手册，而是示范、行动、反馈和纠正。Skill 也需要案例、工具、验收标准、失败后的处理方式，以及遇到未知情况时的升级边界。缺少这些，它只是培训材料；拥有这些，它才开始成为组织能力。

LLM 让经验在被压扁成僵硬规则之前，就能进入软件，被调用、检验和修正。Skill 不是把师傅的答案装进文件，而是把示范、行动、反馈与纠错变成一套可重复运行的系统。

参考：Codex Skills 官方文档

冰山冻结了爱情，互联网开始结算

法官换了，法庭还在

同一部《泰坦尼克号》，近三十年前是一场爱情战胜金钱和阶级的神话，今天却经常被讲成另一种故事：卡尔成了被辜负的“老实人”，杰克成了“黄毛”，露丝则从觉醒的女性变成了精于利己的背叛者。

看起来，观众终于学会了复杂思考。可仔细看会发现，判决虽然翻了，法庭并没有消失。过去的法庭只承认爱情，现在的法庭只承认婚约；过去把露丝的自我解放当成免罪金牌，现在又把卡尔的物质付出当成所有权证书。双方都热衷于找出一个无罪的人和一个全责的人，只是交换了座位。

真正发生变化的，不一定是我们终于看懂了电影，而是衡量爱情的尺度变了。过去最容易打动人的是“一个人有权挣脱别人替她安排的人生”，今天最容易引发共鸣的则是“一个人付出了资源，为什么还会遭到背叛”。爱情从解放的语言，进入了结算的语言。

这并不是说新的疑问没有价值。露丝没有先清楚、体面地结束婚约，就与杰克接吻；她把裸体画像和挑衅性的纸条留给卡尔，也确实制造了羞辱。一个人受过压迫，不等于她做的每件事都自动正当；一个人在追求自由时，也可能伤害别人。

但两种伤害的性质、权力背景和后果并不对称。即使承认卡尔可能真心爱过露丝，他的受伤也不能把控制、掌掴、构陷和持枪追杀变成爱情的正常反应。金钱可以构成照顾，可以构成承诺，却不能自动兑换成另一个人的服从。

复杂不是各打五十大板。复杂是露丝既有权离开，也可能以伤人的方式离开；卡尔既可能感到真实的痛苦，也可能把爱理解成占有。这些事实可以同时成立，却不能彼此抵销。

他们不是两个候选人，而是两种人生

互联网很喜欢问：“如果没有沉船，露丝到底该选杰克还是卡尔？”这个问题听起来实际，却把电影降格成了一档条件悬殊的相亲节目。

杰克和卡尔首先不是两位丈夫候选人，而是两种人生的象征。

卡尔代表的是露丝已经提前看见的未来：宴会、马球、社交礼仪、昂贵珠宝，以及在富裕生活中逐渐失去决定自己身体和时间的权利。她在认识杰克以前就试图自杀，说明她的绝望并不是见到另一个英俊男人以后临时产生的。她真正想逃离的，不只是卡尔这个人，而是一份别人替她写好、只等她签字的人生。

杰克则代表一种尚未被写完的未来。他没有稳定收入，没有社会地位，甚至没有明确计划。但他让露丝第一次意识到，人生也可以由尚未发生的事情组成：骑马、旅行、做演员，甚至只是以自己喜欢的姿势坐着、吃饭和呼吸。露丝选择的并不只是一个穷男人，而是一个尚未成形的自己。

《包法利夫人》里的爱玛也不断把男人当成通向另一种人生的门。夏尔所代表的外省婚姻生活日复一日；爱玛则把巴黎、舞会、激情和爱情小说里的命运投射到罗多尔夫与莱昂身上。他们未必真是那个“别处”，却被她当成了抵达别处的交通工具。

《安娜·卡列尼娜》里的两位男性也不能被压缩成一善一恶。卡列宁的秩序里既有冷漠，也有责任、痛苦和宽恕；渥伦斯基的激情里既有生命感，也有行动自由的不对称。安娜面对的不是一道择优题，而是两种都带着代价的生活。

这里也藏着主体性的阴影。当一个男人被当成逃生门，他就可能不再被当成完整的人。一个人争取成为自己时，也可能把别人压缩成自己叙事里的道具。离开不公正的关系仍会制造真实痛苦；这种痛苦应当被看见，却不能反过来证明那段关系原本正当。

冰山保护了爱情

《泰坦尼克号》与福楼拜、托尔斯泰这两部小说最重要的叙事差别，不在于一边浪漫、一边悲观，而在于它们让爱情活了多久。

杰克死在爱情最炽烈的时刻。他永远不必面对收入、家务、阶级习惯、孩子、嫉妒和激情消退。露丝也永远不必发现，那个教她吐口水、站在船头张开双臂的年轻人，能否在十年以后与她共同处理一地鸡毛。

冰山不仅沉没了船，也替爱情免除了日常生活的考试。杰克不是被证明为完美丈夫，而是因为没有机会成为丈夫，所以永远不会暴露丈夫的缺点。死亡是最彻底的剪辑师，它删掉了所有可能使爱情变质的段落，只留下相遇、拯救和牺牲。

福楼拜和托尔斯泰没有给爱情这种优待。他们不让它在高潮处结束，而是逼它继续活下去。

爱玛的幽会逐渐变成重复、谎言和债务。她对爱情的追求与购买衣服、家具和奢华生活的欲望纠缠在一起。情人让她暂时觉得自己终于活进了小说，商人勒乐则把这种幻想变成信贷，再把信贷变成无法逃脱的现实。爱情没有战胜金钱，它经由消费变成了债务。

安娜与渥伦斯基真正生活在一起以后，激情也不得不接受时间的检验。社会排斥、与儿子的分离、两人行动自由的不对称，以及越来越强烈的嫉妒，使爱情从出口逐渐变成了新的封闭空间。逃离旧制度，并不会自动创造一个没有权力问题的新世界。

在这三部作品里，《泰坦尼克号》让爱情死得足够年轻，因此它可以保持纯洁；福楼拜和托尔斯泰让爱情活得足够久，直到它显露自己的影子。浪漫叙事总是偏爱改变命运的瞬间，低估维持生活的漫长时间。

因此，怀疑杰克与露丝能否相守几十年并没有错。可是“这段关系未经生活检验”与“露丝应该留在卡尔身边”仍是两回事。杰克未必适合婚姻，不等于卡尔因此取得了拥有她的资格。

越界发生在镜头里，压迫存在于空气中

为什么今天的角色反转如此容易传播？一个原因是，事件性的伤害适合截图，结构性的伤害却很难剪成十五秒视频。

露丝与杰克接吻，是一个清晰的时刻；卡尔发现画像，是一个清晰的时刻；婚约被破坏，也可以被清楚命名为“背叛”。这些事实有画面、有证物、有受害者，很适合进入道德法庭。

露丝受到的束缚却不是一次事件，而是一种环境。父亲留下债务，母亲把家庭的未来压在她的婚姻上，卡尔把礼物和生活保障理解为她应当服从的理由，她又缺少现实的经济独立能力。没有哪一个镜头可以单独概括这些压力，因为它们就像空气，存在于每一个镜头的背景里。

可见的越界容易定罪，背景性的压迫很难截图。

爱玛的欺骗、负债和对女儿的忽视清晰可见，但她受到的浪漫主义式误育，以及职业、经济自主和可选人生的狭窄，也共同塑造了她的欲望。安娜违反婚姻规则清晰可见，社会对男女情欲的双重标准却散落在流言、拜访和礼貌的拒绝里。三个人的处境与责任并不等量，但文学都拒绝把她们的行为当成发生在真空中的选择。

婚恋账本擅长记录谁花了钱、谁承诺了什么、谁先越界，却很难记录一项承诺是否在自由条件下作出，一个人有没有真实的退出权，双方拥有怎样的权力，后果又由谁承担。

这才是复杂性的含义。它不是停止判断，也不是平均分配责任，而是沿着选择权、行为、权力、结构和后果分别判断。爱得真和爱得对不是同一件事，受到伤害和拥有正义也不是同一件事。

好的文学没有替人物宣判无罪。它只是让我们发现，人往往不是因为纯粹的邪恶才伤害别人，而是在追求爱情、自由、尊严和幸福时，把自己的匮乏变成了别人的灾难。

相亲要解决一个几乎不可能的工程问题：在一顿饭的时间里，给一个陌生人未来几十年的人生定价。

这不是夸张的说法，而是对任务本身的精确描述。定价需要信息，而这场交易能获得的信息极少。双方没有共同生活过，没有一起扛过麻烦，没有足够长的观察窗口，却要在很短的时间里判断，这个人是否适合进入一段将涉及住房、育儿、赡养和长期财务安排的关系。

信息不够，人自然会去抓最容易量化的东西。年龄、学历、职业、收入、房产，几乎立刻占据谈话中心。性格和兴趣当然也会被提及，但它们很难验证，也很难比较，就像两份无法互相折算的货币。收入不一样。它是一个数字，干净、直接，还带着一种能预测未来的假象。

于是相亲把收入摆在最显眼的位置，原因未必是人变得更物质，而是收入恰好是这套系统里最省力的压缩算法：用一个数字，替代对一整个人的理解。

问题恰恰藏在这句话里。

收入描述的是一个人此刻的状态，却几乎不涉及这个人应对变化的能力。它能显示这个月的现金流，却不会显示失业以后的走向；能显示此刻所在的公司，却不会显示行业下行时这个人能不能重新站起来；能显示一段履历是否连续，却不会显示这个人是否值得信任。一个变量，被要求回答一整套完全不同的问题，答案自然会失真。

对于抱有职业gap想法的人，这种失真被放大到最明显的程度。相亲市场偏爱连续、稳定、可预演的人生剧本，而“gap”意味着中断、波动和无法提前计算。表面上，这像是“自由”和“稳定”两种价值观的冲突。真正应该被拆开的，其实是另外两个经常被混为一谈的概念：收入波动，和逃避责任。

它们看起来相邻，实际上分属完全不同的坐标系。

一套成熟的婚恋判断，应当允许收入成为变量，同时坚持要求责任保持常量。

一、相亲不是拜金，而是一套低带宽系统

想象一个招聘场景：只能看一页简历，不能面试，也没有试用期，却要决定是否录用一名关键岗位的员工。这时最稳妥的做法是什么？盯住名校、大公司、连续履历和过去的薪资曲线。

这不是因为这些指标真的等于能力，而是因为决策者手里没有更好的信息。指标之所以被采用，不是它精确，而是它便宜。

相亲面对的正是同一种约束。自由恋爱通常伴随一个更长的信息积累过程：两个人可能先是同学、同事或朋友，能观察对方如何对待陌生人、如何处理压力、如何履行一个不起眼的承诺。这种纵向观察提供的信息密度，远高于一张资料表。

相亲恰恰缺少纵向数据，只能依赖横截面——某一个时间点上的静态快照。

收入、房产和职业，就是这张快照里最醒目的几个像素。它们被拿来代理一整批真正重要却难以测量的属性：工作能力、自律程度、生活习惯、家庭资源、社会位置，以及未来分担共同支出的可能性。

这种代理关系当然粗糙，却服从一条几乎普遍成立的规律：任何低带宽系统，都会不自觉地迷信容易量化的指标。学校用考试分数评价学生，公司用绩效数字评价员工，平台用点击率评价内容，相亲则用年龄、收入和房产评价一个潜在伴侣。指标真正的优势从来不是完整，而是便于排序。

而排序一旦启动，人就会被压缩成排序需要的形状。

“目前收入不匹配”很容易被翻译成“这个人不行”；“职业状态不稳定”很容易被翻译成“这个人不可靠”；“年龄不在理想区间”很容易被翻译成“这个人正在贬值”。一个本来只描述阶段的状态量，最后被误读成了一个描述人格的常量。

很多人反感相亲，反感的核心未必是谈钱。房贷、育儿和养老都离不开钱，成年人不可能假装经济条件不存在。真正让人不适的是另一件事：当信息严重不足时，数字不再只是数字，它开始越权，代替对一个人的整体判断。

这也解释了相亲话题为什么天然适合被剪成短视频。观众只需要听到一个金额、一个要求或一句极端表态，就能立刻站队完成判断。复杂的人被压缩成一个清晰的角色，婚恋议题也顺势被改写成一场即时的道德审判。

相亲视频里还藏着一个值得多看一眼的不对称：女性“神人”几乎总被归入同一类问题，也就是“要钱”；男性“神人”却显得千奇百怪——控制欲、爹味、妈宝、自信错位，各有各的情节。

这未必说明现实中女性更同质、男性更多样。它首先说明的是，内容系统对两种角色采用了不同的编码方式。

在传统婚恋脚本里，男性常被放在资源提供方的位置，女性提出的房、车、彩礼和收入要求因此很容易被量化。一旦要求超出观众默认的合理区间，冲突立刻成立，戏剧性也立刻兑现。女性角色因此被压缩到一根单一的轴上：索取多少。

男性如果只是收入不高，通常只会被归为“条件普通”，还不足以撑起一条有传播力的短视频。要成为“神人”，往往需要暴露出更独特的行为问题，案例因此显得种类繁多。

这是一种内容选择偏差，也是相亲市场性别分工的投影。它最值得留意的地方，不是谁更奇怪，而是金钱如何成了解释女性角色的默认语言，行为如何成了解释男性角色的默认语言。观众以为自己看到了两性真相，实际上更多时候，只是看到了平台最容易讲述的两种叙事模板。

平台喜欢这种压缩，相亲机制本身也需要这种压缩才能运转。但一个适合快速传播的判断，未必是一个适合共同生活的判断——这两者的评价标准，从一开始就不在同一个维度上。

二、相亲市场真正讨厌的不是低收入，而是方差

设想两个人。

一个人月收入稳定在两万元，工作路径清晰，未来五年大概率不会有明显变化。另一个人今年收入五十万元，但所在行业波动剧烈，并且有主动停下来休整、转型的可能。

单看期望收入，第二个人未必更差，甚至可能更优。但对一个厌恶风险的决策者来说，第一个人明显更容易被接受，原因不在均值，而在于他未来的分布更窄。

这就是方差在发挥作用。

金融市场评价一项资产，从不只看预期收益，还要看波动率。婚恋市场其实在做一件结构类似的事：收入水平固然重要，但收入是否连续、职业是否稳定、人生轨迹是否按计划推进，同样进入了估值模型。

相亲市场真正追求的目标函数，不是单纯的高收入，而是“高收入且低方差”。如果两者不能兼得，很多人会选择牺牲一部分收益上限，用来换取更强的可预测性——这是一笔理性但不完整的交易。

职业gap恰好会让方差骤然变得显眼。

一个人主动离职几个月，可能是在恢复身体、学习新技能、重新选择方向，也可能只是需要一段暂时不生产的时间。从个人生活的角度看，这些选择都可以是合理的；从相亲资料表的角度看，它们却几乎无法定价。

无法定价的东西，会被系统默认按最高风险计算。

更麻烦的是，收入中断很容易被直接推断为责任中断。对方会担心：gap会持续多久？重新就业是否顺利？共同支出由谁先垫付？所谓“寻找自己”，最后是否会变成另一方长期买单的委婉说法？

这些担心不能简单归为势利，它们有现实基础。真正的问题不在于这种担心存在，而在于它常常被推向一个错误的结论。

相亲市场最常犯的错误，是把“方差较大”和“期望值较低”划上等号，再把“收入不连续”和“人格不可靠”划上等号——一次统计误读，叠加一次道德误读。

一个人的职业路径有波动，不代表他缺乏能力；一个人暂时没有收入，也不代表他会逃避责任。反过来，稳定工作也不自动兑换成可靠人格。有人在同一家公司待满十年，却没有储蓄、负债失控、拒绝沟通；也有人经历过转行和gap，却始终控制着成本、维护着技能，并为每一次暂停承担了明确的后果。

前者拥有的是状态上的稳定，后者拥有的是结构上的稳定。

这两种稳定，外观相似，内部构造却完全不同——就像两栋看起来一样牢固的建筑，一栋只在平静环境中站稳，另一栋则为承受外力和可控形变而设计。

三、真正重要的是结构稳定，不是状态稳定

什么是状态稳定？今天有工作，收入固定，生活轨迹没有明显起伏。这是一张此刻的截图。

什么是结构稳定？当工作、收入和计划发生变化时，一个人的生活系统不会立刻崩溃，而且具备恢复的能力。这不是截图，是一条可以持续运行的曲线。

一座桥的可靠，不是因为它永远没有遇到风，而是因为它能在风里发生形变而不断裂。一套电力系统的可靠，也不是因为设备永不故障，而是因为它内置了冗余、隔离和恢复机制。可靠性工程不会把“永不出错”当成现实目标，而是追求“出错以后仍能运行”。

人的生活面对的是同样的约束。

只要把稳定定义为“永远不变化”，所有稳定都注定只是暂时的。公司会裁员，行业会衰退，身体会生病，父母可能突然需要照顾，一个人的兴趣和价值排序也会随时间改变。今天看起来最连续的履历，无法为二十年后的生活提供任何担保。

结构稳定问的是另一组完全不同的问题：收入中断时，有没有储备？固定支出能否下降？能力是否仍然有市场？能不能接受现实反馈并重新行动？计划失败以后，是主动调整方案，还是把后果转嫁给别人？

这些问题几乎不可能写进相亲资料表，却远比履历更接近长期关系真正需要的可靠性。

可以把这理解成两个互相竞争的风险模型。

第一种模型试图找到一个“永远不会出问题的人”。它偏好大公司、稳定职业、连续收入，指望通过筛选，把未来的不确定性提前排除在婚姻之外——这是一种以为可以消灭风险的模型。

第二种模型承认，没有人能保证永远不出问题，于是把注意力转向一个人怎样处理问题。它寻找的不是静止，而是韧性——这是一种承认风险、转而管理风险的模型。

第一种模型很适合相亲表格，因为它只需要读取一个瞬时状态。第二种模型更贴近真实生活，代价是它需要长期观察和深入交流，而这恰恰是相亲这套低带宽系统最稀缺的资源。

这不是说收入和职业不重要。结构稳定从不排斥当前收入，它只是拒绝把当前收入当作全部答案。

高收入可以积累储备，也可能对应着高负债和高固定成本；稳定工作可以提供安全感，也可能悄悄消耗一个人应对变化的能力；gap可以是一次有准备的调整，也可能是长期逃避的漂亮说法。同一个标签之下，可以装进截然相反的两种现实。

关键不在标签，而在机制。

一个可靠的人，不是履历上从来没有空白，而是即使出现空白，仍然清楚责任落在哪里。

四、婚姻看的是组合风险，不是单人评分

相亲还有一个更深的结构性盲点：它评价的是两个人各自的条件，而婚姻真正运行的，是两个人组合之后形成的系统。这是两个不同层次的问题，却被相亲表格压成了同一张表。

金融学里评价一个投资组合，从不只看每项资产单独有多安全，还要看它们之间的相关性。两项分别看起来都很稳的资产，如果总是在同一时刻下跌，把它们放在一起，组合的风险并不会因此降低。

家庭系统面对着相似的结构。

两个人都身处同一个高景气行业，收入都很高，职业履历都漂亮，看起来是一次强强联合。但如果家庭因此同时背上高房贷、高消费和高教育支出，而两份收入又受到同一轮行业周期的共同冲击，这个家庭的真实风险可能远高于表面数字。

反过来，一个人的工作相对稳定，另一个人的职业更灵活、固定成本更低，单看后者似乎“不够稳定”，两者组合以后，系统却可能更有韧性。当家庭需要迁移、照护父母、处理孩子的问题或应对突发事件时，灵活性本身就是一种可以调用的资源，而不是需要被容忍的缺陷。

相亲市场通常只给每个人分别打分：收入多少，房产多少，职业稳不稳。但家庭从来不是两张评分表简单相加，而是一套资源如何互补、风险如何关联的系统。单项打分，回答不了组合问题。

这意味着，一个人收入的方差较大，不必然会推高家庭的总体风险。真正需要判断的是，这种波动是否可控，是否和另一方的风险高度重合，以及它是否换来了别的能力——时间弹性、地域自由、照护能力、重新配置生活的速度。

同样，一份稳定收入也不必然会降低家庭风险。如果它要求超长工时、依赖单一雇主、悄悄吃掉一个人的健康和学习能力，这份稳定可能只是把风险推迟到了未来某个更难处理的时刻。账面现金流很好看，系统冗余却在持续流失。

真正成熟的婚恋判断，不只是问“这个人安全吗”，还必须追加一个更高维度的问题：“我们组合在一起以后，这套系统会变得更安全，还是更脆弱？”

这里的“更安全”，也不是要求双方都尽量抹平个性，变成两份标准化的工资单。好的组合往往依赖差异：一方更擅长承担确定性任务，另一方更擅长适应变化；一方提供稳定现金流，另一方保留探索空间。只要规则透明、责任清楚，差异降低的是风险，而不是制造风险——这正是相亲表格最难看见的部分。

它能比较两个孤立的人，却很难模拟两个人共同生活以后产生的协同、冲突和冗余。于是系统容易高估“看起来相同的稳定”，低估“能够互补的不同”。

婚姻不是挑选两个分数最高的个体，而是设计一个在现实波动中仍能持续运行的组合。

五、自由不是不要代价，而是自己支付代价

支持职业gap，很容易滑向另一种浪漫化的误区：仿佛只要敢于辞职，就比持续工作的人更清醒；只要强调自由，现实成本就显得庸俗、不值一提。

这是一个需要立刻纠正的判断。

如果每一次gap都需要父母或伴侣承担房租和生活费，那么所谓自由，只是更换了付款人，风险并没有消失，只是换了一个不知情的承担者。如果没有储备、没有重返市场的能力，也没有结束暂停的明确条件，却要求另一半无条件理解，这不是在反抗功利，而是在悄悄外包风险。

自由从来不是“不承担后果”。自由恰恰意味着，选择由自己作出，成本也由自己优先承担——这是自由这个词最容易被略过、却最不能省略的那一半。

可以用一个思考框架来把握这层关系：

可持续的自由，取决于储备、恢复能力和固定负担之间的关系。

储备越充足，越有资格停下来；恢复能力越强，暂停越不容易滑向永久掉线；固定负担越高，一个人的个体决定就越容易外溢，影响到共同生活。三个变量任意一个失衡，“自由”这个词就会开始变形。

这不是要求每个人在gap之前都先实现财务自由，那会把暂停变成极少数人的特权。它只是提醒：gap本身，也需要工程设计，而不能只靠一句“想清楚了就好”来支撑。

控制不必要的固定支出，避免被消费和面子锁死；预留一段没有收入时仍能生活的空间；维护技能、人脉和作品，让重启不必从零开始；提前处理社保、医疗和债务问题；给暂停设置一个复盘点，而不是假装时间没有成本。

这些准备不会消灭失业焦虑，却会彻底改变焦虑的性质。

没有准备时，安全感只能来自“希望公司永远不要裁掉自己”，这是一种寄托在外部承诺上的安全感，脆弱且不可控。做好准备以后，安全感转而来自“即使工作中断，生活也有恢复路径”，这是一种建立在内部结构上的安全感，更难被单一事件击穿。

前一种安全感依赖外部承诺，后一种安全感依赖内部结构——这也是这篇文章反复出现的同一条分界线，在不同层面上的又一次重现。

这正是职业gap最有价值的地方。它不只是休息，更像一次压力测试：当工资停止到账，一个人是否仍能安排生活、维持自我评价，并在合适的时候重新启动？

如果答案是肯定的，gap并没有削弱稳定性，反而是对结构稳定的一次检验。

如果答案是否定的，问题也不在于“gap”这个词本身，而在于生活系统还没有准备好去承受它——错的不是选择，是没有为选择做工程准备。

六、婚姻不是购买低风险资产，而是建立风险共担机制

很多人选择伴侣时，会不自觉地套用一种资产配置思维：寻找一个收入稳定、职业安全、家庭条件不错的人，用来降低未来生活的整体风险。

这个思路本身没有错，但它只完成了一半，而且是相对容易的那一半。

婚姻不是购买一项风险已经被提前锁定的资产。婚姻本身，就是一套风险共担机制。双方不仅要贡献资源，还要共同处理收入变化、疾病、照护、转型和各种意外——这套机制运转得好不好，才是真正决定关系质量的变量。

真正决定一段关系能否承受波动的，通常不是两个人从不失业，而是失业真的发生以后会怎样。

收入突然减少时，双方能否把账摊开、重新调整支出？一个人状态低落时，另一方会提供支持，还是立刻把他归入家庭里的负资产？原来的分工无法维持时，两个人能否坐下来重新协商？当暂停超过原定计划，gap的一方能否接受反馈并重新行动，而不是把“你不理解我”当作拒绝负责的盾牌？

这些问题，没有一个能被一个年薪数字回答。

一段关系如果把人的价值和当期收入直接绑定，就很容易异化成第二个雇主：公司用绩效决定奖金，伴侣用收入决定尊重。人在工作里不敢停下来，回到家里同样不敢停下来。婚姻表面上提供了安全感，实际上只是把绩效制度原样搬进了私人生活，换了一个更亲密的考核者。

成熟的关系不应该承诺“你永远不会出问题”，那是一张永远无法兑现的空头支票。它应该建立的是“问题出现以后如何处理”的协议，这才是一份可以被反复履行的合约。

重要决定需要沟通，基本财务保持透明，双方都尽量保留独立能力，任何一方的暂停都不能无限期地由另一方被动买单。涉及房贷、育儿和赡养时，gap也不再是纯粹的个人决定，而必须升级为共同计划——这是责任从个体扩展到系统之后，必然要付出的代价。

这里还有一条容易被忽略、却至关重要的公平原则：自由必须可以互相给予。

一个人要求伴侣理解自己的gap，也必须认真回答另一个问题：如果有一天暂停的是对方，自己能否提供同样的理解？这个问题不能被绕过，也不能只在需要时单向提出。

只允许自己波动、要求对方永远稳定，那不叫追求自由，只是把低风险资产留给自己，把高波动的成本转嫁给别人。

好的关系无法消除不确定性，但可以持续降低不确定性的破坏力，这才是风险共担机制真正要交付的成果。

七、真正要找的，不是“不在乎钱”的人

既然相亲过度强调收入，最自然的反应，似乎是转而寻找一个完全不在乎钱的人。

这同样可能是一个方向性的误区。

完全不谈钱未必浪漫，有时它只是把现实问题推迟到关系最脆弱的时刻再集中爆发。长期关系本来就应该谈收入、支出、住房、父母、孩子，以及双方各自想过什么样的生活——回避这些议题，不会让它们消失，只会让它们改期。

真正重要的区别，从来不是谈不谈钱，而是能不能谈钱、却不因此给一个人定价。

合适的伴侣，不必赞美职业gap，也不必拥有和自己完全相同的风险偏好。对方可以喜欢稳定，可以担心收入中断，也可以追问具体计划。关键在于，对方能否区分“收入暂时变化”和“人格价值下降”，能否区分“非线性的职业路径”与“长期的逃避责任”。

反过来，想保留gap可能性的人，也不能把所有现实追问都简单理解成物质和控制。关心共同生活的风险，是一种正常且必要的需求，拒绝被简化，不等于要求对方无条件接纳一切。

婚恋中的兼容性，很多时候不是两个人条件相同，而是两个人采用了相容的风险模型——这才是“合适”这个词背后真正的技术定义。

有人相信安全来自连续工作、稳定收入和固定资产；有人相信安全来自低负担、强恢复能力和面对变化时的从容。两种模式都可以自洽成立，但如果双方从未说清各自的模型，就很容易在婚后互相失望——不是因为对方变了，而是因为模型从一开始就没对齐。

这里尤其要避免一种隐蔽的道德优越感。

喜欢稳定的人不一定庸俗，他们可能更看重确定的生活节奏，愿意用职业连续性换取住房、育儿和家庭规划的可执行性。愿意接受gap的人也不一定更勇敢，他们可能只是更看重时间主权，愿意为此承担收入波动和重新出发的成本。

每一种生活模型，本质上都在做一次交换，没有例外。

追求高稳定，通常要接受更强的组织约束、更少的时间自主，以及错过某些探索机会。追求高自由，则要接受更高的不确定性、更严格的自我管理，以及偶尔不被主流评价体系理解的孤独。

不存在一种同时拥有全部收益、又不支付任何代价的方案——这条约束，几乎适用于所有值得认真讨论的人生选择。

真正的问题从来不是哪种模型更高级，而是自己愿意支付哪种代价，又有哪些代价，不能偷偷转嫁给伴侣。

如果一个人希望生活高度稳定，就要承认这种稳定可能限制另一方的转型空间；如果一个人希望随时保留暂停权，也要承认共同责任会限制这种权利的边界。双方需要谈判的，从来不是抽象价值观的高下，而是具体成本的分配方式。

这类谈判看起来不如爱情浪漫，却比互相指责“你不懂自由”或“你没有责任感”更接近成熟的关系状态。

前者会觉得后者不负责任，后者会觉得前者在控制人生。其实，他们很可能只是运行着两套不同的操作系统，彼此都没有错，只是从未同步过底层协议。

越到成年以后，找伴侣越不应该只问“这个人条件如何”，还应该问“这个人想运行怎样的生活”。是否要孩子，愿意承担多高的固定成本，怎么看待职业转型，能否接受阶段性收入下降，遇到风险时倾向独自承担还是共同协商——这些问题，远比一张当前的年薪更接近长期兼容性。

这样的筛选可能会缩小候选范围，却也有机会提高匹配精度。这原本就是同一次取舍的两面。

婚恋的目标从来不是被最多的人接受，而是找到少数真正能够共同生活的人。

八、35岁以后，最该调整的不是价格，而是模型

关于年龄，婚恋市场最喜欢使用一整套资产语言：升值、贬值、行情、段位、清仓。

这套语言的危险，不只是听起来刺耳，更在于它会持续诱导错误决策。一个人可能因为害怕继续“贬值”，仓促进入一段生活模型根本不兼容的关系；也可能为了维护自尊，干脆拒绝一切现实评价，把不行动包装成“随缘”这个更好听的说法。两种反应看似相反，其实都是在回避同一个问题。

年龄不会让一个人的人格价值自动下降，但确实会改变约束条件。认识新人的机会、彼此已有的生活结构、是否还要考虑生育、重新磨合所需的成本，都会变得更具体、更难被忽视。

正确的应对，不是提高焦虑的密度，而是提高行动的密度和表达的精度——这是一个关于配速的问题，不是一个关于恐慌的问题。

更主动地认识人，更早说清自己的生活模型，更快结束明显不兼容的关系；同时，不因为第一次见面缺少戏剧性，就轻易淘汰一个普通但可靠的人。

看多了相亲“神人”，人会变得很擅长识别红旗，却不一定擅长识别普通的好人。现实中真正适合长期相处的人，往往没有强烈的节目效果。他们只是稳定地回复消息、尊重边界、说到做到，遇到分歧时愿意坐下来讨论，而不是升级成表演。

相亲表格擅长筛选条件，却不擅长展示这些不产生戏剧性的品质。因此，认识人的方式本身也值得调整。共同朋友、兴趣社群、长期项目和能够反复见面的场景，会提供更多纵向信息，比一次性的资料表更接近真实。即使仍然通过介绍认识，也可以把交流的重点，从互相估值改成交换生活模型。

“现在挣多少”当然可以问，但更值得问的问题是：“如果收入中断，接下来会怎样？”

前一个问题测量的是状态，后一个问题测量的是结构——整篇讨论最后都会收束到这一组对照上。

结语：稳定的最高形式，是允许暂停

人们通常把稳定理解成一条不断向上的曲线：持续就业，持续涨薪，生活水平只升不降。这是一种非常直观、也非常好用的心智模型。

这种稳定确实很好，但它异常脆弱。只要现实稍微偏离预期，整个自我评价和关系秩序就可能一起动摇，因为这套模型本身没有为偏离预留任何空间。

更高一级的稳定，不是永远没有波动，而是系统能够容纳波动——这才是应该被升级的那个心智模型。

安全感其实有两个层次。第一层是结果可预测：明年仍有这份工作，收入仍是这个数字，生活按原计划前进。第二层是应对有能力：即使预测失败，仍有资源可以调整、有人可以协商、也有办法重新开始。

前一种安全感很直观，却正在变得越来越昂贵，因为现代职业和生活本来就处在持续变化之中，靠不变来兑现安全感，成本只会越来越高。后一种安全感不承诺具体结果，却可以通过储备、能力和关系机制被主动建设出来。相亲主要测量的是第一种，长期生活更依赖第二种。

对个人来说，这意味着工作中断时仍有生活空间，方向错误时仍有重启能力。对亲密关系来说，这意味着双方不会因为收入曲线短暂向下，就取消一个人作为平等伴侣的资格；也不会因为追求自由，就取消对共同生活应负的责任。

相亲市场偏爱一张连续、漂亮、容易计算的履历，这可以理解，因为低带宽系统自然会选择最容易读取的指标。但人生不是为了让履历保持完整而存在，婚姻也不是为了给职业连续性配一位监督员。

真正值得进入的关系，不是保证双方永远不会按下暂停键，而是提前把这些问题谈清楚：谁需要暂停时，生活要怎样继续；暂停持续多久，责任怎样分配；什么时候该休息，什么时候该重启。

这可以叫作一段关系的“暂停协议”。

它不消灭风险，却让风险可以被两个人共同处理；它不纵容逃避，却承认一个人不必靠永不停机来证明自己的价值。

收入可以是变量。

责任必须是常量。

一段成熟关系里最重要的安全感，从来不是保证人生永远不会失速，而是即使暂时失速，两个人依然知道，怎样重新拿回控制权。