案例篇：四个现场与一个反例

一套方法论若想站住，最终总要回到现场。没有现场，判断就容易变成口号；没有可反复回查的案例，结构也很容易失去重量。

案例篇因此不是附录，而是全书的证据底盘。

序章和第二篇里反复出现的那个“二十人 SaaS 团队做登录与邀请流程改造”的贯穿案例，并不是新闻报道，而是一个教学性合成案例。

它之所以能成立，正是因为背后站着五组公开材料：OpenAI 内部用 Codex 做产品、OpenAI 把 harness 产品化成 App Server、Anthropic 把长时程 agent 的交接和恢复做成骨架、LangChain 把 harness 当作可量化变量来调、METR 用反例提醒我们边界真实存在。

再加上一条明确标注为教学性推演的灰度险情，前面七篇的方法论才真正落回可回查现场。

1. OpenAI：Harness 的形成是问题驱动的结果

OpenAI 公开内部使用 Codex 构建产品的案例，是这本书最重要的起点材料之一。它真正有价值的地方，不只是“做出了很多代码”，而是把一个此前容易停留在概念层的问题，直接逼到了工程现场：当团队刻意减少人工补位时，什么东西必须被显式写进环境里，agent 才能稳定工作。

这篇公开材料最容易被外界记住的，是量级数字：五个月、约一百万行代码、约一千五百个 PR、几乎没有人工手写代码、产品已经有真实使用者（见参考文献[1]）。

但对本书而言，这些数字并非最关键。更关键的是，它们迫使读者追问：如果这些数字大体成立，系统究竟依靠什么支撑。答案并不神秘。真正支撑这组产能的，不是某个惊艳 prompt，而是 repo-local docs、默认路径、评分系统、可观测性、本地可启动 worktree、后台清理与持续规则化。

OpenAI 这个案例首先证明的，不是“模型终于会写很多代码”，而是“环境一旦不被写清楚，agent 很快就会撞墙”。

这和第一篇立论完全对齐。Harness engineering 不是一门先验发明出来的新学问，而是当 agent 真正进入工作流后，被失败逼出来的工程层。

OpenAI 之所以最后要把 AGENTS.md 从“大而全总说明”收缩成入口文件，再把真正知识拆进 docs/、执行计划、技术债跟踪和质量信号里，恰好说明一个核心事实：问题不是“上下文够不够长”，而是“事实能不能被系统正确找到”。

这个案例还支撑了第二篇很多判断。Intent layer 在这里表现为“任务如何被写成 agent 真能接的工程对象”；Context layer 表现为 repo-local knowledge 的地图化；Tool layer 体现在 worktree、浏览器和日志系统接入；Constraint layer 体现在默认路径和规则；Verification layer 体现在评分与质量回路；Improvement layer 则体现在后台清理和不断把经验写回系统。

七层并不是抽象拼装出来的，而是在这种高度 agent-first 的现场里被一层层逼出来的。

OpenAI 案例还对第五篇有直接支撑。它告诉我们，工程师角色迁移并不是哲学比喻，而是劳动重心的实际变化。团队关键工作不再只是补代码，而是搭环境、写规则、整理知识、定义完成、管理默认路径。

更短地说，高吞吐不是模型给的奖赏，而是环境的复利。

但这个案例最不能被误读成的，是“只要模型够强，团队自然会进入这种状态”。恰恰相反，它证明的是：只有在环境被大量重写之后，这种状态才有可能出现。它证明的是成本，而不只是结果。

四个现场与一个反例怎样分工

把整组材料的分工压成一张表，会更清楚。它们并不提供同一种证据：有的解释概念为何出现，有的解释结构为何必须拆开，有的解释控制为何要进入运行时，有的解释平台化与组织边界如何形成，还有的负责对冲热潮叙事，重新引入边界约束。

总表一：四个现场与一个反例如何托住全书六条主线

