第十九章　范式转变：确定性工程到概率性工程

核心命题：软件开发正在经历一次真实的范式转变——但这次转变不是对过去的否定，而是在更高维度上对同一些永恒问题的重新面对。

序章以两匹马开篇——一匹无驭具、一匹有驭具——并提出贯穿全书的核心公式 $\text{Agent} = \text{Model} + \text{Harness}$。在经过十八章的展开之后，本章回到那个起点，追问一个被序章末句预埋的问题：当我们成为驾驭者，谁来驾驭驾驭者？这个问题的答案，构成了 Harness Engineering 在软件工程史中的位置坐标。

19.1 软件开发复杂性的两个时代

前一个时代的复杂性：确定性系统的规模复杂性——并发、容错、一致性；模块化、接口设计、文档。这些复杂性是可计算的、可分解的，在原则上可以被完全掌控。三轴约束中，质量是主要变量，时间和成本是次要考量。

当前时代的复杂性：概率性智能系统的不确定性复杂性——Agent 的行为是概率性的而非确定性的；目标需要被规范而非被编程；涌现行为无法被完全预测；系统的“正确性”本身是统计概念而非布尔值。更根本的变化：三轴约束从各自独立变成了深度耦合。

软件工程师的工作，从“写出正确的指令”转变为“设计让正确行为在三轴约束下成为最可能行为的环境”。这个转变不只是工作内容的迁移，更是工程师与所造之物之间关系的重定义——从“作者与作品”变为“驭者与马匹”，从“规约的实现者”变为“分布的塑形者”。

19.2 永恒不变的工程原则

工程原则的持久性不是惯例，而是有结构性根源的：这些原则是对工程的不变约束的响应——复杂性总是超过工程师穷举的能力；资源总是有限；系统总是以未被预见的方式失效。这些约束不随范式转变而消失，因此应对它们的原则同样不消失。但“不消失”不等于“不变”——在概率性范式下，每条原则都在其应用形式上发生了深化：不只是换了一种表达，而是揭示了在确定性范式下被遮蔽的维度。

抽象与封装：在确定性系统中，抽象隐藏了实现细节，但行为仍然完全可规约——你可以阅读源代码来理解它做什么。在概率性系统中，抽象变成了认识论必然性：LLM 的内部推理过程不可审计，System Prompt 是你能拥有的唯一接口层。抽象不再是便利，而是工程师与系统之间唯一可能的关系形式。

反馈与迭代：在确定性系统中，迭代趋向一个固定点——测试全部通过，版本发布。在概率性系统中，反馈不收敛于终点，而是持续校准行为分布：Hook 数据告诉你分布的当前形状，迭代是使分布向期望空间移动的持续过程。这是对“循环”概念本身性质的改变——从有终点的修复循环，到无终点的分布校准循环。

最小权限原则：在确定性系统中，这是安全最佳实践。在概率性系统中，它成了行为可预测性的结构性条件：权限集越宽，Agent 的可达状态越多，行为分布越难以塑形。最小权限不只是降低风险，更是使 Harness 的约束设计在计算上可行——一个操作集无限大的 Agent 的行为分布，在理论上是不可被约束的。

关注点分离：在确定性系统中，这是架构整洁的便利。在概率性系统中，三流分离（数据流/控制流/反馈流）是调试的认识论前提：你无法单步追踪 LLM 的推理，只能通过观察各层的输入输出来归因。没有分离，“是信息错了、决策错了、还是纠正缺失”这个问题就无法被系统性地回答。

测试驱动：在确定性系统中，测试规约期望行为，通过即为正确。在概率性系统中，评估是对分布的持续采样——它告诉你当前分布大概是什么形状，但永远无法穷举。这使评估驱动的设计循环从“写测试→通过测试→完成”变为“设计评估→观察分布→调整约束→再评估”的无限改进过程。

这五条原则的深化不是抽象的——它们各自落在 Harness 的某个具体构件上，构成了“原则—构件”的承载关系。Harness 的五构件并非随机选择，而是这五条永恒原则在概率性范式下的物质载体：

永恒工程原则	在 Harness 中的承载构件	承载关系
抽象与封装	System Prompt（第七章）	System Prompt 是 LLM 不可审计的内部推理与外部世界之间的唯一接口层——抽象在此从“便利”变为“必然”
反馈与迭代	Hook（第十一章）+ 评估系统（第十二章）	Hook 是无终点分布校准循环的执行节点；评估系统是观察分布形状的传感器
最小权限	Tool 权限治理（第十章）	Tool 接口是 Agent 与真实世界的边界；权限分级、副作用分类、不可逆操作的拦截在此落地
关注点分离	三流分离架构（第二章）+ Plan（第九章）	数据流（Context）/ 控制流（Plan）/ 反馈流（Hook）的物理分离，是调试归因的前提；Plan 进一步将“目标流”从控制流中分离出来
测试驱动	可观测性与评估（第十二章）+ Skill（第十三章）	评估系统提供持续采样的工具；Skill 将采样得到的有效模式沉淀为可复用知识

