当自动化开始自己选路：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 | 可逆性 × 可发现性 × 影响半径 × 数据敏感性 × 所用身份与授权 × 合规要求 → 允许的自主程度 |
生成草稿错误易发现、随时可弃，可以高度自主；改正式稿只要留着版本和 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”这句话最不神秘、也最严肃的那层含义。