案例	它最能证明什么	它最不能被误读成什么	主要支撑本书哪一条主线	对应篇章
OpenAI 内部 Codex 产品案例	harness 为什么会被逼出来；高吞吐背后是环境重写	不是“模型自动接管工程”	出现、结构、组织	第一篇、第二篇、第五篇
OpenAI App Server	harness 会从团队经验上升为运行时和平台层	不是“多端适配的小工程”	组织、外溢	第五篇、第六篇、第七篇
Anthropic 长时程 agent	handoff、memory、verification 为什么是骨架	不是“长上下文自然等于长时程自治”	结构、控制	第二篇、第四篇
LangChain Deep Agents	固定模型下，harness 可以作为可量化变量改变上限	不是“benchmark 分数等于组织现实”	控制	第四篇、第七篇
METR 开源开发者研究	真实熟悉环境里，AI 可能先制造摩擦而不是提速	不是“AI 没价值”的总否定	外溢、边界	第六篇、第七篇

这张表里最重要的一列，是“它最不能被误读成什么”。很多书在案例写作中的问题，不是缺少证据，而是把证据解释过度。顺风案例被误读为普遍规律，反例又被误读为全面否定。

案例篇真正困难的地方，恰恰是同时保留力量和边界。以上四个现场与一个反例分别对应参考文献[1]、[3]、[9]、[10]、[11]。第三篇关于 repo、golden path、review 和 slop 治理的判断，也主要站在这些材料之上。

2. OpenAI App Server：当 Harness 开始从团队经验上升为平台层

如果前一个 OpenAI 案例说明 harness 会在真实软件生产里被逼出来，那么 App Server 则说明，harness 一旦成熟，不会长期停留在团队经验层。它会进一步上升，变成运行时、协议层和平台层能力（见参考文献[3]）。

这篇材料之所以在全书里地位很高，是因为它直接托住了第五篇、第六篇和第七篇的关键判断。第五篇讲“harness engineering 不是个人技能，而是团队与组织能力”；App Server 正好展示了这件事更进一步的样子。

Codex 不只存在于一个终端命令里，而是同时服务 CLI、IDE、桌面端、Web 端以及更多外部接入点。支撑这些不同界面的，不是各写各的 agent 逻辑，而是一套共享 harness。

这意味着 harness 不再只是“几个工程师心里的一套工作法”，而开始像真正基础设施那样，被抽象成 thread、turn、event、approval、tool execution、state persistence 这类稳定原语。

第六篇谈“外溢条件”时，App Server 也很关键。它说明跨域外溢不是一句“别的行业也能用 agent”就够了，真正要外溢的是运行时和工作面。

如果一个团队连自己的任务对象、状态原语、审批点、工具面都还说不清，它就谈不上平台化。App Server 的启发恰恰在于：harness 不是多装几个工具，而是先把什么算一个线程、什么算一次交互、什么算一次暂停、什么算一类事件，这些最基础的工作对象定义清楚。

第六篇之所以把“工作面可发现”写成外溢前提之一，这个案例就是关键证据。

到了第七篇，App Server 又支撑了另一个更大判断：被低估的不是几条技巧，而是工程环境正在产品化、平台化。

一个能力如果只能停留在团队内部经验层，它的寿命通常不会太长；但当它必须跨终端、跨界面、跨用户群共享时，它就已经不再只是习惯，而是在沉成新的基础设施。

App Server 最该被读者记住的，不是“OpenAI 又做了一个产品”，而是“harness 已经开始长出操作系统层特征”。

这个案例最不能被误读成的，是“多端适配的自然延伸”。它真正重要的地方，不在于多端本身，而在于它逼迫团队把原本隐含在工程默契里的东西，抽象成可复用、可维护、可交互的稳定运行时。

这件事对本书意义很大，因为它把 harness 从“方法论”往“基础设施”再推了一层。

3. Anthropic：长时程 agent 不怕不会写，怕的是交不了班

Anthropic 的长时程 agent 案例，是整本书里最适合拿来支撑第二篇和第四篇的材料。原因很简单：它把“结构”和“控制”两个问题同时暴露得很清楚。