这张映射表的意义不是符号学的归类，而是工程上的承诺：当工程师面对一个新的 Harness 设计任务时，每条永恒原则都对应一个具体的构件设计入口——你不必从零思考“如何在概率性系统中应用最小权限”，而是直接进入 Tool 权限治理的设计空间。这五条原则的持续性，提供了一条穿越范式转变的工程连续性——它们是学习 Harness Engineering 时可以依赖的先验知识。下一节将分析：即便这些原则都延续下来，仍然存在什么是在软件工程史上真正前所未有的东西。

19.3 真正新鲜的是什么

“设计让正确行为成为吸引子”——这句话在软件工程史上找不到先例，因为它描述了一种根本不同的工程对象。

在确定性工程中，“正确”是一个布尔属性：函数要么返回了规范规定的结果，要么没有。工程师的任务是规定正确行为，然后验证实现是否满足规定。正确性来自规约（Specification），工程是规约的实现。

在概率性工程中，“正确”是一个分布属性：Agent 的输出在某个概率分布上，工程师试图使分布的高概率区域与“好的输出”空间重合。工程师的任务是设计一个约束空间，使好的输出在其中具有更高的概率密度。正确性来自环境设计，工程是概率分布的塑形。

这种转变与以下领域更接近，而非与传统软件工程接近：

• 生态工程：设计使生态系统朝健康状态演化的条件，而非规定每个物种的行为
• 制度设计：设计使个体理性选择收敛到集体良好结果的激励结构，而非命令每个参与者
• 城市规划：设计使期望行为模式成为最省力路径的空间结构，而非控制每个居民的移动

Harness Engineering 工程师因此第一次需要同时具备：写代码的能力（实现机制）、认知科学的直觉（理解 LLM 推理模式）、控制论思维（设计收敛的反馈回路）、制度设计的视角（让好的输出成为系统的自然倾向）。这四种能力的组合，在软件工程史上从未被同时要求过。

而当工程从“开发代码”变为“塑造分布”时，一个紧迫的工程问题随之浮现：塑造分布这件事本身，在实践层面究竟难在哪里？它的困难不在于 System Prompt、Hook、或 Tool 等组件设计使用。它的困难在于，工程师必须先回答一个在确定性工程中从未存在过的问题：“什么叫对”。

19.4 落地之难：在概率分布上重新定义「确定性」

第一层：从分布到产品行为的鸿沟

认识到“工程对象是分布”还不足以指导实践——因为用户从不直接感知分布，他们感知的是产品行为。在确定性工程中，“正确”由 Spec 给出，是外部输入；工程师的职责是实现：给定规约，写出满足规约的代码，测试验证，完成。“什么叫对”这个问题不属于工程师，它属于产品经理或需求文档。

在概率性工程中，这个分工瓦解了。没有任何 Spec 能穷举一个语言模型在所有输入上的期望输出；没有任何测试集能穷举分布的全貌。工程师必须自己在分布上定义“好的输出空间”——这不是难度的升级，而是工程对象本身的转移：你不再是一个规约的实现者，你同时是规约的制定者。把一个概率性系统的行为规约写清楚，比写确定性代码难得多——原型阶段“看起来对”可以被接受，生产化却必须给出可被测量、可被追溯、在边界条件下仍然成立的定义。这个定义动作，是 Harness 工程化进程中真正的瓶颈工序。

第二层：四个抽象层的承诺强度

但仅仅“定义确定性”还不够——工程师必须进一步追问：在哪一层提供什么样的确定性？ 不同抽象层应许的承诺强度根本不同；混淆层级，是 Harness 项目失败的常见根源。以下四层是一个可操作的分析框架：

• 接口契约层（API schema / Tool 调用格式）：此层可以提供强确定性——格式合法、参数类型正确、调用幂等可重放。这是机器可验证的部分，与确定性代码的保证性质相同。§10.2 的最小权限框架和副作用分类，正是在此层为 Tool 接口立约。

• 副作用层（Tool 的可逆性、权限边界）：此层提供边界确定性——某些操作绝不发生（不可逆操作必经审批或被 Pre-Hook 拦截），但不保证发生的操作都在语义上“正确”。这是否定式的承诺：承诺系统不会越过某条线，而非承诺它一定走到哪里。

• 行为分布层（Agent 决策、内容生成）：此层只能提供统计确定性——在期望分布下，高概率区域的输出满足某质量阈值，但单次输出不可预先保证。评估系统（§12.1）是持续观测这一层分布形状的传感器；Plan（§9.3）通过把“将要做什么”可见化，使分布的局部行为具有可解释性。

