不要只关注让AI写更好的代码，要关注如何构建一个能让AI持续可靠地工作的系统
-----Mitchell Hashimoto
引言：为什么案例比Prompt技巧更重要
当 Agent 真正进入生产环境，一个令人沮丧的现象反复出现：模型换了一代又一代，Agent依然会声称完成但未验证、在同一文件上死循环修改、破坏既有架构、用删测试的方式"通过"测试。
这些问题不是"Prompt写的不够好"能解决的。顶尖团队给出的答案越来越一致：
Agent = Model（模型） + Harness（驾驭系统）
Harness 是套在模型外面的工程控制系统------约束、验证、反馈、编排。它不限制模型的"智能上限"，但决定了模型在真实任务里能不能稳定交付。
《从零开始学 Agent》第 8 章 用 六大工程支柱 把 Harness 拆成可落地的模块。本文选取三个已在生产环境验证的案例------OpenAI 百万行代码实验、LangChain Terminal Bench +13.7%、Stripe Minions 每周 1000+ PR------用这六根柱子逐一拆解，看看它们各自押注了 Harness 的哪一层。
一：六大支柱：Harness的"承重结构"
| 支柱 | 解决的核心问题 | 核心机制 |
|---|---|---|
| ① 上下文架构 | 长任务中上下文过载、跳步、焦虑 | 生命周期管理、渐进式披露 |
| ② 架构约束 | Prompt 软约束不可靠 | 工具白名单、Linter 规则、强类型参数 |
| ③ 自验证循环 | 未验证就声称完成、作弊删测试 | Plan-Build-Verify-Fix、防作弊检查 |
| ④ 上下文隔离 | 多 Agent 错误跨线程传播 | 子 Agent 防火墙、结构化消息总线 |
| ⑤ 熵治理 | AI 高速写码导致质量螺旋下降 | 文档园丁、Cleanup Agent、定期扫描 |
| ⑥ 可拆卸性 | Harness 越堆越厚，掩盖模型真实能力 | 组件元数据、模型升级后审查移除 |
实施建议也很明确：不要一次做完六根柱子。上下文架构 + 架构约束 + 自验证循环，已经能解决约 80% 的生产可靠性问题。
下面三个案例，恰好覆盖了 Harness 从"从零搭建"到"纯优化"到"大规模自动化"的不同形态。
二、OpenAI：五层Harness如何映射到六大支柱
背景
3 名工程师 + AI Agent，5 个月交付约 100 万行生产代码，人类零手写。这不是 POC，而是已部署的真实系统。
OpenAI 团队构建的是一套从上到下的五层约束体系：
- 渐进式知识体系
- 架构约束体系
- 运行时可观测性
- 自修复闭环
- AI 互审（Ralph Wiggum 循环）
这五层与六大支柱的对应关系非常清晰：
① 上下文架构：文档目录，而非文档全文
OpenAI 的关键创新是 "AGENTS.md 只放目录，不放全文"
项目架构
→ 见 docs/architecture-overview.md
→ 见 docs/domain-model.md
模块指南
→ 见 src/payments/AGENTS.md
→ 见 src/users/AGENTS.md
这正是渐进式披露（Progressive Disclosure） 的生产级实践：启动时只注入轻量索引，Agent 按需 read_doc 拉取具体章节，避免 2000 行文档一次性塞满 context window。
同时，运行时可观测性层把 Git 状态、可用工具、诊断命令格式化为 Agent 可直接解析的结构化上下文------这是上下文架构里"注入阶段"的工程化实现。
支柱命中：① 上下文架构（核心）
② 架构约束：代码库就是 Agent 宪法
OpenAI 把架构规则编码为 AST Linter，例如 api/ 不能直接导入 models/，必须通过 services/。规则不是写在 Prompt 里的"请遵守分层架构"，而是 CI 里跑不过就 merge 不了。
他们的核心经验之一：
代码库就是 Agent 宪法------所有规则必须以代码（Linter、测试）而非文字存在。
支柱命中：② 架构约束（核心）
③ 自验证循环：AI 互审替代人工 Code Review
"Ralph Wiggum 循环"：Writer Agent 写代码 → Reviewer Agent 按清单审查 → 有问题则打回修复 → 人类只做架构级决策。
审查清单包括：是否符合分层规则、错误处理是否充分、测试覆盖、硬编码、性能问题等。这是 自验证循环的多 Agent 变体------验证者与被验证者分离，类似 GAN 的 Generator/Critic 结构。
支柱命中：③ 自验证循环 + ④ 上下文隔离（Reviewer 不污染 Writer 的完整历史）
⑤ 熵治理：Doc Gardener + Cleanup Agent
- Doc Gardener：PR 合并后自动检查文档与代码是否同步，不一致则自动开修复 PR
- Cleanup Agent：每天扫描命名不规范、缺少类型注解等偏差，低风险问题自动提交清洁 PR
这是典型的 熵治理------AI 写码速度极快，没有主动维护机制，代码库会迅速腐化，进而拖累后续 Agent 的工作质量。
支柱命中：⑤ 熵治理（核心）
OpenAI 给我们的启示
OpenAI 五层架构的顺序本身就有方法论意义：上层约束越清晰，下层自主性越高。
"为了获得更高的 AI 自主性，运行时必须受到更严格的约束"------这句话同时解释了 ② 架构约束 和 ③ 自验证循环 为什么不是限制，而是解放。
三、LangChain：不换模型，纯 Harness 优化 +13.7%
背景
Terminal Bench 2.0 基准测试：52.8% → 66.5%，排名从 30 名开外进入前 5。
零模型切换，零微调，所有提升来自 Harness 改进。
LangChain 的五项改进，几乎是对前三大支柱的"量化证明"：
| 改进项 | 贡献 | 对应支柱 |
|---|---|---|
| Plan-Build-Verify-Fix 强制循环 | +7.1% | ③ 自验证循环 |
| 推理三明治策略 | +2.8% | ① 上下文架构（推理预算分配） |
| 环境上下文注入 | +1.9% | ① 上下文架构（启动注入） |
| 死循环检测中间件 | +1.4% | ③ 自验证循环 + ⑥ 可拆卸性 |
| Meta 层 Trace 分析 | +0.5% | ⑥ 可拆卸性（Harness 自我进化） |
③ 自验证循环：+7.1% 来自"强制验证"
LangChain 最大的单项贡献，不是更聪明的 Prompt，而是 强制 Agent 在声称完成之前必须跑测试、对照任务逐项核查。
数据说明了一个残酷事实：大量 Agent 失败的根本原因不是"不会做"，而是 "声称完成但实际未完成验证"（完成偏见 Completion Bias）。
④ 推理三明治策略：+2.8%
│ 高推理预算 │ ← 规划阶段（需要深度分析）
│ 中等推理预算 │ ← 实现阶段（按计划执行）
│ 高推理预算 │ ← 验证修复阶段（需要深度分析） └
"推理三明治"的设计：规划与验证需要深度思考，实现阶段按计划高效执行即可。全程高推理反而降低性能------规划阶段消耗过多 token，实现阶段超时或质量下降。
⑤ 环境上下文注入（+1.9%）
Agent 每次任务开始都要"搞清楚自己在哪"------探索目录结构、查可用工具------浪费宝贵的 context 和推理时间。
LangChain 的解法是启动时一次性注入：工作目录、三级目录树、工具清单、超时时间、常用命令速查。改动几十行代码，收益显著------典型的"低垂果实"。
⑥ 死循环检测与 Meta 自动化
死循环检测中间件在工具调用层拦截：同一文件修改超过 3 次，自动注入"换个思路"提示，而不是直接拒绝执行。这是 Harness 在 Agent 外层加的 软护栏，属于可拆卸组件------模型未来若不再陷入此类循环，可以审查移除。
Trace 分析器更值得关注：批量分析失败案例，聚类后自动生成 Harness 修复建议，并标注应在"上下文架构 / 约束 / 验证循环"哪一层修复。贡献只有 +0.5%，但它是 Harness 自我进化的引擎------每次失败都变成系统改进的输入，对应 ⑥ 可拆卸性 里的"持续审查与迭代"。
LangChain 给我们的启示
LangChain 案例最有力的论点是：Harness Engineering 是可以被量化、被 A/B 测试的工程学科。
当你看到 +13.7% 的分布，会立刻明白该先投哪里------验证循环 > 推理预算 > 环境注入 > 死循环检测 > Meta 自动化。
四、Strip Miniors：多Agnet规模化的Harness设计
背景
Stripe 的 Minions 系统专门处理技术债清理：
- 每周自动合并 1000+ PR
- 人工审查介入率 < 5%
- 主要工作：依赖更新、Lint 修复、代码规范对齐
Stripe 的 Harness 重点不在"写新功能"，而在 任务原子化 + 审查清单 + 自动合并的信心门槛。
① 架构约束：任务范围硬限制
每个 Minion 执行时受到严格约束：
python
constraints={
"max_files_changed": 5,
"max_lines_changed": 100,
"forbidden_changes": [
"breaking_api_changes",
"database_schema_changes",
"security_related_code",
],
}这不是 Prompt 里的"请小步修改"，而是 Harness 层的硬边界。Stripe 的核心经验：
约束是自由的前提------边界越清晰，Agent 在边界内越敢大胆行动。
支柱命中：架构约束（核心）
② 上下文隔离：20 个 Minion 并发互不干扰
Minions 系统有 Worker Pool（约 20 个并发小 Agent），每个 Minion 只做一件极具体的事------"更新这一个文件的这一个依赖"，而不是"清理整个项目的依赖"。
任务原子化的好处：
- 失败范围被严格限制
- 审查更容易（改动小、上下文清晰）
- 并发性更高（互不干扰）
这是 上下文隔离在大规模场景下的典型应用：每个 Minion 持有最小必要上下文，通过任务队列和审查 Agent 结构化交互，而非共享完整对话历史。
③ 自验证循环：审查清单优先于人工判断
Stripe 的审查清单非常具体，每一条都能被机器验证：
- 是否仅包含声明类型的变更？
- 是否有完整测试覆盖？
- 是否通过所有 CI？
- 变更范围是否超出任务描述？
- 是否有安全相关改动？
全部通过 → 自动合并；有任何疑问 → 升级人工。
Stripe 的逻辑是 "除非有任何疑问，否则自动合并"，这要求前置验证体系必须极其完善------再次印证 自验证循环是自动化的前提，而非可选项。
④ 熵治理：高频小 PR 对抗技术债累积
每周 1000 个只改 1--5 个文件的 PR，优于每月 100 个改 50+ 文件的大 PR。
Stripe 用 高频、小粒度、可自动审查 的变更流，持续对抗代码库的熵增------这是 ⑤ 熵治理 在运维型 Agent 场景下的最佳实践。
五、三大案例 × 六大支柱：一张总览表
| 六大支柱 | OpenAI | LangChain | Stripe |
|---|---|---|---|
| ① 上下文架构 | ⭐⭐⭐ 文档目录 + AI 可观测性 | ⭐⭐⭐ 环境注入 + 推理三明治 | ⭐ 原子任务上下文 |
| ② 架构约束 | ⭐⭐⭐ AST Linter 分层规则 | ⭐ 工作流强制 | ⭐⭐⭐ 文件/行数/禁止变更类型 |
| ③ 自验证循环 | ⭐⭐⭐ AI 互审循环 | ⭐⭐⭐ PBVF +7.1% | ⭐⭐⭐ 机器可验证审查清单 |
| ④ 上下文隔离 | ⭐⭐ Writer/Reviewer 分离 | ⭐ 单 Agent 优化 | ⭐⭐⭐ 20 并发 Minion 隔离 |
| ⑤ 熵治理 | ⭐⭐⭐ Doc Gardener + Cleanup | --- | ⭐⭐⭐ 高频小 PR 持续清理 |
| ⑥ 可拆卸性 | --- | ⭐⭐ Trace 分析 + 循环检测 | ⭐ 按任务类型分发 Minion |
六、四个跨案例的普适规律
三个团队、三种场景，提炼出四条可以写进团队 Playbook 的规律：
1. 验证比生成更重要
LangChain 用数据证明了这一点：强制验证 alone 贡献 +7.1%，超过其他四项之和。
Agent 花在"声称完成"上的时间，远多于"真正验证完成"上的时间。
2. 系统思维 > 个例修复
OpenAI 的第一原则：遇到问题，修改系统，而不是修改代码。
每次 Agent 犯错，先问"Harness 的哪个部分失效了"，而不是"这个 Prompt 怎么改"。
3. 约束是自由的前提
OpenAI 的 Linter 分层、Stripe 的文件行数限制、LangChain 的强制工作流------都是在 Harness 层 设护栏，让 Agent 在边界内更敢行动。
4. 最好的 Harness 是进化出来的
LangChain 的 Meta Trace 分析、OpenAI 的 Doc Gardener、Stripe 的持续任务扫描------都不是一次性设计，而是 失败 → 分析 → 改 Harness → 再跑 的闭环。
七、落地路线图
不必照搬 OpenAI 的五层架构。按六大支柱的优先级，分三级实施：
Level 1（马上就能做）
- 写一份 ≤60 行的 AGENTS.md，用目录引用代替全文（①）
- 加 pytest / lint CI 门禁（② + ③）
- 在 system prompt 里强制 Plan → Build → Verify 流程（③）
Level 2（有 Agent 在生产跑之后）
- 启动时 注入环境上下文（目录树、工具、超时）（①）
- 工具调用层加 死循环检测中间件（③ + ⑥）
- 探索任务用 子 Agent 隔离上下文（④）
Level 3（规模化阶段）
- 部署 Cleanup / Doc Gardener 类熵治理 Agent（⑤）
- 建立 Harness 组件注册表，模型升级时审查哪些约束可以移除（⑥）
- 引入 Trace 分析，让失败自动转化为 Harness 改进建议（⑥）
结语
OpenAI 用五层 Harness 在 5 个月里交付了百万行代码；LangChain 用五项 Harness 改进在不换模型的前提下把基准测试拉升 13.7 个百分点；Stripe 用原子化 Minion 每周自动合并上千 PR。
它们表面差异很大，底层却是同一套逻辑：模型提供智能，Harness 提供可靠性。而 六大工程支柱 就是把这套逻辑拆成你能逐项实施、逐项度量的工程清单。
下次 Agent 又"声称完成"却没过测试，别急着换模型------先检查你的 Harness，缺的是哪一根柱子。
参考资料
- 8.4 生产级案例：OpenAI、LangChain、Stripe --- 《从零开始学 Agent》
- 8.2 六大工程支柱 --- 《从零开始学 Agent》
- OpenAI Engineering Team. Harness engineering: leveraging Codex in an engineering organization. OpenAI Blog, 2026-02.
- LangChain Team. From 52.8% to 66.5% on Terminal Bench 2.0: a harness engineering case study. LangChain Blog, 2026-01.
- Stripe Engineering. Minions: autonomous agents for technical debt reduction. Stripe Engineering Blog, 2025-12.