表面上看，这篇材料在讲编码；更深一层看，它讲的是一个系统为什么会在会话边界上失忆、误判完成、留下残局，以及应该怎样通过交接和验证把这些失败变成可治理对象（见参考文献[9]）。

这个案例最有穿透力的部分，不是成功流程，而是失败起点。Anthropic 明确写出，单靠更长上下文和连续调用，并不会自然长出可靠长时程 agent。系统会出现两个高度典型失败：一种是过度进攻，试图一口气做完整件事，最后把半完成现场耗死在上下文边界里；另一种是过早收工，四处看一眼，就宣布“差不多好了”。

这两个失败模式对第四篇尤其重要，因为它们说明“完成”不是主观感觉，而必须被更强验证回路定义。

Anthropic 的修正方式也因此极有代表性。它没有把问题继续推给模型，而是先在 harness 上拆层：initializer agent 用来搭环境和留下初始工地，coding agent 用来做后续迭代；进度日志、feature list、init.sh 和 git 提交一起构成交接面；浏览器自动化测试和更明确功能列表一起构成完成判断。

第二篇里的 Memory layer、Verification layer、Improvement layer，在这个案例里几乎一目了然。不是先有抽象七层模型再去找材料往里塞；而是这样的案例逼着我们承认：长时程自治如果没有交接、没有记账、没有验收、没有恢复机制，根本走不远。

Anthropic 这个案例也给第四篇提供了一句非常扎实的支撑：长时程 agent 面临的首要风险，不是能力不足，而是无法稳定交接。

这不是修辞，而是工程判断。很多团队一谈到 agent 失败，第一反应是“换个更强模型”；Anthropic 的经验提醒我们，更常见的问题是系统没有把状态、阶段、完成与升级写成可继承结构。只要这一点不解决，再长上下文也只是把问题推迟，而不是解决。

这个案例最不能被误读成的，是“长上下文自然等于长时程 agent”。它真正证明的是，长时程能力从来不是上下文长度的直接函数，而是交接结构、验证强度和恢复能力的函数。

4. LangChain：Harness 作为可量化变量

LangChain 的案例在整本书里的价值很特别。前面几个案例已经证明 harness 很重要，但还容易被质疑成“成功团队的经验之谈”。

LangChain 这篇材料，把这种经验又往“可测量变量”推进了一步。它把问题问得很直接：如果模型不变，只改 harness，会发生什么（见参考文献[10]）？

他们给出的结果是，固定同一个模型 gpt-5.2-codex，deepagents-cli 在 Terminal Bench 2.0 上从 52.8 提升到 66.5。

这并不意味着 benchmark 就是真实组织，但它至少把一件事做实了：harness 不是氛围词，而是能在一定条件下被量化地推动结果上限。也因此，LangChain 是第四篇最关键证据之一。

更重要的是，这个案例把“harness 调优”拆成一组可以被分析的机制，而不是继续停留在提示词审美上。trace 用来找失败模式，middleware 用来在退出前强制验证，build-self-verify 回路用来防止系统“看着像完成就停”，loop detection 用来阻断在错误路径上的局部打转，reasoning budget 和环境提示用来降低无意义摸索。

第四篇之所以把 harness engineering 写成控制系统，而不是写成 prompt 手艺，这个案例是关键证据。

它还对第七篇“高估与低估”都提供了帮助。一方面，它支持了“被低估的不只是提示技巧，而是一整套闭环结构”；另一方面，它也提醒我们不要把 benchmark 胜利误写成组织现实。

LangChain 做得越干净，这个提醒越重要：它证明了 harness 可以被量化，不等于它已经自动跨越真实组织里的所有摩擦。

这个案例最不能被误读成的，是“只要 benchmark 提升，就等于企业提效”。它真正证明的是更有限也更硬的一句：在固定模型下，harness 可以作为系统变量改变上限。

5. METR：反例的边界价值

如果没有 METR，这本书的案例篇会失去必要的平衡。前四个案例都很强，强到容易让读者误以为“方向已经完全坐实，剩下的只是速度问题”。

