三周前那篇讲 AI harness engineering 的文章，我读到就存下来了，没写。写得挺好，该说的话都说了——问题恰恰在这：一篇带五十来条评论的工程师随笔，本身还构不成一条曲线。单看它是一帧。作者说 AI 已经能挤进需求、细化、规划、构建、验证这五个环节里的每一个，说编码未必是真正的瓶颈，说给模型堆更多文档反而可能让它更糊涂。每一条单拎出来都对，但对的话不构成判断。
真正让我把它从收藏夹里翻出来的，是评论区那几个反复冒头的说法：「加上认证」这种工单到底缺了什么、评审归谁、完成的定义要不要重写、没有代码库权限的 PRD 会让代理在假设上盖楼。这几个词我过去一两年在别的地方见过，每次都换一副面孔。同一个说法第三次穿着不同衣服出现，就不能再当孤例处理了。
作者的落点是「AI 工程本身不难，难的是改变我们围绕它工作的方式」。这话对，也不新——每次抽象层往上挪一格，都会来一轮「原来瓶颈不在工具」的发现，编译器时代、云时代是同一个句式。新的不是句式，是这次被露出来的那层东西的品种。
这里我要认一个分类错误。去年这套三层棋盘（模型层/壳层/场景层）我用过一次，当时顺手就把「围绕代理搭的那套环境」塞进了壳层，理由是它看起来像工作流整合。现在看塞错了，错得还挺关键。三层棋盘本来是拿来放「能被买卖的东西」的：模型层卖推理，壳层卖工作流和习惯，场景层卖信任和权限设计。可 harness 里面那大半内容——评审规范长什么样、什么算做完、代理能碰哪些系统、知识该放在哪儿、代码库怎么布局——没有一件是可采购的，只能由一家公司自己长出来。把一家公司的内部秩序，往一张讲供给侧的棋盘上放，是我图省事；框架用错格子，比没有框架更容易让人误以为自己想清楚了。这条记下来。
于是问题换了位置。不再是「谁能做出更好的 harness」，而是「哪家公司的内部秩序能让代理真正跑起来」。这个转向要命的地方在于，它把这一轮的分野从供给端挪到了需求端，而需求端历来是慢变量扎堆的地方。我此前说过国内和硅谷在 vibe coding 上的差距不在模型能力，在于企业采购结构和为效率工具付费的习惯——harness 这件事基本是同一个判断的又一次重复，只是这次连硅谷自己也没修好，所以差距暂时被拉平了。这是个错觉。
评论区里最具体的那几条，几乎都没在谈选什么工具。有人讲本地跑一个窄子集——定向单测、linter、状态 diff——把反馈压在五分钟以内，标准 CI 只做合并前最后一道关卡；有人讲用退出码和错误流回灌上下文，而不是让模型自己给自己打分；还有人把「加上认证」这类工单拆开，说密码重置、令牌校验、令牌刷新各有不同的影响范围和撤销方式，所以恢复路径本身就得写进完成的定义里，先讲清楚这次改动是可逆的、可补偿的、还是永久不可逆。表面上在讲流程，实际上全在做同一件事：把原来靠人脑默契维持的边界，改写成可执行的判定。
我拿一个不指向任何具体团队的说法往下推。给令牌刷新写一块工作，人来写的时候，工单可以写得很糙，因为接单的人自带一整包默认常识，会顺手把失效路径、旧令牌的撤销、并发场景补齐。代理没有这包常识，也没有那杯顺手接过来的咖啡。所以「完成」必须从一段文字描述变成一条能跑的判定；测试通过算不算完成，得看这条测试有没有覆盖撤销路径，而不是看它是不是绿的。这一步听着像洁癖，其实是把定义成本从隐性挪到显性。
| 路线 | 谁付这笔定义成本 | 能不能跨公司搬走 | | 内部 harness | 公司自己，以评审时间和更小的工单形式付 | 基本搬不走 | | 托管 harness | 按席位或按量付费 | 能搬，但只覆盖通用那截 |
顺这个方向再推一步，有个反直觉的结论：AI 没有把这门生意的总成本降下来，只是把成本从「实现」这个科目挪到了「定义」这个科目。定义成本一直都在，只是过去由人用常识免费抹平了——白板上画两笔、回头看一眼隔壁同事的屏幕、会上顺口问一句就算对齐了。代理既没有常识也没有茶水间，这笔钱现在必须显式支付，付的形式就是评审时间、更碎的工单、更早被拉进来的 UX，还有一堆以前没人愿意写的架构记录。有人在评论里观察到一件事，我印象很深：工具变快之后，「工程变简单」并没有体现为交付变快，而是体现为在制品变多。这个观察比原文本身更有信息量，因为它说的正是成本换了科目、但没消失。
拿抽象层上移来类比这一轮，可能是偷懒。高级语言替代汇编的时候，被露出来的是内存管理和类型系统，那是技术问题，能靠更好的工具解决；这一轮露出来的是评审归属和权限边界，那是责任问题，工具只能帮你想清楚，不能替你承担。形状像，性质不一定像。不过机制那一层我仍然觉得是同一件事：新的一层抽象，会把旧一层里靠默契维持的边界强制变成显式接口，而默契这东西在人和人之间传输极便宜，在人和代理之间传不了。所以这一轮真正的成本项，是「把默契写成接口」的那笔手工费。
接下来往哪走，能看到几条路。一条是 harness 留在公司内部，长成一种组织能力，外部工具退回零件角色——CI、沙箱、审计日志、上下文索引——卖零件不卖秩序；另一条是验证、权限、审计被托管化，harness 像当年的托管 CI 一样被商品化，你付费，别人替你定义什么叫做完；第三条最难堪，卡在中间：厂商卖半托管的秩序，团队一半靠外部一半自己补，两套完成标准并存，评审会开成两倍长。
我压第一条，压得比较重。理由是验证这件事的价值来自「对所验证对象的知识」，托管方案能覆盖的恰好是通用那截——跑测试、开沙箱、记审计，这些谁都能做，且正在被做便宜；剩下的那截，也就是这个团队的「完成」到底长什么样，绑死在具体的人和具体的项目历史里，跨公司不可迁移。控制供给的一方向需求侧扩张，这是过去几年反复出现的结构性路径，但扩张到组织内部通常会停住，因为组织不是市场，扩张进来也没法定价。
证伪条件挺明确：如果一年之内真出现一家厂商，能把一套「完成的定义」以配置的形式卖出去、跨团队复用，并且真的有人持续为别人的完成标准付钱，那我上面这整套推演就该扔掉——那一刻 harness 从组织能力变回了可采购的层位，护城河搬回供给侧，模型厂商向下整合的老剧本接着演。在此之前，我更倾向于相信 AI 释放出来的产能会继续以在制品的形式沉在管道里，而不是变成交付。