• 最终交付层（用户感知到的产品行为）：此层的目标是把前三层的异质承诺重新合成为“工程意义上足够确定”的产品体验——通过 Hook 的实时拦截（§11.3）、评估系统的持续采样反馈、以及 Human on the Loop 的战略节点介入（§15.3），将统计确定性逐层补强，使用户感知到的行为稳定在可接受的包络之内。

这四层框架的核心教训是：对行为分布层许诺接口契约层强度的“确定性”，是过度承诺；对接口契约层只提供统计确定性的保证，是设计退化。工程师必须在每一层找到与其本质相符的确定性形式，并在向上合成时明确每层承诺的边界在哪里。

第三层：阶段坐标——何时承诺什么

第二层的四层框架回答了“在哪一层给什么承诺”，但它是静态截面：同样的四层，在项目生命周期的不同阶段，合理的承诺强度优先级截然不同。Harness 工程师必须同时驾驭的第三个坐标，是时间——即当前处于哪个阶段，决定了哪几层的承诺是底线、哪几层的承诺可以暂时模糊。

• 原型期：副作用层是绝对底线——避免灾难性操作是任何阶段都不能跨越的红线；但接口契约层可以粗糙（schema 可变），行为分布层只做弱评估或不评估，最终交付层尚不存在。这一阶段的核心任务是探索“什么场景是可能的”，过早在行为分布层做强承诺，会迫使工程师在尚未理解场景边界的情况下先锁定产品形态。

• 内测期（灰度期）：接口契约层与副作用层先行收紧，形态趋于稳定；行为分布层开始建立基线评估指标，真正测量分布的形状而非依赖直觉；最终交付层在局部用户群内形成可观测的包络。此阶段的重点是发现生产前无法预见的场景，并把发现的边界补入四层约束。

• 生产期：四层全部必须给出明确承诺。最终交付层升格为整体对外契约——用户已经形成行为预期，任何退化都有实际代价。此时行为分布层的统计确定性必须是被实测支撑的，而非依赖原型期的直觉估计。

• 演化期：每次场景拓展，行为分布层和最终交付层必须重新对齐。分布漂移（新用户群、新使用模式）和用户预期变化，都会让原先成立的承诺悄然失效。演化期最危险之处，在于工程师往往以为“系统没改、承诺还在”，却没意识到输入分布已经变了。

四个阶段不是线性升级，而是对同一套四层框架的不同加载方式。这就是为什么“在什么时间、在哪一层、提供什么样的确定性”是同一个判断的三个坐标，缺一不可——三坐标的组合决定了一条具体边界的正确实施形式。

在这个框架下，Harness 项目有两种典型失败模式，与第二层的“层级错配”诊断形成对仗：

提前收紧：在原型期对行为分布层做强承诺——在尚未探明场景边界时就锁定了对分布的具体要求，扼杀了探索空间，并使后续发现的真实场景与已承诺的行为形态之间出现难以弥合的裂缝。

延迟承诺：进入生产期才开始认真考虑接口契约层与副作用层的硬约束——此时用户使用模式已经被早期粗糙实现锁定，修改成本极高。最直观的表现就是 Harness 项目在原型期总是推进飞快，到生产化时总是陷入泥潭：原型期只需要“看起来对”，这个门槛用直觉满足即可；到生产期，才发现必须把“什么叫对”重新翻译成每一层都能消费的具体约束——而此时回头补的代价，远超早期就做对的成本。

既然定义“确定性”已经如此之难，那么定义“确定性”的工程师本身，偏差又由谁来纠正？这个递归问题，构成了终章必须正面回答的最后一问。

19.5 终问：谁来驾驭驾驭者？

古罗马诗人尤维纳利斯有一句名言：Quis custodiet ipsos custodes——谁来看管看管者自身？这是人类制度设计最古老的问题之一。任何监督机制都面临这个递归困境：如果 A 监督 B，谁来监督 A？如果 Harness 约束 Agent，谁来约束 Harness 的设计？

这个问题有两种错误的回答方式。

错误回答一：找到一个足够可信任的监督者。这条路的终点是单点失效——任何对单一主体的信任依赖，都会成为整个系统崩溃的根源。航空事故调查反复证明：凡是依赖“最有经验的机组不会犯错”的设计，最终都在统计意义上失败了。

错误回答二：建立无穷的监督链。无穷递归不可操作，只会把问题推迟而非解决。