METR 的价值，在于它把这种过早确定感拦住了（见参考文献[11]）。

这项研究关注的是一个很关键但并不讨喜的场景：熟悉自己仓库的资深开源开发者，在真实项目里完成 issue 时，使用 2025 年初的 AI 工具，平均并没有更快，反而慢了 19%。更让人警醒的是，开发者自己依然倾向高估 AI 帮助。

这组结果之所以对第六篇和第七篇极其重要，不是因为它推翻前面成功，而是因为它迫使我们承认：环境、隐性知识、人机切换成本和任务形态，都会让 agent 的价值变得高度条件化。

第六篇之所以最后写成“外溢条件分析”，而不是写成“跨行业胜利宣言”，METR 是关键支点。它提醒我们，外溢不是自动发生，也不是均匀发生。

一个高度依赖隐性知识、局部经验和熟悉感的环境，可能会让人类专家拥有非常强上下文优势；在这种情况下，AI 工具带来的额外交互、验证和切换成本，未必能被生成收益抵消。

第七篇关于“最容易被高估在哪里”的论述，也几乎要靠这个案例托底。否则，全书就会滑向只凭顺风案例搭建的倡议文本，而不是方法论写作。

METR 对这本书还有另一个更深价值：它帮助我们区分“AI 无效”和“harness 未成形”这两件事。很多反例讨论会直接滑向犬儒主义，仿佛只要某个场景里慢了，整件事就不值得再谈。

但 METR 的更强读法是：当环境没有被重写成 agent 友好工作面时，人类熟悉度和切换成本会真实压过生成能力。这个判断不是否定前文，而是替前文画出边界。

这个案例最不能被误读成的，是“AI 没有价值”。它真正证明的是：不是所有场景都会立刻因 agent 受益，而边界本身就是方法论的一部分。

还缺的一类现场：必须停下来的灰度险情

五组公开材料已经足够说明环境、交接、验证、平台化和边界，却几乎都缺少一类对普通团队最重要的现场：系统为什么必须停下，以及停下之后谁把事故写回环境。

OpenAI 让人看见环境为何必须被重写，Anthropic 让人看见交接为何会成为骨架，LangChain 让人看见验证为何必须进入回路，METR 让人看见边界为何真实存在。但问题如果再追近一步，就会落到更具体的现场：在一个普通团队里，真正遇到灰度险情时，谁让系统停下？谁决定回滚？谁负责把这次险情写回模板、验证和权限带？这些问题，公开材料并不会自动替我们回答。

因此，本书在第四篇和第五篇中专门补入了一条明确标注为教学性推演的灰度险情。它并不替代新闻事实，而是把前面已经证明的机制压回一个更接近普通生产现场的连续动作链。

这条推演并不提供新结论，只是让已有结论第一次真正带上手感：

• 灰度、日志和一线报警，如何把“好像有点不对”变成“必须停下来的偏差”
• 暂停权、回滚权和审批权，如何决定组织是不是在真正控制风险
• 复盘为什么不能只写“下次注意”，而要追问本来该由哪一层挡住它
• 一次险情之后，done definition、验证链路、结构保护和授权带是怎么被改写的

这条教学性险情不是第六个主案例，而是一段补强装置。它补的不是“更多故事性”，而是五组公开案例共同缺少的连续生产触感。

总表二：成功机制、失败机制与修正机制对照表

第一张表回答的是“哪些案例托住了哪根梁”；这一张表回答的，则是“这些梁到底靠什么站住”。

它把案例里的机制拆成成功机制、失败机制和修正机制。比起只记住故事，真正重要的是看清这些机制怎样重复出现。

