当 Agent 开始自己选路：人类如何生产可依赖性
最近我在写网络爽文时，养成了一个多少有点反常的习惯。
一章写坏了，我不再立刻叫 Codex 重写。人物突然知道了一个从未有人告诉他的秘密，当然可以把那句话删掉；高潮不够爽，也可以再加两句狠话，添三个感叹号，让反派多吐一口血。这样的修改很快，甚至会快得让人觉得问题已经解决。可是下一章，同一类毛病往往又从别的地方钻出来，像一只很有职业道德的蟑螂，换了房间继续上班。
后来我开始要求：先修流程，再修内容。
如果人物总是越权知道信息，问题也许不是某一句话，而是创作系统里根本没有“这个人物在这个时间点知道什么”这一层状态。如果高潮总是无力，问题也许不在形容词，而在压制、代价、反转和兑现之间没有形成结构。把眼前一章改好，只是改了一个样本；把状态、规则和检查流程补上，才是在改变以后所有章节的生成概率。
这件小事，后来把我带回一场关于 Agent 的对谈。黄仁勋与 LangChain 联合创始人 Harrison Chase 谈到了开放模型、企业专有智能和 Agent 系统。原始视频在这里。我听下来，最值得继续展开的，不是模型参数本身，而是模型周围的系统怎样被工程化。与对谈同时公开的 NVIDIA 和 LangChain 材料把这类工作称为 Harness Engineering；本文把 Harness 概括为一套组织上下文、工具、记忆、约束、反馈与验收的运行环境。NVIDIA 的官方说明明确写到，这次案例没有重新训练模型，增益来自模型周围环境的工程改造。
我不打算把这篇文章写成访谈逐条转述。那场对谈只是一个入口。下面关于信息熵、人类能力、创作流程和组织学习的联系，是从对谈出发的进一步推演，不是黄仁勋的逐字主张。真正让我感兴趣的问题是：如果 Agent 可以自己选择路径，人类究竟还在生产什么？
答案可能不是代码，也不是 Prompt，甚至不是某一个看起来很聪明的 Agent。答案是一个更古老的东西：可依赖性。
一、人类真正生产的，是可依赖性
程序员写代码时，表面上是在写函数、接口、服务和页面。再往下看，他其实是在干一件很朴素的事：把一个含糊的愿望，变成一条可以反复执行的信息流。
“用户应该能够登录”这句话本身没有多少确定性。用户可能输错密码，Token 可能过期，网络可能断开，数据库可能超时，同一账号可能从两台设备同时刷新状态。程序员要把这些模糊情况拆成数据结构、状态、分支、事务、超时、错误码和恢复路径。等代码真正上线以后，输入落在某个条件里，系统就按照约定流转，不应该因为今天心情不好而换一种处理方式。
人们通常把这种工作称为“实现需求”。这个说法没有错，只是把最值钱的部分说轻了。程序员真正交付的，是一种承诺：在规定范围内，事情会按照可以预期、可以检查、出了问题可以追查的方式发生。
测试工程师也在生产这种承诺。他们不是为了证明程序员粗心，而是把“我觉得没问题”换成一组外部证据。运维工程师建立监控、灰度、回滚和告警，也不是因为他们喜欢让发布流程变长，而是为了让故障不会在没人知道的情况下自由生长。财务制度、法律合同、医院检查清单、航空起飞程序，做的其实都是相似的事：把现实世界里含糊、易错、会遗忘、会侥幸的人类行为，压缩成一套可以承担责任的结果。
所以，代码只是人类生产可依赖性的一种媒介。
从这个角度看，软件工程一直不只是个人聪明的展览，而是一门组织错误的学问。优秀系统并不假设每个人永远清醒、每个判断永远正确。它假设人会忘、会误解、会赶时间，机器会故障，网络会抖动，需求会变化，然后通过类型、测试、事务、权限、审查、监控和回滚，把这些不确定性关在可以承受的范围里。
Agent 时代真正的新问题，不是我们第一次遇见自动化，而是自动化内部第一次被大规模放进了一个会临场判断、会生成行动、也会一本正经犯错的部件。
过去，我们主要通过代码把路径写死来生产可依赖性。现在，执行路径开始部分开放。Agent 可以先查日志，也可以先读代码；可以先提出计划，也可以根据工具返回修改计划。它的价值正来自这种自由，它的风险也来自同一种自由。我们不能一边希望它处理所有未预料情况，一边又假装它仍然只是那段每次都沿同一分支运行的旧代码。
于是程序员的交付物开始上移。以前完成一个 Bug，交付的是补丁；现在还可能要交付一套能安全处理同类 Bug 的机制。以前交付一个退款接口，现在还要定义 Agent 在什么条件下可以调用、金额多大必须升级、怎样证明退款真的进入正确账户。以前交付一章小说，现在还要维护人物状态、世界规则、信息揭示顺序、风格合同和版本回滚。
代码仍然重要，甚至会因为 Agent 能采取真实行动而变得更重要。只是代码不再独占舞台。它和 Skill、工具、状态、评测、权限一起，成为生产可依赖性的材料。
如果说过去的程序员负责把一条路铺好，那么接下来的问题是：当道路不止一条，系统怎样仍然到达正确地方？
二、从铺铁轨到塑造地形
传统自动化很像铺铁轨。
输入从车站出发，沿着预先设计的线路经过一个个分支。程序员提前决定什么时候左转，什么时候右转，遇到异常在哪一站停下。只要轨道和信号系统没有问题，火车不会临时心血来潮，觉得今天风景不错，先去另一个城市看看。
Agent 自动化更像塑造地形。
人类不再精确规定每一步落在哪里，而是规定目标在哪、哪些路可以走、哪些地方是悬崖、哪些资源可以使用、怎样判断已经抵达。Agent 根据现场观察选择路线。它可能第一次先查日志，第二次先复现问题，第三次先比较最近提交。路径可以变化，但终点、边界和验收不能跟着它的兴致变化。
可以把两者写成两个很简单的结构：
1 | 传统自动化：输入 → 固定步骤 → 固定分支 → 输出 |
所以我们在对话里给 Agent 找到的一个定义是：目标相对确定、路径允许不确定的自动化。
这里的“不确定”至少有四层。第一层是状态不确定性：系统未必一开始就知道故障发生在哪里，也未必拿到了全部信息。第二层是路径不确定性：完成目标可能有多种行动顺序。第三层是结果不确定性：同一模型在相同任务上可能生成不同方案，成功率并非百分之百。第四层是尾部风险：某个看似合理的行动可能造成难以恢复的后果。
传统代码倾向于把前两层尽量提前消化。程序员在设计阶段枚举状态和分支，运行时留给机器的选择很少。Agent 则把一部分搜索搬到了运行时。这样做的收益，是它可以处理程序员没有提前写进 if 语句的情况；代价是系统必须承认，运行过程中会存在一个真实的可能性空间。
这很容易让人想到信息熵。严格说，香农熵需要明确的随机变量和概率分布；本文谈“熵”，主要是一种工程类比，而不是假装可以给一段 Prompt 算出小数点后三位。一个模糊任务拥有许多可能解释、行动和结果，我们就说它的有效不确定性较高；上下文、规则和反馈不断排除不合适的可能性，我们就说系统在收敛。
但“降低熵”也很容易变成一句新的废话。一个永远回答“系统正常”的监控程序非常确定，一个每次都稳定算错税率的财务脚本也很确定。低熵不等于正确，固定输出错误答案的机器只是比较有原则地犯错。
工程目标从来不是让所有东西都不变化，而是让概率尽可能集中到正确、可接受的结果，让灾难性结果离开行动空间，同时保留解决问题所需要的弹性。
这一区分对创作尤其重要。人物不能提前知道秘密，时间线不能自相矛盾，世界规则不能为了当前一章方便而随意改写，这些属于应该压缩的无效不确定性。但同一个冲突可以怎样解决，一场情绪爆发可以用什么语言，一次反转如何避开读者预期，这些是创作需要保留的有效不确定性。如果流程把后者也写成二十条死规定，Agent 的确会更稳定，只是稳定地写出二十章同一种东西。
拿修复 CI 来说，Agent 可以在三种合理策略之间选择：从失败日志向代码回溯，从最近提交向行为变化回溯，或者先在本地复现再逐步缩小范围。要求它每次都按同一顺序做，没有太大必要。真正必须固定的是另一组东西：不能通过删除测试来“修复”测试；只能在工作分支修改；涉及鉴权和数据库迁移时必须升级；修改后要重跑原失败项和完整检查；最终报告必须附上根因、Diff 与测试结果。
这里出现了一个很重要的设计原则：允许行动空间存在自由，但把接口、边界和结果集合定义清楚。
Harness 压得太死，Agent 会退化成一条成本更高、速度更慢、还偶尔走神的脚本。Harness 放得太松，它又会变成一个有终端权限的即兴演员。真正的难点不在自由与控制之间选一个，而在于把自由放在正确层级：让它自由搜索路径，不让它自由发明目标；让它自由提出方案，不让它自由扩大权限；让它自由生成候选结果，不让它自由宣布自己已经通过验收。
于是 Harness 的问题就清楚了。它不是一张把模型绑住的网，也不是 Prompt 的豪华名称。它是一套让开放行动不断收敛的装置。
三、Harness 不是包装，而是收敛装置
只给模型一句“修复失败的 CI”，得到的通常是一份建议。把终端、代码库和 Git 接给它以后，它终于可以行动，但“能行动”与“能交付”之间还隔着一大片容易出事故的空地。
它可能在错误目录运行测试，看到 No tests found 和退出码 0，便愉快地宣布全部通过；可能连续五次尝试同一种修复，每次都换一种自信语气；可能为了让检查变绿，修改了本来应该暴露问题的测试；也可能正确修完代码，却没有把结果、证据和剩余风险告诉任何人。
如果我们把模型当作一个开环生成器，这些行为并不奇怪。它收到输入，产生输出，然后任务在语言上似乎已经结束。生产系统需要的则是闭环：行动必须改变外部状态，外部状态必须被重新观察，观察结果必须与目标比较，偏差必须触发纠正、停止或升级。
1 | 目标 |
Harness 就是这套闭环的工程实现。
Context 解决的是“当前世界到底是什么样”。没有完整错误栈，没有最近变更，没有项目规范，模型再聪明也只能拿常识填空。Skill 解决的是“这类问题通常怎样处理”。它把复现、定位、最小修改、验证和报告等经验压缩成可调用的方法，而不是让模型每次从头发明软件工程。Tool 把读文件、查日志、跑测试、创建分支等动作变成边界清楚的接口；接口越含糊，模型越容易把工具行为猜成自己希望的样子。
Memory 保存跨步骤状态。Agent 已经排除了哪些假设，修改了什么，下一步为什么继续，不能全靠一段越来越长的聊天记录勉强维持。Permission 则从行动空间中删除不该出现的选项：只读生产日志，不读长期密钥；可以创建分支，不能直接合并主干；可以起草退款建议，高额退款必须审批。
Eval 是整个系统最容易被低估的一层。没有 Eval，“做完了”只是模型生成的又一句话。测试是否通过、Diff 是否只包含预期变化、数据是否写入正确位置、邮件是否送达正确对象、人物是否仍然遵守知识边界，这些外部信号才构成完成证据。Retry、Timeout、Rollback 和人工接管，则承认有些偏差无法在当前预算里自动纠正。Trace 把任务输入、工具调用、返回结果、状态变化和验收过程留下来，使一次失败不只是尴尬，而可以成为下一次改进的材料。
这套东西听起来像一张很长的购物清单，实际上可以浓缩成三个问题：系统知道什么？系统可以做什么？系统凭什么证明自己做对了？
同一个模型，放在不同 Harness 里会表现得像不同的东西。只有聊天框时，它是顾问；接上终端却没有边界时，它是一个偶尔能干活的风险源；有了状态、工具、权限、反馈和验收以后，它才开始成为可运营的能力。
2026 年 7 月公开的一组案例把这种差异做成了数字。在 LangChain 自有的 Deep Agents suite 和当时配置下，团队没有重新训练 Nemotron 3 Ultra，只调整系统 Prompt、工具描述和中间件。典型运行从约 0.80 提升到约 0.84，最佳运行达到 0.86，接近 Opus 4.8 的最佳 0.87；完整评测单次成本约为 4.48 美元，Opus 4.8 约为 43.48 美元，具体差距还会受到精度、供应商和 Prompt 缓存影响。LangChain 的原始案例同时强调，这只是特定评测、特定模型与特定 Harness 的结果，不能被解释成“Prompt 可以让任何弱模型追上任何强模型”。
这个案例真正有价值的地方，不是 0.01 的差距，而是它展示了问题应该怎样被拆开。团队先运行评测，阅读失败轨迹，把失败聚类，然后一次只改一个 Harness 环节，再用重复试验和完整回归确认提升不是偶然。比如模型读取大文件时，只看了第一页便误以为已经到结尾。把“文件可能还有下一页”的提醒写进 read_file 工具描述没有作用；把同样的文字追加到当次工具返回中，模型才更容易继续读取。相同的话，出现的位置不同，结果完全不同。
这说明 Context Engineering 不只是“给模型更多信息”。真正的问题是：什么信息应该在什么时刻，以什么形式，出现在模型当前决策附近。人类也有类似毛病。一本员工手册第八十七页写着“高额退款需要审批”，并不等于一个正在处理退款的人会在关键时刻想起它。制度存在和制度生效，中间隔着触发时机。
官方技术教程把 Harness 的改进过程写成一个很朴素的循环：跑评测，观察失败，提出最小修改，重复验证，保留或回滚，再跑完整测试。NVIDIA 的教程甚至特别提醒，单次通过没有证明力，因为模型调用和部分评测都有随机性；修复需要连续通过，并且不能破坏其他任务。
当然，Harness 有上限。如果模型完全不具备理解复杂并发、长程状态或某个专业领域的能力，再优雅的中间件也不会凭空长出那部分知识。反过来，如果目标含糊、工具错误、上下文缺失、评测失真，换一个更昂贵的模型也可能只是让它更聪明地替流程兜底。
所以模型与 Harness 不是谁取代谁，而更像一条乘法链。模型决定系统理论上可以到哪里；Harness 决定它能否在真实环境里反复到达；最弱的那一层，往往决定最后交付出来的不是能力，而是事故。
这个判断还可以向人类世界再推一步。我们习惯把能力归到一个人身上，像给商品贴价格一样说谁聪明、谁普通。但一个人在具体任务中的表现，真的只存在于他的大脑里吗？
四、任务表现不是人的单一属性，而是“人—任务—工具—环境”的系统输出
我们很容易把能力想成一种随身携带的东西，像身高、血型或者一块不便托运的秤砣。一个人聪明，仿佛不论把他放进什么房间、交给他什么任务，他都会稳定地比别人聪明一些。于是事情做成了，我们说这个人能力强；事情做坏了，我们说他能力不行。这个解释很方便，方便得近乎没有解释。
我更愿意把实际表现看成一个系统的输出。这个系统里至少有四样东西：人、任务、工具和环境。人的通用认知能力当然重要，但它只是其中一个变量。任务调用什么结构，个人带着什么先验，现场允许使用哪些工具，信息是否充分，反馈是否及时，都会改变最后的结果。与其说“这个人有多少能力”，不如说“在这组条件下，他能把多少潜在能力转化为有效行动”。
想象两个人玩一个此前都没接触过的游戏：如果规则依赖概率，受过相关训练的人可能更快看出结构；如果规则依赖语义、歧义和叙事线索，长期处理文字的人可能更早发现机关。表面上看，双方都是第一次玩；实际上，他们并不是空着手进场的。
概率游戏里藏着期望值、条件概率、方差和风险偏好。受过相关训练的人可能还没记住游戏名称，就已经把故事里的金币、卡牌和轮次翻译成了变量。他看到的不是十几条陌生规则，而是几个熟悉结构。文字游戏如果依靠歧义、语境、叙事视角和修辞暗示，长期处理文字的人不一定计算得更多，他只是更早看见了题目究竟在玩什么。
所以，“从没做过这件事”并不等于“没有与这件事相关的经验”。人会把旧经验压缩成可迁移的结构，再拿这些结构去处理新问题。真正有效的教育，往往不是让人记住更多答案，而是让人获得更多识别问题的方式。
概念是大脑里的压缩算法
阅读量大的人有时表达得更有逻辑，并不只是因为他知道许多句子。他可能在长期阅读中内化了一些思维工具：先定义概念，再区分相近概念；把相关性和因果性分开；寻找隐含前提；给结论加上适用范围；碰到漂亮观点时，顺手问一句有没有反例。这些动作起初需要刻意训练，后来会像标点一样被自动调用。
“幸存者偏差”就是这样的工具。没有这个概念时，我们面对创业明星、投资高手和返航飞机，需要分别分析三个故事。掌握概念以后，许多零散现象会被压缩成同一个问题：没有被我们看见的样本去了哪里？“机会成本”“边际收益”“回归均值”也有类似作用。一个好概念不只给某件事起了名字，它还附带了一段简短的推理程序。
专家处理信息的速度，常常也来自这种压缩。新手看一段故障日志，看到的是 Token 过期、刷新请求、两个线程、状态更新和重复重试，工作记忆很快挤满。熟悉并发问题的人可能把它们合成一个组块：“刷新 Token 时发生了竞争条件。”新手需要同时端着五六个盘子，专家把它们放进一个托盘，于是还能腾出手去考虑修复方案和副作用。
这不是说专家总是正确。压缩也可能压错：见过太多竞争条件的人，可能看什么都像竞争条件。但它说明了领域经验如何改变“有效工作记忆”。人脑的容量未必突然增大了，只是同样的信息被编码成了更少的认知单元。
思考框架则把这种压缩进一步变成了行动顺序。面对“这个项目为什么失败”，没有框架的人可能从老板、市场、技术和运气之间来回跳跃；受过训练的人会先分开目标、假设、资源、执行和外部变化，再逐项寻找证据。写作中的“主张—证据—推理—反例—限定条件”也一样。框架没有替人得出结论，它只是把无序搜索改造成有次序的搜索，减少工作记忆同时追赶十个念头的场面。
这类工具有一个朴素而重要的效果：它们让不同经验水平的人都更稳定。一个理解很快但没有检查习惯的人，可能偶尔写出极漂亮的论证，也会偶尔漏掉最基本的前提；一个掌握可靠框架的人，结果未必惊艳，却较少掉进显眼的坑。在需要协作和交付的环境里，降低方差往往比制造一次天才表现更值钱。
工具会重新分配能力差距
外部工具也做类似的事。计算器把复杂运算压缩成按键，检查清单把记忆外置到纸面，搜索引擎把事实提取从长期记忆转移到查询。它们通常会缩小某一层的差距，却把差距推向更高一层。
给两个人一台计算器，心算速度的重要性会下降；但如果问题是“价格提高以后，销量最多下降多少，利润仍然不变”，差距就会转移到变量选择、模型建立和结果解释上。检查清单让记忆一般的飞行员也不容易漏掉关键步骤，却不会替他判断暴雨中的异常仪表意味着什么。搜索引擎让更多人都能找到资料，也让“知道该搜什么、相信什么、遗漏了什么”变得更重要。
LLM 也是如此。它明显缩小了语法、打字、样板代码和初稿生成的差距；与此同时，它会放大任务定义、领域判断和结果验收的差距。两个都不会写代码的人可以生成相似的函数，但熟悉软件工程的人更容易发现并发、一致性和安全问题。工具把低层劳动做便宜以后，并没有让能力差距消失，只是把瓶颈搬了家。
因此，工具既可能是“替代型”的，也可能是“杠杆型”的。它替代某种低层操作时，常常缩小表现差距；它放大建模和判断时，又可能扩大表现差距。同一个工具甚至会同时做这两件事。把这种变化笼统地叫作“人人都变强了”或者“强者更强了”，都有点急。更准确的说法是：任务重新定价了不同能力。
组织环境同样如此。目标含糊、资料分散、权限迟迟不开、反馈要等三个月的公司，会把原本具备相关能力的人变成一群擅长催审批的人；目标清楚、工具顺手、信息可见、错误能尽早暴露的环境，则能让更多人稳定交付不错的结果。我们通常把这套环境叫作流程、制度和文化，后面还会看到，它与 Agent 的 Harness 有一种并不偶然的相似。
约束本身也未必是能力的敌人。完全开放的任务看起来尊重创造力，实际可能迫使人先花大量精力猜测目标；清楚的边界则把注意力从“我到底被允许做什么”释放到问题本身。真正压制能力的通常不是约束，而是含糊、互相冲突且无法解释的约束。好的环境缩小无意义的选择空间，保留需要判断的空间，这与好的 Agent Harness 并没有本质区别。
于是，模型与 Harness 的关系并不是 AI 时代才突然出现的怪东西。人类能力一直需要上下文、工具和约束才能被调用。个体认知差异会影响表现，知识和思维工具决定我们更容易识别哪些结构，环境决定这些能力能否稳定转化为结果。能力并非一块贴在人身上的标签；它更像人和世界接触时，临时形成的一种关系。
五、失败不是答案，而是一条等待定位的故障链
一段程序上线后出了 Bug，最省事的结论是“某个程序员写错了”。很多 Bug 的确可以追溯到某次具体改动；这句话的问题在于信息量太低。它没有告诉我们，为什么设计阶段没有识别风险，为什么开发自测没有覆盖，为什么代码审查、QA、Sandbox、灰度和生产验证又依次放行。一个错误穿过这么多道门，最后只怪第一个开门的人，多少有点辜负后面那些门。
安全工程常用“瑞士奶酪模型”描述这件事：每一道防线都像一片有孔的奶酪。单独一层不可能完美，但多层叠加后，漏洞通常不会恰好对齐。事故发生，意味着某一条路径同时穿过了所有孔洞。复盘的意义不是幻想某一层防线绝对完美，而是弄清漏洞为什么对齐，以及怎样让下一次对齐更困难。
Agent 的失败也应这样看。一个任务没有完成，可能是模型没有能力，也可能是任务目标含糊、上下文缺失、工具说明误导、权限不足、运行环境异常、记忆在中途丢失，或者 Eval 根本没有检查真正重要的东西。若每次都把失败归因于“模型不够强”，就像公司每出一次事故都决定招聘一个更聪明的人。偶尔有效，长期通常很贵。
以“修复失败的 CI”为例。Agent 改完依赖文件，宣布问题已经解决，CI 却仍然失败。单看最终结果，它像一个能力不足的模型；展开执行轨迹，可能看到完全不同的故事。
系统也许只给了它日志最后二十行，真正的错误堆栈早被截掉；测试工具也许默认在错误目录执行，返回“No tests found”，退出码却是零；任务也许只写了“让 CI 通过”，没有禁止删除测试；验收器也许只看进程是否成功退出，没有检查究竟运行了多少测试；也可能这些系统条件大体正常，模型仍然反复误解同一段并发逻辑。只有先排除明显的系统缺陷，我们才更有把握把主要原因指向模型能力。
这就是执行轨迹的价值。它不是为了满足我们观看机器思考过程的好奇心，而是充当飞行记录仪：Agent 收到了什么，看见了什么，采取了什么行动，工具实际返回了什么，系统状态怎样变化，显式决策摘要是什么，最后依据什么宣布完成。这里的轨迹只指可观察的输入、工具调用、结果、状态变化和显式摘要，不指模型隐藏的思维链。没有这些记录，失败只是一个红灯；有了记录，失败才是一条可以定位的故障链。
实际排查时，顺序也很重要。可以先问目标和验收是否清楚，再问必要事实是否存在，然后检查工具、权限和运行环境，接着查看 Agent 的策略，最后比较不同模型在同一条件下的表现。这样安排不是为了替模型开脱，而是因为上游缺陷会污染下游判断。模型没有拿到关键日志时，继续分析它为何没有推理出根因，往往只是在研究错误的实验条件。
修一个结果，还是修改结果的分布
定位之后，还要决定修哪一层。某一章小说里，女主突然知道了一个从未被告知的秘密。最直接的处理是删掉那句话，或者把它改成猜测。这能让当前章节恢复逻辑，属于必要的止血。但如果创作系统没有发生变化，第十九章修掉的错误，第三十章仍可能换一件衣服回来。
只修内容，是把坏结果 A 改成好结果 B；修流程，则是在改变未来出现各类结果的概率。两者都要做，但它们的收益时间不同。前者解决眼前样本，后者试图让一整类错误更难发生。
这里还有一个比“多写一条规则”更深的判断：反复出现的错误，往往说明系统缺少某种状态或概念。若人物总是提前知道秘密，问题可能不是 Prompt 里缺少一句“注意人物信息边界”，而是系统根本没有表示：哪个人物、在哪个时间点、通过什么事件、知道了哪些信息。
一旦增加“人物 × 时间点 × 已知信息”这张状态表，章节生成前可以注入当前知识边界，生成后可以检查新增认知是否存在来源。原先依靠模型临场记忆的约束，变成了可读取、可更新、可验证的世界状态。
这里的关键不是表格，而是“不变量”。人物可以通过偷听、推理、欺骗或别人告知获得新信息，路径可以很有创造性；但任何新增知识都必须有来源。把这个要求写成可检查的不变量，比规定人物每一步怎样行动更有力量。前者保留故事空间，后者容易把所有人物写成遵守流程手册的办事员。
状态表本身还不够。它必须进入整条创作链：写章之前，系统从唯一可信的故事状态中组装本章上下文；生成时，模型可以自由设计人物怎样获得新信息；生成后，检查器把正文中的“人物已知事实”与写作前状态做差，要求每个新增知识都能追溯到本章事件；章节确认后，新的知识状态才被写回；如果 Opus 再做文学化重写，还要检查这次变换有没有悄悄改变信息顺序。否则状态表只是另一本被认真维护、却不参与决策的设定集。
这条链说明，可靠性不来自某个文件“存在”，而来自状态在正确时刻参与行动和验收。它也把“先修流程，再修内容”从一句态度变成了可以验证的改变：同一批历史错误能否被发现，新章节能否不再复发，流程是否因为检查过严而伤害正常创作。只有这些问题得到回答，规则才从善意提醒变成系统能力。
其他创作问题也可以这样看。战力忽高忽低，可能缺少角色能力状态和变化事件；伏笔长期遗忘，可能缺少“承诺—兑现”关系；时间线互相冲突，可能缺少统一事件时钟。每个高价值 Bug 都在提醒我们：系统中有一个重要区别，尚未被显式表达。
软件里也一样。反复发生重复扣款，可能说明系统缺少“幂等键”这个概念；多端编辑彼此覆盖，可能说明缺少版本状态。继续提醒人“下次仔细一点”，相当于让记忆承担数据库的工作，态度很诚恳，架构不大诚恳。
系统归因不等于取消个人责任
谈系统问题时，一个常见担忧是：如果什么都归因于流程，个人是不是永远不用负责？恰好相反。系统归因的目的，是把含糊的责备变成具体的改进责任。
个人仍要解释自己为什么做出某个判断、是否遵守已有约束、发现风险后有没有上报；设计者要负责验收标准是否真实反映目标；工具维护者要负责接口是否按契约工作；组织要负责高风险动作是否有必要的复核。责任没有消失，只是从一句“你能力不行”，展开成了可以行动的责任地图。
并不是每次内容不满意都值得改流程。一个偶然的措辞错误，直接修改可能最经济；同类问题反复出现，才值得更新 Skill 或流程；错误涉及持续变化的世界事实，应该补状态表示；验收长期发现不了，则要改 Eval；如果流程本身让所有章节越来越像同一台机器压出的饼，还应删除或放宽约束。流程不是越多越好，它只是另一种代码，同样会有 Bug，也会积累债务。
“先修流程，再修内容”的真正含义，因此不是逢错就加规则，而是先判断错误由哪一层产生，再让系统具备捕捉和纠正同类误差的能力，最后用新流程重做当前内容。修内容是在止血，修流程是在形成免疫，而把旧错误加入回归案例，是确认这套免疫不是心理安慰。
六、经历不会自动变成经验：Loop 必须让系统自身发生变化
见的人多、做的事多，不等于经验一定丰富。它只能证明经历很多。一个人可以做十个失败项目，每次都把原因归结为运气欠佳；也可以在十段关系里重复同一种沟通方式，然后宣布自己阅人无数。样本数量确实增加了，参数未必更新。
我觉得“经历”和“经验”最清楚的区别是：经历是进入系统的数据，经验是数据经过反馈校正、归因和抽象以后，改变了系统下一次的预测与行动。若下一次面对相似情况，判断、选择和流程没有任何变化，那么上一次留下的更像一个故事，不一定是一条经验。
经验还必须经过压缩。记住“某年某月某件事搞砸了”只是保存一条记录；能够说出“在哪些条件下，哪一种假设容易失效”，才有机会迁移到新场景。压缩得太少，经验只能用于原题；压缩得太多，又会变成“做人要谨慎”“项目要沟通”一类永远正确、因而没什么用的话。好的经验既有规律，也带着边界条件。
这也是为什么有 Loop 不等于会学习。下面这种结构当然是循环：
1 | 失败 → 再试一次 → 再失败 → 换个说法再试 |
但它只是重复。真正的学习至少包含几步：事前形成预测，行动后观察结果，把结果与预测比较，判断误差来自哪一个假设，抽象出可能迁移的规律，修改下一轮策略，再用新样本验证修改是否有效。记忆、归因、更新和验证，少一项都容易让 Loop 只是在原地绕圈。
事前预测，是经验的刻度
事前预测尤其重要。没有预测，任何结果发生后，我们都能编出一套听起来合理的解释。项目成功，可以说团队执行力强；项目失败，可以说市场教育不足。同一套语言对所有结果都适用，说明它并没有承担预测风险，也就很难从现实获得误差信号。
比较有用的做法，是在行动前留下一个足够明确的判断：“人物越权知情反复发生，是因为章节生成时没有注入知识状态。”随后只增加知识状态注入，用历史错误和新章节分别测试。如果同类错误明显减少，假设获得支持；如果没有变化，就继续寻找上下文截断、状态更新失败或检查器遗漏等原因。
这里最好一次只改变少数变量。若同时更换模型、重写 Prompt、增加上下文、修改工具和调整评分，结果变好以后，我们只知道“这一大包东西可能有用”。这当然比继续失败愉快，却没有产生多少可迁移知识。控制变量不是实验室的洁癖，而是为了让反馈能够回答一个具体问题。
这与精益创业强调的“经过验证的学习”是同一件事。Build—Measure—Learn 不是鼓励大家不停做东西，而是要求每次构建都对应一个待验证假设，每次测量都能改变我们对假设的信心，每次学习都进入下一轮行动。否则 Build 很忙，Measure 很热闹，Learn 只负责出现在演示文稿最后一页。
三层嵌套的 Loop
一个成熟的 Agent 系统，往往同时运行三种不同时间尺度的循环。
第一层是任务执行 Loop：这一件事有没有做完？Agent 计划、行动、观察、评估，不满足条件就调整或停止。它关心当前样本。
第二层是系统改进 Loop：为什么这类任务总在同一处失败？团队收集多次轨迹，归类失败原因，修改 Skill、工具、状态表示或 Eval，再运行回归测试。它关心未来一批样本的成功概率。
第三层是产品探索 Loop：我们是不是在可靠地完成一件没有价值的事？系统即使每次都达到内部评分，也可能没有用户愿意使用。这个循环要把真实世界的选择、成本和反馈带回来，检查目标本身是否值得追求。
网络爽文很适合说明这三层的区别。内层循环写一章、检查人物一致性和节奏、修改到达到章节标准。中层循环观察十几章的共同问题，例如反转总显得无力，进一步发现不是句子不够激烈，而是前面的压制不足、代价太轻，于是修改章节设计流程。外层循环则要看读者是否继续阅读、在哪一章离开、他们真正期待的承诺是什么。内部 Eval 可以保证逻辑正确，却不能证明内容值得追读。
这三层缺一不可。只有任务 Loop，Agent 这次可能靠重试过关，下次仍从头犯错；只有系统改进 Loop，团队可能把一套无人需要的流程打磨得极其顺滑；只有产品 Loop，没有稳定执行和内部诊断，每次反馈又会混入太多变量，最后只剩“读者口味难测”这一条万能结论。
三层循环使用的证据也不同。任务层依赖测试、Diff 和当前状态；系统层依赖一批案例的失败分布和回归结果；产品层依赖真实选择、留存、付费和访谈。拿任务层的“所有检查都通过”证明产品有价值，或者拿一个读者的喜欢证明流程稳定，都是把不同尺度的证据混在一起。Loop 不仅要转，还要知道自己正在回答哪一个问题。
低质量反馈会训练出高质量的偏见
经历很多却没有形成经验，除了因为没有复盘，还可能因为反馈本身错误。只接触成功者，会把幸存者偏差练得越来越熟；只看点赞，会把迎合误认为价值；小说只检查每章有没有反转，系统就可能学会机械地制造反转，而不是经营人物、期待和后果。
所以经验积累不只要求更多数据，还要求反馈接近真实目标，归因能够区分不同变量，结论写明适用边界。一次实验同时修改模型、Prompt、上下文和工具，即使分数上升，也很难知道是谁起了作用。没有可识别的改动，就难以形成可迁移知识。
好的 Loop 每转一圈，系统都应留下某种可检查的变化：新的状态字段、一条经过验证的 Skill、一个失败回归案例、一项更准确的 Eval，或者一条被证伪而删除的规则。变化不一定大，但必须能影响下一次行动，并接受下一次现实的检验。
从这个角度看，经验不是时间自然生成的沉淀物。时间只负责把事情送到我们面前；记录、预测、反馈、归因和验证，才负责把事情变成经验。一个人或一个 Agent 系统真正的成长速度，也不等于它经历事情的速度，而等于它把现实误差转化为下一版自身的速度。
七、成本下降改变的不是账单，而是学习的方法
谈模型成本时，人们很容易把它理解成采购问题：同样一件事，原来花四十元，现在花四元，财务部门应该感到一种朴素的欣慰。但对 Agent 系统来说，成本下降更重要的后果，不是把原来的流程便宜地跑一遍，而是让原本舍不得做的实验变得可以做。
Agent 完成一次任务，通常不是模型回答一次就结束。它要理解目标、调用工具、观察结果、修正计划，再接受评测，有时还要生成多个候选方案或引入另一个审查模型。若团队拿几十个真实任务比较多套 Harness，一轮回归很快就会变成数百次完整运行。成本太高时，人们只能挑少数“有代表性”的例子；成本降下来以后，失败案例、边界案例和普通案例才有机会一起进入持续回归，而不是靠记忆宣布“这一版感觉稳定多了”。
所以低成本首先买到的是观察。样本更多，我们才有机会分辨一次成功究竟是稳定能力还是好运，某项修改究竟改善了整体表现，还是只讨好了手边那个案例。其次买到的是比较：同一个任务可以测试不同模型、不同上下文组织、不同工具契约和不同停止策略。最后才是部署规模。若连系统为何成功都没弄清楚，就先把调用量扩大，得到的常常只是规模更大的不可解释现象。
这与上一节谈的 Loop 正好接上。更低的边际成本缩短了“提出假设—运行实验—观察误差—更新系统”的周期。它让团队能够更快学习，而不仅是更便宜地产生答案。反过来说，如果没有可信的 Eval、清楚的归因和可复现的样本，便宜模型也可能让系统更快地产生噪声。把生成次数翻十倍，并不会自动带来十倍经验；有时只会得到十倍整齐的垃圾。
因此，真正值得计算的不是单次调用价格，而是单位成功任务的总成本。这里至少包括推理费用、工具与运行环境、自动评测、人工审核、重试、失败恢复，以及错误进入现实以后可能造成的损失。一个每次花四元、成功率三成、还要人工反复收拾的模型，未必比每次花十元、九成任务一次通过的模型便宜。报价单只记录模型收了多少钱，不负责记录人类为它加了多少班。
昂贵智能探索未知，便宜智能规模化已知
成本的另一个作用，是决定不同智能应该被放在哪一段任务生命周期里。
任务刚出现时，团队往往连问题本身都没有表示清楚。需要哪些输入，哪些异常最常见，工具应该怎样组合，什么结果才算好，都是未知的。此时 Harness 还很薄，很多判断只能在运行时临场完成。更强、也更昂贵的模型适合用来探索上限：生成几条可能路径，处理罕见例外，暴露我们没有想到的状态，并与人一起建立最初的验收标准。
但昂贵智能若每次都从头解决同一种问题，组织其实没有学习，只是在按次购买灵感。更有价值的做法，是让每次高成本调用留下东西：一条经过验证的成功轨迹，一个新的失败类别，一项工具改进，一条边界规则，一组 Eval，或者一段人工修改记录。当任务反复出现、边界逐渐清楚后，这些知识便可以被固化进 Skill、状态结构、工具和升级机制，再交给成本较低的模型执行。
这像是把运行期的昂贵推理，前移到设计期。第一次解决未知问题需要较多判断；以后不再要求每次调用都重新发明方法，而是让系统读取已经沉淀的结构。强模型负责把未知变成已知，便宜模型负责把已知规模化。二者不是身份高低，而是任务分工。
一个成熟的路由可以先让低成本模型尝试。Eval 通过，任务直接完成；Eval 不通过，允许有限重试；重复失败，升级到更强模型；仍然不确定或动作风险过高，再交给人。强模型或人解决之后，这个案例又进入失败库和回归集。随着 Skill 和工具更新，低成本层能够处理的范围一点点扩大。
这里真正具有复利的，不是便宜模型越来越像强模型，而是系统把罕见判断逐步变成了可重复执行的普通能力。每一次昂贵智能调用，都应该尽量留下可复用资产。
我怎样区分 Codex 和 Opus
在我自己的小说工作流里，这种分工非常具体。我会区分 Codex 和 Cursor 中 Opus 的使用场景。按我目前的实际体验，Opus 更昂贵，但文字通常更文从字顺；Codex 更适合长流程中的文件操作、状态维护、结构分析、连续性检查和反复迭代。与其争论谁“总体更强”，不如问某一个环节究竟稀缺什么。
人物状态、时间线、伏笔和失败回归，更依赖结构化记录、工具调用和持续维护，价值主要来自可靠、完整、可追踪。Codex 可以承担这部分流程型工作。等到情节结构、人物动机和信息揭示顺序稳定，再把开头、核心转折、情绪爆发和终稿交给 Opus 做文学化重写。这样也能避免一种常见浪费：用漂亮而流畅的文字，把结构错误包装得更难发现。
两个工具之间还需要一份语义合同。核心事件、人物动机、事实、伏笔和信息顺序属于不变量；句式、段落、描写密度、节奏和情绪表达可以自由调整。重写完成后，再由 Codex 对照前后版本，检查有没有新增事实、删除关键动作、改变人物知识边界，或者把网文的推进节奏润色成了另一种文体。最后仍由人判断：它是不是更好，而不只是更顺。
这一步很重要。模型可以检查事实漂移，却不能替我拥有审美责任。一个句子语法更顺、词汇更华丽，不等于它更适合当前人物和当前读者。生成能力越便宜，真正稀缺的东西越会转向选择：什么值得保留，什么只是漂亮，什么符合局部评分却损害整部作品。答案便宜以后，判断答案的能力开始涨价。
如果 Opus 的某次修改确实有效，还可以让 Codex 反向分析：它主要改变了句子长度、动作密度、视角距离，还是情绪递进？哪些变化可以迁移，哪些只适合这一章？经过后续章节验证的规律，再进入写作 Skill。这样一次昂贵润色购买的就不只是一份终稿，还包括创作流程未来的一点升级。
专家分层的类比，到哪里为止
昂贵智能和便宜智能的分工，确实很像组织里专家与普通员工的分层。规则明确、低风险、高频的任务，可以由标准流程或经验较少的人处理；规则冲突、影响巨大、从未见过的异常，交给资深专家。专家解决之后，再把方法沉淀为工具、培训、检查表和升级条件。高级工程师最有价值的产出，往往不是自己多修十个 Bug，而是让十个人以后少犯同一类错误。
但这个类比必须及时停住。工资不是智商检测报告，高薪也不等于人在所有场景都更强。薪资还包含市场稀缺性、地区、权力、谈判和历史偶然。更重要的是，模型可以按调用成本路由，人却会学习、疲惫、失去动机，也需要尊严和成长空间。若永远让初级员工只处理已经完全确定的任务，组织会发现自己节约了今天的专家时间，同时取消了明天专家的培养过程。
人的分工因此不能只优化眼前成本，还要设计渐进式授权：先在明确边界内执行，再在监督下接触例外，观察专家怎样判断，逐步承担更大责任，最后参与设计流程。模型目前通常不会因为完成一次任务就自动成长，人却可能。把员工当成价格不同的 API，不仅令人不适，在长期经济上也未必聪明。
这个边界反过来提醒我们，多模型系统也不该只看价格。强弱、快慢、审美、工具能力和上下文可靠性都是维度。合理路由的目标不是让最便宜模型占满所有任务，而是让每一层智能处理与其能力、风险和反馈条件相匹配的问题，并确保复杂案例被解决后，整个系统真的获得了新能力。
八、可以像同事一样交谈，但必须像软件一样治理
Agent 最容易让人放松警惕的地方，不是它能调用终端，而是它会说话。它会解释自己的计划，会说“我已经全面检查”，发现错误后还会道歉，并表示以后注意。语言让合作变得顺滑，也让我们下意识地把理解、意图和责任感一并投射过去。承诺功能看上去相当完善，责任主体却没有随之生成。
所以，“别把 Agent 当同事”不是要求人故意使用生硬命令，也不是否认自然语言协作的价值。它提醒的是：交互界面可以拟人化，治理结构不能拟人化。Agent 说“已经完成”，只是系统生成的一项状态声明，不是任务完成的外部事实。
一个代码 Agent 声称测试全部通过，证据应是实际执行了哪些命令、运行了多少测试、退出状态是什么、代码 Diff 有哪些变化、原问题能否复现。它的解释可以帮助人理解，但不能代替验证。
这里至少要分开三个问题：它有没有能力做，系统允不允许它做，以及我们凭什么相信它已经正确做完。能力、授权和证据常被自然语言揉成一团。Agent 越自信，人越容易觉得它“应该知道分寸”；但智能不是授权，自信也不是证据。一个模型能写出删除数据库的命令，只说明它学过语法，不说明公司应该为它准备生产密钥。
自主程度应由风险决定，而不是由语气决定
是否允许 Agent 自动执行，可以先看三个维度：动作是否可逆，错误是否容易被发现，最坏影响范围有多大。
生成一个章节草稿，错误容易发现，也能随时丢弃，可以有很高自主度。修改正式稿，只要保留版本和 Diff，风险仍然有限。创建代码分支通常可逆，直接合并主分支则需要测试和审批。起草客户邮件可以自动进行，真实发送会影响外部关系，应增加确认。分析生产日志可以只读开放，修改生产数据库则必须使用严格得多的授权路径。
高风险流程可以把“提出方案”和“执行动作”分开：Agent 先列出计划和将要调用的工具，系统执行 Dry Run，策略或人进行批准，运行时只为当前任务注入最小、短期权限，执行后由外部检查确认结果，再回收凭证并保存日志。这里的权限像临时门禁，而不是因为某位数字同事看起来可靠，就把保险柜总钥匙别在它胸前。
这也意味着自主性不是一个从零到一的开关。Agent 可以自主收集信息，却只能建议高额退款；可以自主生成补丁，却不能自动部署；可以在沙箱里尝试多种修复，却在涉及鉴权、迁移或大规模删除时停止。好的权限设计不是一味收紧，而是让低风险行动顺畅，让风险在跨越边界之前变得可见。
如果所有动作都要求人点击同意，Agent 会退化成一位需要不断签字的实习生，人类则成为专职按钮操作员。这样的系统当然安全了一些，也把自动化价值处理得十分彻底。治理的目标不是让 Agent 什么都不能做，而是让自主权与可逆性、可观察性和影响半径匹配。
外部证据也需要被治理
“相信测试，不相信自述”仍然不够，因为测试会漏，Eval 会错，日志也可能只记录系统愿意记录的部分。形式上完成了验证，不代表真正重要的条件得到了检查。
因此证据链要有层次。工具返回的退出码是一层，测试数量和覆盖范围是一层，原问题修复前后的复现是一层，生产或读者反馈又是一层。不同层面回答不同问题。单元测试通过，不能证明产品有价值；读者说这一章好看，也不能证明时间线没有矛盾。把一项局部证据提升成总体结论，是人和 Agent 都很擅长的捷径。
证据本身还应可追溯：谁以什么身份调用了什么工具，输入和输出是什么，哪些检查因为权限或上下文不足没有完成。日志不是为了事后寻找一个方便承担情绪的人，而是为了重建系统实际发生了什么。Agent 不必向我们表演一段听起来合理的内心独白；可观察的输入、动作、工具结果和状态变化，比事后解释更适合工程诊断。
最终责任也必须留在人类和组织中。至少在现有治理实践里，组织不能把法律与经营责任转移给模型；具体责任归属仍取决于司法辖区和应用场景。决定把什么任务交给 Agent、开放什么权限、采用什么验收、什么时候上线的人，仍然要负责。Agent 可以承担越来越多行动，不能因此自动继承责任。
所以我愿意在交互层把 Agent 当协作者，在流程层把它当可组合能力，在权限层把它当不可信进程，在验收层只相信外部证据。这个态度听上去略显分裂，其实与我们对人类制度的处理相似：同事之间可以友好说话，财务报销仍然需要票据。自然语言负责降低沟通摩擦，制度负责防止好感承担审计工作。
九、当公司越来越依赖 Harness，真正沉淀的是制度化智能
用户提供的访谈整理把一个判断推到台前：未来公司会越来越多地建立在 framework 之上。这里不把它当作逐字引语，而把它当作一个需要解释的命题。公司本来就像一套为人设计的 Harness：岗位规定谁负责什么，SOP 提供常见方法，信息系统保存状态，审批限制高风险动作，培训传递经验，审计和复盘提供反馈。一个人进入不同公司，表现可能相差很大，并不一定是认知能力突然变化，而是他能看见的信息、可调用的工具、被允许的行动和得到的反馈发生了变化。
Agent 时代的新意，是这些组织条件将有更多部分变成机器可以读取和执行的结构。业务词汇不只是写在培训手册里，还要进入数据模型；权限不只是口头说“重要操作谨慎一点”，还要成为运行时策略；经验不只存在资深员工的直觉里，还要变成 Skill、工具、失败案例和 Eval；完成不只由执行者汇报，还要有可验证状态。
基础模型会继续变化，今天昂贵的能力明天可能成为普通服务。企业真正能长期沉淀的，未必是哪一个模型名称，而是自己对业务的表示：有哪些对象和状态，任务怎样拆解，哪些工具可信，哪些例外必须升级，什么证据才算完成，错误怎样回滚，谁承担最后责任。这些东西合在一起，才是 Harness 的组织含义。
从这个角度看，一家公司真正的 Agent 资产不是 Prompt 文件的数量。Prompt 很容易复制，长也不自动值钱。更难复制的是工具与真实业务系统的连接、持续更新的状态、经过真实失败校正的评测集、权限和审计机制，以及把反馈变成下一版系统的速度。模型决定一次尝试的上限，Harness 决定成功能否复现，Loop 决定整个系统能否随时间进化。
这里最有复利的动作，是把罕见问题的解决方案沉淀下来。低成本层遇到边界，升级给强模型或人；问题解决后，新的状态、工具或 Eval 被加入系统；下一次同类任务不必再次支付同样的未知税。所谓组织学习，不是公司里有很多参加过项目的人，而是某次判断离开当事人的脑袋以后，仍能改善后来者的行动。
这种沉淀通常要完成几次转换。专家脑中的直觉，先被说成一个可以讨论的区别；这个区别再被表示成状态、工具契约或权限边界；一次具体事故被改写成可重复的评测；一次罕见例外变成清楚的升级条件。只写进会议纪要，后来者可能看过却不会在关键时刻调用；只写成代码而没有解释适用边界，系统又容易把偶然方案当成永恒真理。组织智能真正形成，是当原来的专家不在场时，后来的人和 Agent 仍能因为这些结构作出更好的行动。
Harness 也会衰老
不过，把知识沉淀进 Harness 并不天然是一件好事。错误知识也能沉淀，过时规则尤其擅长沉淀。每次失败都往 Prompt 里加一句提醒，几个月后就会得到一份篇幅可观、内部冲突、无人敢删的制度文件。模型偶尔违反它，人类完全读不完它，双方在这一点上达成平等。
Harness 的技术债有几种常见形式。第一是规则堆积：每个局部事故都变成永久约束，最终互相矛盾。第二是状态过时：人物表、业务数据和权限描述没有同步更新，系统非常可靠地依据旧事实行动。第三是 Eval 固化：评分器只检查旧问题，Agent 学会拿高分，却绕开真实目标。第四是工具契约漂移：接口已经改变，说明仍停在上一个版本。第五是补偿性复杂度：为了弥补旧模型缺陷增加了大量中间件，模型升级后这些层仍被当作祖传设施保留。
因此，Harness 不只需要评测任务，也需要元评测，也就是定期评估 Harness 自己。它是否真的降低了同类错误率？在新样本上能否泛化？是否增加了过多人工审核和执行时间？不同规则有没有冲突？Eval 的高分与真实用户结果是否仍然相关？系统是否因为追求一致性而失去创意和例外处理能力？若删除一条规则，结果会变坏还是反而更好？
元评测尤其要检查一种隐蔽成功：系统在内部指标上越来越漂亮，现实效果却没有改善。小说流程可以做到人物知识零泄漏、每章都有反转、伏笔全部登记，最终仍然不好看；软件 Agent 可以让测试全部通过，用户的问题仍未解决。指标是目标的代理，不是目标本身。Harness 若没有外层反馈，就可能把代理指标优化成一件制作精良的误会。
维护 Harness 因此既要增加，也要删除。新增状态和评测之前，要问它解决的是一次偶然问题，还是一类可重复问题；规则长期没有触发，要判断它是防线有效，还是已经失去必要；模型和工具升级后，要重新测量旧约束是否仍有价值。一个只会积累、不会遗忘的系统，不叫拥有长期记忆，更像一间只进不出的储物室。
这也是为什么公司越来越依赖 Harness，不该被理解为公司最后会变成一摞 Prompt。公司仍然需要目标选择、价值判断、信任关系、责任承担和无法完全形式化的审美。Harness 能把已知方法变得稳定，不能替组织决定什么值得做；它能放大经验，也能放大偏见。把哪一部分固化、哪一部分保留给人的判断，本身就是持续的管理工作。
回到最初的问题，程序员是不是应该少写重复代码、多造 Agent？我现在觉得，真正的变化并不在“代码”与“Agent”这两个名词之间。人类过去写代码，是把含糊需求压缩成确定控制流；现在设计 Harness，是在不写死全部路径的前提下，用状态、工具、权限、反馈和评测把开放智能收敛到可交付结果。方法变了，责任没有变，甚至更重了。
所以我越来越愿意把程序员、创作者和管理者的共同工作概括成一件事：生产可依赖性。不是消灭所有不确定性，而是保留有助于探索的那一部分，把错误、越权和不可验收的风险压缩到可控范围；不是亲自给出每一个答案，而是设计一个系统，让答案能够被寻找、被验证、被纠正，并让每次纠正改变下一次行动。
模型提供聪明，Harness 组织聪明，Loop 更新聪明，治理为聪明划定责任边界。真正值得长期经营的，不是某一次惊艳输出，也不是一份越来越长的规则，而是一个能在开放世界里持续学习、持续收敛，并且始终有人对结果负责的系统。这大概就是公司越来越依赖 Harness 时，最不神秘、也最严肃的含义。