人类在复杂系统治理上积累了数百年经验，实践得出了第三条路：不是寻找终极可信任者，而是设计使监督本身具有自我纠错能力的结构。航空工业的多重独立检查清单不是找到了不会犯错的飞行员，而是设计了使人为失误可被及时发现和中断的程序；核电站的多道独立安全屏障不是找到了完美的运营者，而是设计了使任何单一故障都无法酿成灾难的架构；科学共同体的同行评审不是找到了全知的裁判，而是设计了使错误随时间浮现的集体过滤机制。

这些制度的共同结构是：分散性、可见性、问责性。没有单一权威，所有决策暴露在可见范围内，偏差产生可追溯的后果。

Harness Engineering 在实践中面临的是同一个根本问题，因此可以用同样结构的解答。但这三个条件不能停留在抽象层——它们必须被翻译为具体的工程实施。下面分别展开：

分散性的工程实施：

• 构件级分散：System Prompt 层定义问题域、Plan 层分解任务、Tool 层执行操作、Hook 层验证副作用——同一个错误必须穿透至少两层才能造成实质损害（参见第二章三流分离与第十一章 Pre-Hook / Post-Hook / Stop Hook 的分层）
• 权限分级：Tool 按副作用可逆性分类，不可逆操作（删除、外部 API 写入、资金流动）需要 Pre-Hook 显式拦截或人类批准（第十章 §10.2 的副作用不可逆性与最小权限框架）
• 设计权威分散：Harness 的不同构件由不同角色维护——System Prompt 由产品负责人、Tool 接口由工程师、评估指标由 QA、价值边界由治理委员会——任何单一角色无法独自重构 Harness 的全貌

可见性的工程实施：

• Plan-before-Act 透明化：Agent 在执行任何不可逆操作前必须先生成可读的 Plan，使“将要做什么”在“已经做了什么”之前暴露给人类审视（第九章 §9.3）
• 结构化日志与 Trace：每一次 Tool 调用、每一次 Hook 触发、每一次 Context 压缩都产生结构化记录，构成可重放的执行轨迹（第十二章 §12.3 可观测性三层设计：事件层、聚合层、告警层）
• 评估指标的对外暴露：质量指标不只是内部仪表盘，而是对人类决策者持续可读的工程读数——使“系统当前在何种工作点上”不依赖直觉判断

问责性的工程实施：

• 升级链：Hook 检测到高风险操作或检测器不一致时，按预定义路径将决策权升级到人类（第十一章 §11.5 的 Stop Hook 与升级协议）
• Stop Hook 验收：里程碑节点处的强制人类验收——不是“可选审查”而是“无法绕过的验收门”
• Human on the Loop 节点：Agent 主导执行，人类在战略节点上判断方向、在价值边界上仲裁（第十五章 §15.3）——这与 Human in the Loop 的区别在于人类不在每步介入，而是在结构化设计的关键点上介入

这三组实施措施合起来，给“谁来驾驭驾驭者”这个根本问题一个工程层面的有限答案：不是找到一个完美的驾驭者，而是设计一个 Harness 体系，使它的偏差可被发现、使纠正成本低于沉默的代价、使人类判断的介入接口始终存在。这个体系永远不会完美，但它可以是自我纠错的——而自我纠错，是任何有限系统在无限时间中的唯一可持续属性。

回到两匹马

序章以两匹马开篇：一匹无驭具的千里马在原野上奔跑（壮观，无用），一匹配备完整驭具的马在精确轨道上完成了原本需要一支团队才能做的工作。这个隐喻在全书展开后积累了四个层次：

• 第一层：驭具不是能力的对立面，而是能力转化为可靠行动的条件。
• 第二层：驭具不是静态装置，而是持续校准的反馈系统——驭者在马的整个生涯中不断调整缰绳的张力。
• 第三层：当多匹马协作时，问题从“如何驭一匹马”扩展到“如何设计马匹之间的协作秩序”——驭具设计必须服从更大的制度结构。
• 第四层：驭者本身也是有限的——会疲倦、会失误、会被替换。可持续的驭马系统必须使任何单一驭者的失误都不会成为灾难；驭者是可被监督、可被替换、可被追问的角色，而非中心。

序章末句问：“当我们成为驾驭者，谁来驾驭驾驭者？”在终章的视角下，这个问题的答案不是“找到一个超级驾驭者”，而是让驾驭这件事本身具有自我纠错能力——通过分散性、可见性、问责性，使任何驾驭者的偏差都能被系统性地发现和纠正。

这就是为什么 Harness Engineering 不只是关于 Agent 的工程，更是关于人类如何与一类全新的智能系统建立可持续关系的工程。Agent = Model + Harness 这个公式，在终章的回望下，可以被读出更深的含义：Model 是被压缩的人类智能；Harness 是把这份智能解压到真实世界中的装置；而驾驭这套装置的我们，最终也必须把自己置于一套更大的、可被检验的结构之中。

---

尾页题词

驭具不是牢笼，而是让马真正成为马的条件。

---