案例	成功机制	暴露出的失败机制	最有代表性的修正机制
OpenAI 内部 Codex 产品案例	repo-local docs、worktree、可观测性、评分与清理	知识不可发现、默认路径过弱、坏模式快速复制	把隐性知识拆进仓库，把规则和质量信号写回系统
OpenAI App Server	线程持久化、统一事件流、工具接入、审批交互	harness 停留在局部技巧层、跨端状态碎片化	把团队习惯抽象成稳定原语和运行时接口
Anthropic 长时程 agent	initializer + coding 分层、progress log、feature list	会话失忆、过早收工、半成品交接	init.sh、结构化 handoff、端到端验证
LangChain Deep Agents	traces、middleware、build-self-verify、loop detection	在错误路径上打转、看似完成却没验证	失败模式分析 + 强制验证回路 + 中间件控制
METR 开源开发者研究	无显著系统性成功机制被观察到	人机切换成本高、隐性知识优势强、真实环境摩擦大	不能靠局部提示修补，必须重构任务分工与工作面

这张表最值得注意的，不是哪个案例“最好”，而是哪类修正机制反复出现。知识地图、交接工件、验证闭环、统一运行时、把失败写回系统，这些东西一旦重复出现到一定程度，就很难再被解释成偶然技巧。

它们开始构成一层稳定工程对象。

6. 六个更硬的判断

把五个公开现场再加上一条教学性险情并置起来，最后真正值得留下来的，是六个判断。它们分别对应全书已经稳定下来的六条主线。

第一，关于“出现”。Harness engineering 不是先被命名出来的，而是先被失败逼出来的。OpenAI 和 Anthropic 都说明，当 agent 真正进入工作流后，团队会发现单靠 prompt 已无法解释为什么系统不断在同类问题上跌倒，于是知识、边界、交接、验证开始被写进环境（见参考文献[1]、[9]）。

第二，关于“结构”。第二篇的七层结构不是抽象发明，而是对公开现场的压缩。OpenAI 让我们看见 Context、Tool、Constraint 如何被堆起来；Anthropic 让我们看见 Memory、Verification、Improvement 为什么是长时程骨架；LangChain 让我们看见这些层之间如何通过控制回路协同（见参考文献[1]、[9]、[10]）。

第三，关于“控制”。真正决定系统是否可靠的，不是生成时那一下，而是系统能不能形成闭环。Anthropic 和 LangChain 都说明，没有强验证、没有 trace、没有退出前约束、没有失败分析，系统再能干，也只是反复猜（见参考文献[9]、[10]）。

第四，关于“组织”。OpenAI 内部案例与 App Server 一起说明，harness 很快会从个人技巧升级成团队能力，再升级成平台能力。它不是“谁更会用 AI”的故事，而是“谁更早把环境、审批、状态和工具面写成系统资产”的故事（见参考文献[1]、[3]）。

第五，关于“外溢”。App Server 与 METR 放在一起看，可以逼出第六篇冷判断：能外溢的不是“用了 agent 的场景”，而是“已经具备足够清楚工作面、验证面和责任面的场景”（见参考文献[3]、[11]）。

第六，关于“边界”。METR 的存在提醒我们，边界不是附录，而是方法论的一部分。一个不能同时解释成功和失败的概念，最后只能变成口号。OpenAI、Anthropic、LangChain 给出了增长曲线，METR 则替这条曲线画出失效条件（见参考文献[1]、[9]、[10]、[11]）。

再往下压，可以得到六句更克制的判断：

• Harness engineering 不是被想出来的，而是被失败逼出来的。
• 七层不是作者发明的框架，而是公开现场留下的压缩痕迹。
• 系统能不能持续做对，取决于它会不会停、会不会验、会不会把错写回去。
• 真正稀缺的不是更会用 AI 的个人，而是更早把环境写成组织资产的团队。
• 外溢不会自动发生，它只会沿着工作面、验证面和责任面足够清楚的地方发生。
• 边界不是悲观主义，而是成熟判断的一半。

本篇小结

案例篇真正完成的，不是材料堆砌，而是证据归位。前七篇里那些最重要判断，并不是作者独自推出来的，而是被五个公开现场，再加上一条明确披露的教学性险情反复逼出来的。

也因此，它在这里不是附录，而是让整本书重新落地的那一层。把它再压成最短一句，就是：

模型可以给出答案，Harness 决定答案能不能进入现实。