10-案例篇-四个现场与一个反例

案例篇四个现场与一个反例一套方法论若想站住最终总要回到现场。没有现场判断就容易变成口号没有可反复回查的案例结构也很容易失去重量。案例篇因此不是附录而是全书的证据底盘。序章和第二篇里反复出现的那个“二十人 SaaS 团队做登录与邀请流程改造”的贯穿案例并不是新闻报道而是一个教学性合成案例。它之所以能成立正是因为背后站着五组公开材料OpenAI 内部用 Codex 做产品、OpenAI 把 harness 产品化成 App Server、Anthropic 把长时程 agent 的交接和恢复做成骨架、LangChain 把 harness 当作可量化变量来调、METR 用反例提醒我们边界真实存在。再加上一条明确标注为教学性推演的灰度险情前面七篇的方法论才真正落回可回查现场。1. OpenAIHarness 的形成是问题驱动的结果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 Serverharness 会从团队经验上升为运行时和平台层不是“多端适配的小工程”组织、外溢第五篇、第六篇、第七篇Anthropic 长时程 agenthandoff、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. LangChainHarness 作为可量化变量LangChain 的案例在整本书里的价值很特别。前面几个案例已经证明 harness 很重要但还容易被质疑成“成功团队的经验之谈”。LangChain 这篇材料把这种经验又往“可测量变量”推进了一步。它把问题问得很直接如果模型不变只改 harness会发生什么见参考文献[10]他们给出的结果是固定同一个模型gpt-5.2-codexdeepagents-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 长时程 agentinitializer coding 分层、progress log、feature list会话失忆、过早收工、半成品交接init.sh、结构化 handoff、端到端验证LangChain Deep Agentstraces、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 决定答案能不能进入现实。