本章你将学到
- 计算型与推理型控制项的全面对比------速度、成本、确定性、能力边界四个维度的横向拉通；
- "方向 × 类型"四象限矩阵：前馈/反馈 与 计算/推理 交叉出的四类控制项及其典型实现；
- 一棵可直接照着走的选型决策树------面对一个质量问题，究竟该用哪种控制；
- Token 经济学：如何给一个控制项做成本核算，把"贵不贵"从感觉变成数字；
- 控制项组合的边际收益------为什么加控制到某个点之后反而有害（过度约束）。
从"有哪些控制项"到"该用哪个"
到本章为止，全书第二篇（核心构件）已经把控制项的"工具箱"摆满了：前馈的 Guides（第 6-9 章）、反馈的 Sensors（第 10-13 章），每一类下又分计算型与推理型。工具够多了，但一个真实项目里，你不可能把每一种都拉满------每个控制项都有搭建成本、运行成本、维护成本。于是真正的工程问题浮现出来：
面对一个具体的质量问题，我该动用哪一种控制项？投入多少？先做哪个？
本章就是回答这个问题的决策层 。它不引入新的控制项，而是给你一套成本模型和决策框架 ，把前面所有工具统一到一个可比较、可权衡的坐标系里。贯穿本章的是一条成本优先原则：先计算后推理、先前馈后反馈。
本章源级：本章为 B 级。它是本书对前 13 章内容的框架化整理与决策工具提炼；其中引用的 OpenAI 事实（成本偏好、最低限度门禁、廉价事后纠正等）为 A 级，已在前文标注来源。四象限矩阵、决策树、Token 经济学核算法为本书归纳的思维工具，非源文原有结构。
14.1 计算型 vs 推理型：全面对比
第 11、12 章分别讲透了两类传感器，第 9、8 章分别对应两类 Guide。现在把"计算型"与"推理型"这条根本分类轴，沿四个维度做一次横向拉通------这四个维度正是第 10 章评估传感器的那四把尺子：
| 维度 | 计算型控制项 | 推理型控制项 |
|---|---|---|
| 速度 | 毫秒到秒级，可进 Agent 内循环 | 秒到分钟级，受模型调用延迟制约 |
| 成本 | 极低，一次搭建后近乎零边际成本 | 高，每次运行都要花 token/时间 |
| 确定性 | 高，同输入同输出、无 flaky | 低，非确定，同输入可能不同判断 |
| 能力边界 | 只能处理"有确定判据"的问题 | 能处理语义、意图、品味等模糊问题 |
这张表浓缩了一条铁律：两类控制项是互补而非替代关系。 计算型又快又准又便宜，但只能覆盖"结构上可判定"的那部分问题；推理型能深入语义地带，但慢、贵、且会飘。任何一个成熟的 Harness，都是两者的分层组合------用密集的计算型控制项兜住绝大多数确定性问题，再用少量、精准投放的推理型控制项去补语义盲区。
这也直接推出了本章的成本优先原则的前半句：先计算后推理。凡是能被计算型控制项拿下的问题，就绝不要动用昂贵的推理型------把宝贵的推理预算，留给那些真正只有理解语义才能解决的问题。
举个"分层组合"的实感：守护"所有对外接口必须校验输入"这条要求。最底层，你用类型系统让请求体必须经过一个校验过的 schema 类型才能进入 handler（计算型前馈，非法状态无法表达）；再加一条 lint，禁止 handler 直接读取未经校验的原始 body（计算型反馈，确定拦截）；最后，对新增的关键接口，让安全评审 Agent 补一层"校验逻辑是否覆盖了业务上的边界"（推理型反馈，补语义盲区）。三层里，计算型挡住了绝大多数机械违规，推理型只需盯那少数需要理解业务语义的部分------这就是"分层组合"既省钱又可靠的原因。
14.2 "方向 × 类型"四象限矩阵
第 5 章立起了第一条根本分类轴------控制的方向 （前馈 Guides / 反馈 Sensors），§6.2 又补上第二条轴------执行的类型 （计算型 / 推理型）。把它们交叉，就得到一张能给几乎所有控制项归位的四象限矩阵：
| 计算型 | 推理型 | |
|---|---|---|
| 前馈（Guide） | 脚手架、代码生成器、类型系统、LSP、CLI 工具、codemod（第 9 章） | AGENTS.md、Skills、设计文档、示例代码（第 6-8 章） |
| 反馈（Sensor） | 类型检查、linter、测试、结构测试、变异测试、SCA（第 11 章） | 评审 Agent、LLM-as-Judge、语义级检测（第 12 章） |
这张矩阵有几个立刻可用的洞察：
- 左列（计算型）是地基：无论前馈还是反馈，计算型控制项都应当是你优先铺满的一层------它们便宜、可靠、可自动化。OpenAI 的整个体系正是架在密集的左列之上。
- 右上角（推理型前馈）最易被误用 ：写一堆冗长的 AGENTS.md 规则很容易，但它是"概率性说服"，可能被稀释、被忽略（第 6 章"过度指导等于没有指导"）。凡能从右上角降维到左列的规则（把一条约定写成一条 lint），都应当降。
- 右下角（推理型反馈）最贵：评审 Agent、LLM-as-Judge 都在这里，用时要精打细算（§14.4）。
- 一个问题常需多象限协同 ：比如"禁止跨层依赖"------用右上角的一句 AGENTS.md 说明意图、用左下角的结构测试机械强制、必要时用右下角的架构评审补语义盲区。好的控制不是选一个象限，而是让多个象限各司其职。
拿一个常见需求"确保数据库迁移安全"来归位，就能看到四象限如何各司其职：右上角，用 AGENTS.md 写清"迁移必须可回滚、禁止在迁移里删列"的意图（推理型前馈）；左上角，提供一个迁移脚手架模板，让 Agent 生成的迁移天然带上回滚段（计算型前馈）；左下角，用一条 lint / 结构测试拦住"迁移里出现 DROP COLUMN"（计算型反馈）；右下角，对每个迁移 PR 触发一次专门的"数据安全评审"，判断这次迁移在业务上会不会丢数据（推理型反馈）。四个象限从不同角度合围同一个风险，缺哪个都留下一道缝。
14.3 选型决策树
有了矩阵，就能给出一棵面对一个具体质量问题时照着走的决策树。核心是三连问，顺序体现成本优先。
不过在进入三连问之前，还有一个隐含的第零问：这个问题值得上控制项吗？ 判据是频率 × 严重度：一个只出现过一次、后果又轻微的问题，直接修掉就好，为它建控制项是赔本买卖；只有反复出现、或虽低频但后果严重（如丢数据、泄密钥）的问题，才配得上一个持续运转的控制项。第 5 章"同类问题出现两次就写一条 lint"里的"两次"，就是这个第零问的经验阈值。过了第零问，再走三连问：
-
能提前预防吗？ （前馈优先） → 如果这个问题可以通过"一开始就不让它发生"来消除（用脚手架固化正确结构、用类型系统让非法状态无法表达、用文档讲清意图），优先用前馈 Guide。预防永远比事后纠正便宜------这是成本优先原则的后半句"先前馈后反馈"。
-
能静态检查吗？ （计算型反馈优先） → 如果问题无法完全预防，但它有确定判据 （能被编译器、linter、测试、结构测试机械地判定对错），就用计算型传感器。快、准、便宜，能进内循环。第 5 章那条"同类问题出现两次就写一条 lint"正是这一步的操作指令。
-
需要语义判断吗？ （推理型反馈，但要算成本） → 只有当问题没有确定判据 、必须理解语义或意图才能判断（命名好不好、抽象合不合理、有没有过度设计、是不是 slop），才动用推理型传感器------并且要按 §14.4 算清成本、按第 12 章做好非确定性管理和风险分级触发。
这棵树的形状本身就是一条纪律：能预防的不留给检查，能计算的不留给推理。 只有被前两问"筛剩下"的问题，才值得花推理型控制项那份昂贵的预算。把这个顺序反过来（一上来就上评审 Agent），是最常见、也最烧钱的浪费。
举一个具体的走树例子。假设你发现 Agent 反复把日志写成了非结构化的 console.log：
- 第一问"能提前预防吗"？------部分能：把"用结构化日志"写进 AGENTS.md 与示例代码（前馈），但前馈是概率性的，不能保证绝不发生；
- 第二问"能静态检查吗"？------能！"是否使用了
console.log"有确定判据，一条 lint 规则就能机械拦住。到这一步就应停下------问题已被计算型控制项拿下； - 第三问根本不必问------不需要任何语义判断。
反之，如果问题是"这段代码是不是过度设计了"，前两问都会得到"不"（无法预防、无确定判据），才落到第三问的推理型传感器。同一棵树，不同问题，自然地被导向了成本高低截然不同的控制项。
再走一个不同走向的例子。假设问题是"Agent 可能把密钥硬编码进代码"：第一问"能预防吗"------能部分预防（提供从环境/密钥管理读取的脚手架与示例），但挡不住它偶尔图省事直接写死；第二问"能静态检查吗"------能，密钥往往有可识别的模式（高熵字符串、特定前缀），semgrep / 密钥扫描能确定性地抓，且该设成阻断档（第 13 章）。到这步问题已被拿下，同样不必进入第三问。可见"安全类"问题大多能被前两问解决，这也解释了为什么它们最该被机械化------既高频又高危。
回扣 Harness：这棵决策树是第 5 章"掌舵回路"在选型层的具体化。当你观察到一个反复出现的质量问题，不要凭直觉抓一个控制项就上，而是让它走一遍这三连问------它会把你导向那个"能解决问题、且成本最低"的控制项。
14.4 Token 经济学：控制项的成本核算
推理型控制项之所以要精打细算，是因为它的成本是真金白银且随规模线性增长的：每一次评审都是一次（或多次）模型调用，消耗 token 和时间。要把"贵不贵"从模糊感觉变成可决策的数字，需要一套简单的核算方法。
一个控制项的总成本，至少要算三笔账：
- 搭建成本（one-off）：写这条 lint 规则、这个 Skill、这个评审提示词、这套结构测试所花的一次性投入。计算型控制项这笔账通常偏高（要写代码），但只付一次。
- 运行成本（per-run）：每触发一次的开销。计算型的这笔账近乎为零；推理型的这笔账 = 模型调用的 token 数 × 单价 × 采样次数（§12.4 多次采样会翻倍），再加上延迟带来的循环拖慢。
- 维护成本（ongoing）：规则会过时、评审提示词会漂移、测试会 flaky。维护成本常被忽略，却是长期最沉重的一笔------一条误报率高的规则，会持续消耗人和 Agent 的注意力。
把这三笔账和"收益"（它能拦住多少、多严重的问题）一比，就能给每个控制项算出性价比。核算带来的关键决策有两个：
- 计算型 vs 推理型的取舍 ：一个问题如果又能写成 lint（搭建成本高、运行成本≈0）、又能靠评审 Agent 抓（搭建成本低、运行成本高），在高频触发的场景下，几乎总是应该付那笔一次性的搭建成本，把它做成计算型------因为运行成本会随调用次数被无限放大。这正是"让 Agent 自己写 linter"划算的经济学根据。
- 推理型的省钱手段 ：当一个问题确实只能用推理型时，§12.5 的三招（抽样、增量、按风险分级触发）本质都是Token 经济学的优化------把昂贵的 per-run 成本，只花在最该花的改动上。
举一个粗略的算账例子感受一下量级。假设某类"命名是否达意"的问题，既可用一条 lint（搜尾命名规范）部分拦截，也可用评审 Agent 全面判断：
- 方案 A（计算型）：写规则花半天（一次性），此后每次 CI 运行成本≈ 0；
- 方案 B（推理型）：无需开发，但假设每次评审消耗 5,000 token、一天触发 500 次，就是每天 250 万 token 的持续支出------而且随团队提交频率线性增长。
在这种高频、有确定判据 的场景下，方案 A 的一次性成本很快被方案 B 的日均支出超过。这就是为什么"让 Agent 自己写 linter"在经济上几乎总是划算的硬道理：你付一次搭建成本，换来无限次的零边际运行。反之，对于低频、无确定判据的问题（如"这个抽象合理吗"），搭建计算型控制项既不可能、也不划算，这时推理型的高 per-run 成本反而是可接受的。
第三笔"维护成本"最容易被低估，值得再算细一点。设想你上了一条正则写的命名 lint，它误报率有 20%------每五次报警就有一次是假的。Agent 每次撞上误报，要么被迫绕道、要么向人求助；人每次都要停下来判断"这次是真是假"。跑上几个月，这条规则消耗的人力与 Agent 轮次，可能远超它当初"半天搭建"的成本，甚至超过它拦下的真问题的价值。这时正确的动作不是留着它，而是要么把规则改准（降误报），要么干脆删掉------一条误报率高的控制项，是负资产。维护成本这笔账提醒你：控制项上线不是终点，它的性价比要被持续重算。
回扣 Harness：Token 经济学解释了 OpenAI"最低限度阻塞门禁 + 廉价的事后纠正"策略的成本逻辑：与其在每个 PR 上都跑一套昂贵的全量推理评审（高 per-run 成本 × 高频），不如放行大多数、再用便宜的事后纠正处理少数漏网------这在他们那套密集计算型地基之上是成本最优的。但请注意第 22 章 §22.6 的泛化警告：这套账只在特定的结构与工具投入下才算得平。
14.5 控制项组合的边际收益：过度约束的危害
最后一个、也是最容易被忽略的问题：控制项不是越多越好。 每加一个控制项都有边际成本，而它的边际收益是递减 的------当控制项密度超过某个点，再加控制不仅收益趋近于零，甚至会转为负收益。这就是"过度约束"。
过度约束的危害有几种典型表现：
- 拖垮自主循环：给 Agent 内循环塞进太多慢速传感器（如把该放集成后的变异测试提到提交前），会让快速反馈的地基崩塌（第 11 章）。
- 规则互相打架：前馈规则堆到几百条时，会出现相互矛盾、彼此稀释的情况------这正是第 6 章"过度指导等于没有指导"的成本侧翻版。Agent 的注意力被摊薄，反而每条都遵守得更差。
- 诱导规避行为：把一切都设成阻断门禁（第 13 章），会训练 Agent（和人）学会用更糟的 hack 去"过检"，制造出比原问题更隐蔽的新问题。
- 维护成本失控：每条规则都要维护，规则越多，知识库腐化（第 18 章）和误报累积的负担越重，最终没人再信任这些信号。
一个真实的过度约束现场：某团队为了"保证质量"，在提交前门禁里堆了单测、集成测试、E2E、变异测试、三个专项评审 Agent，外加两百多条 AGENTS.md 规则。结果 Agent 每改一行要等十几分钟反馈、评审意见彼此打架、规则多到它开始随机挑几条遵守。交付速度不升反降，质量也没变好------因为快速反馈的地基被压垮了，注意力被摊薄了。他们后来做的"减法"是：把慢速传感器移回集成后、把两百条规则砍到三十条最关键的、把三个评审合并成"按风险触发"的一个。控制项少了一多半，驾驭能力反而上去了。
正确的姿态是把控制项当作一项有成本的投资组合 来经营：持续问"这个控制项的边际收益，还配得上它的边际成本吗？"对收益已趋零的控制项，要像第 23 章"熵管理"那样主动做减法 ------删掉过时的规则、合并冗余的检查、把该降维的降维。驾驭的目标不是控制项数量最大化，而是"用最少的控制项，覆盖最关键的失效"。
到底该砍哪些控制项？三个可操作的信号：其一，长期零命中 ------一条规则跑了几个月从没抓到过真问题，它大概率在防一个不存在的风险；其二，高误报 ------像上面那条 20% 误报的 lint，噪声已盖过价值；其三，被系统性绕过------如果大家都学会了一个标准姿势去"骗过"某个检查，说明它拦的东西要么不该拦、要么拦错了地方。命中这三条中的任何一条，就该把这个控制项拉进"删除 / 改准 / 降维"的评审。定期做这件事，本身就是熵管理（第 23 章）的一部分。
回扣 Harness：这一节是对全书前半部分的一个重要平衡。前面章节一直在教你"如何增加控制"，本节则提醒：控制本身是有代价的，Ashby 定律要求的是"匹配"多样性，而不是"过量"堆砌。真正成熟的驾驭者，既懂得在关键处加控制，也懂得在冗余处做减法。
本章要点
- 两类控制项互补而非替代：计算型快/准/便宜但只能处理有确定判据的问题；推理型能进语义地带但慢/贵/会飘。任何成熟 Harness 都是二者的分层组合。
- "方向 × 类型"四象限矩阵给几乎所有控制项归位：左列（计算型）是应优先铺满的地基；右上角（推理型前馈）最易被误用、能降维的都该降；右下角（推理型反馈）最贵、要精算。
- 选型决策树三连问：能提前预防吗（前馈优先）→ 能静态检查吗（计算型反馈）→ 需要语义判断吗（推理型，且算成本）。能预防的不留给检查，能计算的不留给推理。
- Token 经济学核算三笔账：搭建（一次性）、运行（推理型 = token×单价×采样）、维护（长期最重）。高频场景优先付一次性成本做成计算型；推理型靠抽样/增量/风险触发省钱。
- 过度约束有害：边际收益递减甚至转负------拖垮循环、规则打架、诱导规避、维护失控。控制项是有成本的投资组合，目标是"用最少的控制覆盖最关键的失效"，冗余处要主动做减法。
- 贯穿原则：先计算后推理、先前馈后反馈------成本优先。
动手练习
- 给你的控制项画四象限。 把你项目现有的所有控制项（AGENTS.md 规则、Skills、linter、测试、评审流程......）逐一填进 §14.2 的四象限矩阵。看看你的分布是否"头重脚轻"------右上角堆了一大堆没人遵守的文档规则，左下角却几乎是空的？
- 拿一个真实问题走一遍决策树。 挑一个你最近反复遇到的质量问题，让它走一遍 §14.3 的三连问，得出应该用哪类控制项的结论。对比你此前"凭直觉"的处理方式，看决策树是否给出了更省成本的答案。
- 做一次过度约束体检。 审视你的 AGENTS.md 和 CI 门禁，找出至少一条"边际收益已趋零"的控制项（过时的规则、从没抓到问题的检查、误报率高到大家都忽略的告警），评估它的边际成本，并决定是删除、合并还是降维。
承上启下 ：至此，全书第一大部分------Harness Engineering 的核心概念与控制项体系 （第一、二篇及本章的决策框架）------就全部讲完了。你已经理解了什么是驾驭、有哪些控制项、以及如何在成本约束下选型。但所有这些控制项要发挥作用，都依赖一个前提：Agent 得能"看到"它需要的知识和上下文。 一个再好的规则，Agent 运行时读不到，就等于不存在。第 15 章「仓库即唯一事实来源」 将开启第三篇「知识库与上下文工程」，从一条冷峻的第一性原理讲起：Agent 运行时拿不到的信息，等同于不存在。