本章你将学到
- Harness 一词最凝练的定义------一个只有两项的加法公式
Agent = Model + Harness，以及它为什么能框住整个领域；- 这个定义为什么"过于宽泛"，又该如何针对"编码代理"这一边界上下文把它收窄；
- 三层同心圆模型：被驾驭的模型、厂商内建的 Harness、你能亲手构建的外层 Harness------分清你的主战场在哪一层，哪一层你改不了、哪一层你说了算；
- 为什么"harness"是个多义词，在 Agent harness、测试夹具（test harness）、评估框架（evaluation harness）三种语境下含义不同，读文献时如何不被绕晕；
- 外层 Harness 存在的两大目标（前馈提高一次做对概率、反馈自动纠错），以及它顺带带来的三个副产品；
- Harness Engineering 不是什么------四条最常见的误解，逐一破除；
- 它与上下文工程、平台工程、DevEx、SRE、质量工程等相邻学科的关系图谱与分工边界。
给"驾驭"下一个精确的定义
前三章我们一路铺垫：软件工程正在经历第三次范式跃迁（第 1 章），编码代理的内部机制与能力边界已被看清（第 2 章），而 AI 生成代码的三重信任壁垒------非确定性、无组织上下文、无真正理解------让"直接放手让 Agent 干"变得不可行（第 3 章）。所有这些线索都指向同一个答案：我们需要在模型的外部，构建一套系统，去系统性地补偿模型的固有不足。 这套系统，就是 Harness；构建它的学问，就是 Harness Engineering。
但"Harness"这个词本身太宽泛了。如果不加界定，它几乎可以指"模型以外的任何东西"，大到无从下手。本章的任务，就是把这个宽泛的词，收窄成一个精确、可操作、并且贯穿全书的定义。我们会先给出一个公式，再用一张同心圆图把它结构化，接着厘清术语的多义性，说清它的两大目标，破除四条常见误解，最后画出它与相邻学科的关系图谱。读完本章，你手里就有了全书最重要的一张"地图与坐标系"。
本章源级：本章为 A/B 混合级。核心公式 Agent = Model + Harness、术语的多义性辨析、前馈/反馈两大目标均出自 Böckeler 框架文的一手记载（A 级）；三层同心圆图、"不是什么"四条辨析、相邻学科关系图谱为本书归纳的框架工具（B 级），非源文原有结构。
4.1 核心公式：Agent = Model + Harness
Böckeler 在框架文里给出的定义，简洁到近乎苛刻：
"harness"一词，已经成为"AI 代理中除模型本身之外的一切"的简称------也就是说，Agent = Model + Harness。
这个公式看起来简单，却做成了一件至关重要的事：它把"Agent"这个含混、笼统的整体，切成了两个可以分别对待、分别评估、分别投资的部分。
公式的两个组成部分
- Model（模型） ：那个以 token 思考、非确定性的下一词预测器（第 2 章讲的正是它）。它是被驾驭的核心，同时也是我们在工程实践中无法直接改造 的部分------你不训练它、不微调它的权重，你只是使用它。对绝大多数团队而言，模型是一个"给定的、外部的、黑盒的"输入。
- Harness（马具 / 驾驭系统） ：模型之外的其余一切------系统提示词、上下文检索机制、可调用的工具、规则文件、知识库文档、测试、linter、类型系统、评审流程、沙箱、编排逻辑......凡是"包裹在模型外面、影响它如何工作"的东西，统统属于 Harness。
这个切分为什么是"战略性"的
这一刀切下去的价值，不在于分类学上的整齐，而在于它重新定位了工程杠杆的落点。
回顾第 3 章的结论：模型的三重信任障碍，源于它的固有机制，无法从模型内部根除。既然如此，那么我们所有能施加影响的工程手段，就都落在了公式"+"号的右边------Harness 这一侧。换句话说：
既然改不了"Model"，那就把全部精力投在"Harness"上。Harness Engineering，就是系统地设计、构建、演进这个 Harness 的学问。
这也是为什么本书几乎不讨论"如何训练一个更好的模型"------那是模型厂商的战场；本书讨论的，是在给定模型的前提下，如何通过经营它外部的一切，让它可靠地产出好结果。
一个必要的提醒：这个定义"过于宽泛"
Böckeler 本人也坦承，"Agent = Model + Harness"是一个**"非常宽泛的定义"------"模型之外的一切"几乎无所不包，宽泛到难以直接指导实践。因此，她建议针对具体的代理类型**去收窄它。
本书正是这样做的：我们把讨论限定在"编码代理（coding agent）"这一个边界上下文里。也就是说，本书谈的 Harness，特指"为编码代理构建的驾驭系统"------它服务于写代码、改代码、测代码、评审代码这一类软件工程任务。这个收窄非常关键，它让"模型之外的一切"这个空泛的集合，变成了一组具体、可枚举的构件（规则、Skills、测试、linter......），也正是这个收窄，引出了下一节的三层结构。
4.2 Harness 的三层同心圆
"模型之外的一切"仍然太笼统------它把"你能控制的"和"你控制不了的"混为一谈。Böckeler 用一张三层同心圆 图把它结构化。这张图是全书反复引用的锚点图，请务必记牢它的每一层。
markdown
┌───────────────────────────────────────────────┐
│ 最外层：用户外层 Harness（User Harness） │ ← 本书主战场
│ 你为自己的系统亲手构建的：规则文件、知识库文档、 │
│ Skills、自定义 linter、类型定义、测试、评审 Agent、 │
│ 脚手架、沙箱、CLI 工具...... │
│ │
│ ┌─────────────────────────────────────────┐ │
│ │ 中间层：厂商内建 Harness（Builder Harness）│ │
│ │ 编码代理产品出厂就自带的：系统提示词、 │ │
│ │ 代码检索机制、上下文管理、编排系统...... │ │
│ │ │ │
│ │ ┌───────────────────────────────────┐ │ │
│ │ │ 最内层：模型（Model） │ │ │
│ │ │ 被驾驭的最终对象------你选它、用它， │ │ │
│ │ │ 但不训练、不改造它 │ │ │
│ │ └───────────────────────────────────┘ │ │
│ └─────────────────────────────────────────┘ │
└───────────────────────────────────────────────┘最内层------模型（Model）
被驾驭的最终对象。你选择 它（用 GPT-5 还是 Claude？）、使用 它，但你不改造它。它的能力和缺陷，构成了整个系统的地基与天花板。所有外层的努力，最终都作用在这个非确定性的核心上。对它，你唯一的"控制"就是选型------而选型本身也是一种驾驭决策（第 9 章 §9.5 会讲"选型即驾驭"）。
中间层------厂商内建 Harness（Builder Harness）
这是编码代理产品在出厂时就已经内建的那部分驾驭。当你用 Codex、Claude Code、Cursor 时，你拿到的从来不是"裸模型"，而是"模型 + 一层厂商已经包好的 Harness"。这一层包括：
- 系统提示词：厂商预设的、塑造 Agent 基本行为和人格的指令；
- 代码检索机制：产品自带的、把代码库内容搬进上下文的检索策略；
- 上下文管理与编排系统：如何管理上下文窗口、如何在多步之间编排 Agent Loop（第 2 章 §2.2）。
第 2 章 §2.4 讲的那些"标准部件"（工具、Agent Loop、上下文管理），大多属于这一层。对这一层，你通常改不了它 ------它是产品的一部分。但你必须理解它，因为它塑造了 Agent 的默认行为，是你外层构建的地基。选择不同的编码代理产品，本质上就是选择不同的中间层 Harness。
最外层------用户外层 Harness（User Harness）
这是编码代理产品特意留给你 去构建的部分------专门针对你自己的用例、你自己的代码库、你自己的团队约定。Böckeler 明确指出：编码代理"也为它们的用户提供了大量能力，去构建专属于自身用例的外层 Harness"。
这一层包括本书后续要讲的几乎所有具体构件：AGENTS.md 与规则文件（第 7 章）、Skills（第 8 章）、计算型工具与类型系统（第 9 章）、各类传感器与测试（第 10--13 章）、知识库（第 15--18 章）、架构约束（第 19 章）、沙箱（第 25 章）......
这最外层，就是本书的主战场。 厘清这三层的现实意义在于一条纪律：
不要把精力浪费在你控制不了的地方（模型、厂商内建），而要全力经营你真正能掌控的最外层。
当 Agent 表现不好时，新手的第一反应往往是抱怨"模型不行"（最内层，你改不了）或"这个工具太笨"（中间层，你也改不了）；而 Harness 工程师的第一反应是问："我的最外层还缺了什么？"------这正是 OpenAI 团队那句"失败时的解法几乎从来不是'再努力一点'"的深层含义。
回扣 Harness：这三层结构也呼应了第 1 章"三代范式层层递进、后者包含前者"的思想------外层 Harness 包裹着厂商内建 Harness，厂商内建 Harness 又包裹着模型，层层向内驾驭。你在最外层投入的每一分，最终都会穿透中间层，作用到最内层那个非确定性的模型上。
4.3 术语的边界上下文：同一个词的不同含义
"Harness"是个多义词。Böckeler 特意强调："harness"这个词，在不同的边界上下文（bounded context）里含义不同。 读文献、读别人的博客、甚至团队内部讨论时，若不加区分，极易发生"鸡同鸭讲"。至少有三种常见用法必须分清：
| 用法 | 含义 | 本书是否指它 |
|---|---|---|
| Agent harness | AI 代理中除模型之外的一切（Agent = Model + Harness） |
✅ 本书全程指这个 |
| Test harness（测试夹具 / 测试脚手架） | 软件测试中，为运行被测代码而搭建的驱动程序、桩件、夹具环境------一个历史悠久的通用软件工程术语，与 AI 毫无关系 | ❌ 传统含义，切勿混淆 |
| Evaluation harness（评估框架） | 用于系统性评测一个模型或系统能力的测试装置（例如 OpenAI 案例中，Agent 自己生成的用来评估产品质量的"评估框架"） | ❌ 又一个独立含义 |
三者的共同内核与关键区别
这三个用法之所以都叫"harness"，是因为它们共享同一个隐喻内核 ：harness = "一套支撑与约束的框架"（就像马具是套在马身上的支撑与约束装置）。但它们所指的具体对象截然不同：
- Agent harness 约束和支撑的是"模型"；
- Test harness 约束和支撑的是"被测代码"；
- Evaluation harness 约束和支撑的是"被评估的系统"。
本书的用词约定
为避免混淆，本书立下一条用词约定，请记住：
本书凡出现"Harness"而不加任何限定词，一律指 Agent harness------即三层同心圆里那个"模型之外的驾驭系统"。当涉及"test harness""evaluation harness"时，本书会加上完整限定词，此时请切换到对应语境去理解。
这不是咬文嚼字。术语边界上下文的混淆，是团队讨论 Harness 时最常见的内耗之源------一个人在说"测试脚手架"，另一个人在说"Agent 驾驭系统"，第三个人在说"模型评估框架"，三人却用着同一个词"harness"，讨论了半天才发现根本不在一个频道上。厘清这一点，本身就是一种前馈。
4.4 外层 Harness 的两大目标
一套构建良好的外层 Harness，到底要达成什么？如果说不清目标，就无法判断某个具体投入值不值。Böckeler 给出了极其明确的两个目标 ，外加一组副产品：
一套构建良好的外层 harness，服务于两个目标：它提高 Agent"一次就做对"的概率；它提供一个反馈回路，在问题到达人类眼前之前，就自动纠正掉尽可能多的问题。 最终，它应当降低审查负担、提升系统质量，并顺带减少一路上被浪费的 token。
这段话里藏着整个领域的两条经纬线，我们逐一拆开。
目标一：提高"一次做对"的概率（前馈 / Feedforward）
在 Agent 行动之前，就塑造它的行为，让它第一次尝试就更可能产出好结果。
- 它作用在"事前"：不是等错误发生了再补救，而是通过预先设定的引导，从源头降低错误发生的概率。
- 它改变的是"概率"而非"确定性"：即使有了完善的前馈，模型仍可能出错------前馈只是把"做对"的概率往上抬。
- 它的具体手段：规则文件、知识库文档、Skills、类型系统、脚手架、LSP......这些都是第二篇"Guides"（第 6--9 章）的主题。
前馈对应的直觉是：与其事后返工一百次，不如事前把路修对。
目标二：让问题在到达人眼前被自动纠正（反馈 / Feedback）
在 Agent 行动之后 ，观察它的产出，驱动它自我修正，把尽可能多的问题挡在人类视线之前。
- 它作用在"事后"：观察实际产出，与期望对比，把偏差信号回灌给 Agent。
- 它的核心价值在"自动纠正" ：注意 Böckeler 的措辞是"在问题到达人类眼前之前"------反馈的首要目标不是"通知人类来修"，而是"让 Agent 自己修掉"，从而节省最稀缺的人类注意力（第 3 章监督成本悖论）。
- 它的具体手段：测试、linter、类型检查、静态分析、评审 Agent......这些是第二篇"Sensors"（第 10--13 章）的主题。
两大目标是全书的经纬线
这两个目标，正是第 5 章控制论"前馈 + 反馈"的直接对应。 全书讲的每一个具体技术，你都可以对它问一句："它服务于哪个目标？是在事前提高一次做对的概率（前馈），还是在事后自动纠错（反馈）？" 这个提问，会成为你归类和评估任何 Harness 构件的第一把尺子。
三个副产品
除了两大核心目标，一套好的 Harness 还会顺带带来三重收益。注意 Böckeler 用的是"最终它应当（ultimately it should）"------这些是目标达成后自然溢出的结果，而非需要单独追求的目标：
- 降低审查负担（reduce review toil）------直接回应第 3 章的"监督成本悖论"：问题被前馈+反馈自动纠正得越多，最终需要人类亲自审查的就越少，人类的注意力被解放出来投向更重要的地方。
- 提升系统质量（increase quality） ------前馈引导 + 反馈纠错的合力，让代码库的整体质量随时间上升而非衰减。这是对抗"AI 生成代码导致代码库腐化"这一普遍担忧的正面回答（第 23 章熵管理会深入）。
- 减少 token 浪费（fewer wasted tokens）------Agent 少走弯路、少返工、少在错误方向上空转，就少烧 token。这既是成本问题，也是效率问题（第 14 章 §14.4 会把 token 经济学量化）。
回扣 Harness ：请注意两大目标与三副产品之间的因果链------你直接投资 的是前馈和反馈两个目标，而审查负担、质量、token 这三者是结果指标。这条因果链在第 35 章"度量体系与投资回报"里会变成可测量的量：你不能直接"提升质量"，但你可以增加一个传感器（投资反馈），然后观测质量指标是否改善。
4.5 Harness Engineering 不是什么
定义一个概念，同样要划清它的边界------说清它不是 什么，往往和说清它是什么同样重要。以下四条是关于 Harness Engineering 最常见的误解，逐一破除。
误解一：它不是提示词技巧
很多人第一反应是把 Harness Engineering 等同于"把提示词写得更漂亮"（prompt engineering）。这是把整片森林误认成一棵树。
- 提示词优化只影响单次交互，无法沉淀、无法复利------你这次把 prompt 调好了，下次换个任务、换个人，一切归零（第 1 章 §1.2 论证过）；
- 而 Harness 是可版本化、可测试、每次运行都自动生效的持久系统------它写进仓库、进入代码评审、随代码库一起演进。
二者是包含关系而非同一层次：提示（尤其是系统提示词）只是前馈的一小部分。把 Harness Engineering 缩小成"写好 prompt"，会漏掉它 95% 的版图。
误解二：它不是"选一个更强的模型"
这是最诱人、也最危险的误解。当 Agent 表现不好，"等下一代更强的模型就好了"是一种极具吸引力的偷懒。
但第 3 章已经论证：三重信任障碍源于模型的固有机制 ------换一个更强的模型，只能缓解 这些问题，无法根除非确定性、无法凭空获得你团队的组织上下文、也无法让它真正"理解"而非"预测 token"。OpenAI 团队的经验一针见血：
失败时的解法"几乎从来不是'再努力一点'（try harder）"------而是回过头去问"缺了什么能力，如何把它对 Agent 变得既可理解又可执行"，然后去补系统的能力。
模型再强，也替代不了 Harness。恰恰相反，模型越强，一个好 Harness 能撬动的杠杆就越大------因为强模型能更好地利用你提供的前馈和反馈。
误解三：它不是"又一套 CI 工具链"
有经验的工程师容易走向另一个极端：把 Harness 等同于"CI/CD 流水线"。这个误解更接近真相，但仍然严重低估了 Harness 的范围。
CI/CD 只是反馈体系的一部分，而且偏计算型。Harness 比 CI 宽得多，它至少多出三块 CI 覆盖不到的版图：
- 行动前的前馈引导（规则、Skills、类型、脚手架）------CI 完全管不着，它只在代码写出来之后才介入；
- 面向 LLM 消费而设计的信号 （第 13 章）------传统 CI 的报错是写给人 看的，而 Harness 里的信号首先是写给 Agent 看的、要能驱动自我纠正的；
- 推理型传感器（AI 评审、LLM-as-Judge，第 12 章）------传统 CI 里根本没有这类概率性的语义检查。
OpenAI 团队把他们面临的最难挑战，定位为"设计环境、反馈回路和控制系统"------这个表述的量级，远超"一套 CI 流水线"。把 Harness 等同于 CI，会漏掉它一半以上的内容。
误解四：它不是"消灭人类参与"
最后一条误解带有某种技术乌托邦色彩：以为 Harness 的终极目标是把人类彻底踢出循环、实现全自动。恰恰相反。Böckeler 说得很清楚：
"一个好的 Harness，不应以完全消灭人类输入为目标，而应把人类输入引导到它最重要的地方去。"
Harness 的目的是重新分配 人类的注意力，而不是取消它：
- 它把人从琐碎的、机械可查的结构审查里解放出来（那些交给计算型传感器）；
- 从而让人能把注意力投向机器兜不住的地方------意图定义、价值判断、优先级权衡、"到底想要什么"（第 3 章的意图类失败、第 33 章工程师的新角色）。
正如第 3 章反复引用的那句话："正确性不在任何传感器的职权范围内------如果人类一开始就没说清楚想要什么。" 人类的判断力永远是系统的一部分，Harness 只是让这份判断力用在刀刃上。
4.6 与相邻学科的关系图谱
Harness Engineering 不是凭空长出来的，它与几个成熟的软件工程学科深度交叠。厘清这些关系，能帮你复用既有经验、避免重复造轮子，也能帮你在团队里给这个新领域"定位"。
markdown
┌────────────────────────┐
│ Harness Engineering │
└────────────────────────┘
▲ ▲ ▲ ▲
前馈的核心手段 │ 交付载体 │ 分工/借鉴 │ 分工/借鉴 │
┌──────────────┘ │ │ └──────────────┐
Context Engineering Platform Engineering DevEx 质量工程 / SRE
（上下文工程） （平台工程） （开发者体验） （质量保障 / 稳定性）与上下文工程（Context Engineering）：手段与体系
两者是手段与体系 的关系。Böckeler 专门用一个边栏讨论了"Harness Engineering 与 Context Engineering 有何关系"，结论是：上下文工程是 Harness"前馈部分"的核心手段。
把正确的知识、文档、约定、示例组织好，并在恰当的时机喂给 Agent------这件事本质上就是在做前馈引导。所以，上下文工程并不是 Harness 的竞争对手或上位概念，而是被吸纳 进了 Harness 的前馈半区。可以说：所有的上下文工程都是 Harness 的一部分，但 Harness 还包含上下文工程之外的东西（尤其是整个反馈半区）。 本书第三篇"知识库与上下文工程"（第 15--18 章）整篇都在展开这一交叠。
与平台工程（Platform Engineering）：交付载体
平台工程关注的是"把内部能力打包成自助式平台，供团队复用"。Harness 与它的关系是：Harness 可以作为一种内部平台能力来交付。
当一个团队沉淀出一套成熟的 Harness（一套规则模板、一批 Skills、一组传感器配置），完全可以把它平台化------做成模板、脚手架、共享库，供组织内其他团队一键复用（第 31 章"Harness 模板与平台化"专门讲这件事）。此时，平台工程提供的是 Harness 的分发和治理载体 ，Harness 提供的是平台之上的具体内容。
与 DevEx（开发者体验）：目标的延伸
DevEx 关注"如何让开发者工作得更顺畅、更高效、更少摩擦"。Harness Engineering 与它高度同源------只不过 Harness 把"开发者"这个服务对象，从"人类工程师"扩展到了"Agent"。
过去我们优化目录结构、命名、工具链，是为了让新入职的人类工程师 更快上手；现在我们做同样的事，是为了让 Agent 更快理解和操作代码库（第 20 章"Agent 可读性工程"）。很多 DevEx 的既有智慧可以直接迁移，但要注意 Agent 与人的差异（比如 Agent 没有常识、以 token 消费上下文）。
诚实标注 ：把 DevEx 视为"服务对象从人扩展到 Agent"，是本书为帮助读者迁移既有经验而做的类比与综合，并非框架原文的直接论断。请把它当作一个有用的思维桥梁，而非权威定义。
与质量工程 / SRE：分工与协作
质量工程（QA、测试策略、质量门禁）和 SRE（可靠性工程、SLO、可观测性）与 Harness 的反馈半区有大量重叠，但分工清晰：
- 质量工程 提供了大量现成的反馈手段（测试金字塔、覆盖率、变异测试......），Harness 把它们重新定向------从"给人看的质量门禁"变成"给 Agent 用的自纠错信号"（第 11、13 章）。
- SRE 的运行时监控、日志、追踪，为 Harness 提供了"运行时反馈"这一层（第 21 章"运行时可读性"、第 10 章 §10.3 的部署位置谱系最右端）。OpenAI 案例里 Agent 能用 LogQL/PromQL 查询日志和指标，正是把 SRE 的可观测性栈接给了 Agent。
诚实标注 ：与 SRE、质量工程的具体分工方式，同样是本书基于框架思想所做的综合与延展。框架文提到了"保持质量左移"（第 24 章）等思想，但这张关系图谱的细分是本书的组织方式。
这张图谱的核心信息是 ：Harness Engineering 不要求你抛弃过去所有的工程智慧，而是站在这些成熟学科的肩膀上，把它们的手段重新定向到"驾驭非确定性 Agent"这一新目标上。
本章要点
- 核心公式
Agent = Model + Harness：harness = "AI 代理中除模型本身之外的一切"。它把 Agent 切成"改不了的 Model"和"可经营的 Harness"两部分，从而把全部工程杠杆定位到 Harness 一侧。这是个"过于宽泛"的定义，需按"编码代理"这一边界上下文收窄。 - 三层同心圆 （全书锚点图）：最内层是模型 （选它用它不改它）、中间层是厂商内建 Harness （系统提示词/检索/编排，你改不了但要理解）、最外层是用户外层 Harness （规则/Skills/传感器/知识库...，本书主战场）。纪律：别在控制不了的地方内耗，全力经营最外层。
- 术语边界上下文 ：harness 至少有 Agent harness、test harness（测试夹具）、evaluation harness（评估框架）三种含义，共享"支撑与约束框架"内核但对象不同。本书不加限定的"Harness"一律指 Agent harness。
- 两大目标 ：①前馈------提高"一次做对"的概率 （事前引导）；②反馈------在问题到达人眼前自动纠正（事后闭环）。二者是全书经纬线，对应第 5 章控制论。
- 三个副产品 ：降低审查负担、提升系统质量、减少 token 浪费------它们是投资两大目标后自然溢出的结果指标。
- 四条"不是"：不是提示词技巧（提示无复利、Harness 有复利）、不是选更强的模型（"try harder"几乎从不是答案）、不是又一套 CI（缺了前馈、面向 LLM 的信号、推理型传感器）、不是消灭人类（而是把人类输入引导到最重要处）。
- 相邻学科：上下文工程 = Harness 前馈的核心手段（被吸纳）；平台工程 = Harness 的交付载体；DevEx = 服务对象从人扩展到 Agent；质量工程/SRE = 提供反馈手段，被 Harness 重新定向为 Agent 的自纠错信号。
动手练习
- 给你的 Agent 系统画三层同心圆。 针对你正在用的某个编码代理（Codex / Claude Code / Cursor...），把它拆成三层：最内层是哪个模型？中间层厂商内建了哪些你改不了的东西（系统提示词、检索方式）？最外层你已经构建了哪些、还能构建哪些？画完后，圈出"你花了最多精力、但其实属于你控制不了的层"的部分------那就是被浪费的努力。
- 给你现有的每个 Harness 构件贴"目标标签"。 列出你项目里所有的 Harness 构件（规则、文档、测试、linter...），逐个标注它服务于"目标一（前馈/提高一次做对概率）"还是"目标二（反馈/自动纠错）"。统计两类的比例，看看你的投资是否严重偏科（这会在第 5 章 §5.4 得到理论解释）。
- 破除一次团队里的误解。 在你的团队里找出四条"不是"中最流行的那一条误解（很可能是"等更强的模型就好了"或"我们有 CI 就够了"），用本节的论证写一段 200 字的反驳，并给出一个你们团队本可以用 Harness 手段解决、却一直在"try harder"的具体例子。
承上启下 ：本章给出了 Harness 的定义、结构、目标与边界，但"前馈 + 反馈"这套说法并非 AI 时代的发明------它是一门有近八十年历史的学科"控制论"的核心概念。第 5 章「控制论基础：把 Harness 看作调节器」 将请出这套现成的理论坐标系，讲清前馈与反馈为什么缺一不可、Ashby 必要多样性定律为什么预言"单一控制手段必然失效"，以及人类在新范式下的工作界面------掌舵回路。