第 13 章 · 高级技术：ToT 与 Prompt Chaining
本章目标：理解"模型很强但执行不可靠"的根源——能力鸿沟（capability gap）与 harness-induced failure，学会用诊断循环定位问题层，为后续 harness 工程打下认知基础。
10.1 SWE-bench 的真相：50%–60% 意味着什么
2025 年底，SWE-bench Verified 基准上最强的编码智能体通过率达到约 50%–60%。这个数字乍看不错——但别急着庆祝。
这个基准集有几个隐藏前提：
- 题目是经过挑选的 GitHub issue，描述清晰；
- 配套测试用例已经写好，验证标准明确；
- 仓库上下文相对干净，没有十年历史的技术债。
换成真实工作场景——模糊的需求文档、散落在代码库里的隐式约定、没有测试覆盖的代码——通过率会掉得更低。Anthropic 和 OpenAI 都报告过：在工程团队的实际项目中，即使是最强模型在未加 harness 的情况下，成功率经常低于 20%。
这就是能力鸿沟（Capability Gap）——模型在基准上的表现与实际任务表现之间的巨大落差。
核心论断
模型不强不是问题；harness 不完整才是。 同一模型，换不同的执行环境，结果可以天差地别。
10.2 同一个模型，两种命运
Anthropic 做了一个对照实验，把同一句话（"做一个 2D 复古游戏编辑器"）和同一模型（Opus 4.5）跑了两遍：
| 运行 | 用时 | 花费 | 结果 |
|---|---|---|---|
| 裸跑（bare run） | 20 分钟 | $9 | 核心功能无法使用 |
| 全 harness（规划器 + 生成器 + 评估器） | 6 小时 | $200 | 游戏完全可玩 |
模型没变，提示词没变，变的是 tack——也就是围绕模型的工程基础设施。
OpenAI 2025 年的 harness engineering 文章用了一个更直接的词：Codex 在一个有完整 harness 的仓库里，表现不是"a bit better"，而是从 "unreliable"直接跳到"reliable"，这是质变。
10.3 五大失败模式
当 agent 说"完成了"但结果不可用时，问题通常落在以下五层之一。记住这张清单，每次失败先定位层，再想怎么修：
① 需求模糊（Task Specification）
"添加搜索功能"——搜索什么？全文还是结构化查询？结果要分页吗？高亮吗？agent 只能猜，猜对了是运气，猜错了返工成本是明确写出来的好几倍。
② 隐含约定未记录（Context Provision）
团队统一用 SQLAlchemy 2.0 语法，但 agent 默认写 1.x；所有 API 必须走 OAuth 2.0 鉴权，但这条规则只存在于你们团队的 Slack 历史消息里。agent 不是不想遵守，它根本没看见这条规则。
③ 环境不全（Execution Environment）
依赖没装完、Node 版本不对、测试命令路径写错——agent 把宝贵上下文预算花在
pip install报错和版本冲突上，而不是真正的工作。
④ 无验证方式（Verification Feedback）
没有测试，没有 lint，或者验证命令根本没有告诉 agent。agent 写完代码，扫一眼觉得"差不多"，就宣布完成。Anthropic 观察到一个有趣的现象：当 agent 感知到上下文快用完时，会表现出"焦虑式收尾"（context anxiety）——跳过验证步骤、选简单的方案、仓促结束。
⑤ 跨会话状态丢失（State Management）
每个新会话从头开始。上一轮的分析、决策理由、已修改的文件全部丢失。没有持久化状态记录时，超过 30 分钟的长任务失败率会急剧上升。
10.4 关键术语：Definition of Done
五个失败模式对应的 remedy 是一个新概念：Definition of Done（完成定义）。
DoD 是一组可以被命令行验证的条件，不是主观判断。比如：
## Definition of Done
- [ ] 新增接口 `GET /api/search?q=xxx` 返回 JSON
- [ ] 支持分页，默认每页 20 条
- [ ] 搜索结果中高亮关键词
- [ ] 所有新增代码通过 `pytest tests/` 测试
- [ ] 类型检查通过 `mypy src/ --strict`注意这些条件全是可执行的——每个条件都能对应一条命令。没有 DoD 的 agent 会自己发明一套"我觉得做完了"的标准，那套标准几乎总是过于乐观。
10.5 诊断循环：每次失败都是改进机会
harness engineering 的核心方法论是一个闭环——诊断循环（Diagnostic Loop）：
执行 → 观察失败 → 归因到具体层 → 修复该层 → 重新执行不要只看"模型不够强"这一个结论。每遇到一次失败，问自己：
- 是任务不清晰？→ 补充 AGENTS.md 里的需求描述
- 是上下文不足？→ 补充技术栈版本、架构约束、相关文档链接
- 是环境不可复现？→ 用 pyproject.toml / .nvmrc / Docker 锁定
- 是验证反馈缺失？→ 在 AGENTS.md 里写明
make check命令 - 是状态丢失？→ 引入 PROGRESS.md 或类似的状态持久化文件
每次归因后修一条，再跑一次。几轮之后，你会清楚地看到瓶颈在哪一层，然后把精力集中在那里。
记录越简单越好——只需记下每任务的"成功/失败"和"失败在哪一层"，数据积累下来瓶颈自然浮现。
本章小结
- SWE-bench 50%–60% 是精心挑选的基准；真实场景中裸跑成功率往往低于 20%；
- 同一模型不同 harness 实验：裸跑 20min/$9 vs 全 harness 6h/$200，结果天差地别；
- 五大失败模式：需求模糊、隐含约定未记录、环境不全、无验证方式、跨会话状态丢失；
- Definition of Done 必须可被执行命令验证，不是主观感受；
- 诊断循环是核心方法论：失败 → 归因到层 → 修复 → 重跑，循环迭代。
🧪 随堂测验
点击你认为正确的选项。答错时会展示正确答案与原因解析。
1. Anthropic 对照实验中，同一模型 Opus 4.5 裸跑 20 分钟花费 $9 的结果是什么？
2. "Definition of Done"的核心特征是什么？
3. 当 agent 感知到上下文即将耗尽时，Anthropic 观察到的现象叫什么？
4. 以下哪项是"诊断循环"的正确执行顺序？
🛠️ 动手实践
- 找一个你熟悉的项目（或创建一个小项目），在它没有任何 AGENTS.md 的情况下让 Claude Code / Codex 完成一个任务，记录失败现象，然后补上 AGENTS.md 并再次运行，对比两次成功率。
- 为你的项目手写一份 Definition of Done，要求至少包含 5 条可被命令验证的条件（测试、类型检查、lint、构建等）。
- 回顾最近一次 agent 失败的经历，用五大失败模式清单逐条归因，写出具体应该补哪一层。
完成后进入下一章：Harness 到底是什么。