Harness Engineering 落地实践（六）：一线团队案例深度解析

引言

理论听了一堆，不如看真实案例。

这一篇深入解析四个一线团队的 Harness 实践：

• OpenAI：三人、五月、百万行、零手写代码
• Anthropic：GAN 式三智能体架构
• Stripe：每周 1300+ PR 无人值守
• Mitchell Hashimoto：单人六步进阶

每个案例都揭示了一些反直觉的实践真相。

一、OpenAI：三人五月百万行零手写

1.1 核心数据

1.2 五大方法论

方法论1：给 Agent 一张地图，而不是一本千页手册

OpenAI 的 AGENTS.md 只有约 100 行，作用类似于目录，指向 docs/ 下更深层的设计文档、架构图、执行计划和质量评级。

这本质上是渐进式披露——先把最关键的信息放进来，需要什么再加载什么。

类比：你到一个新城市，不需要把整本旅游指南背下来。给你一张简明的地图，然后告诉你"想了解这个景点的详细信息，翻到第 X 页"就够了。

方法论2：架构约束不能写在文档里，必须靠工具强制执行

他们给每个业务领域定义了固定的分层结构：

Types → Config → Repo → Service → Runtime → UI

依赖方向不能反过来。怎么保证？自定义 Linter + 结构测试。违反了就报错，报错消息里不光告诉你哪里错了，还直接告诉你怎么改。

OpenAI 原话：

"If it cannot be enforced mechanically, agents will deviate."

文档中记录约束是不够的，如果不能机械化地强制执行，Agent 就会偏离。

方法论3：可观测性也是给 Agent 看的，不只是给人看的

他们把 Chrome DevTools Protocol 接入了 Agent 运行时。Agent 能自己抓 DOM 快照、截图。

日志、指标、链路追踪都通过本地可观测性栈暴露给 Agent。

这样"把启动时间降到 800ms 以下"就从模糊的愿望变成了 Agent 可以自己测量、自己验证的目标。

方法论4：熵不会自己消失，必须主动对抗

一开始团队每周五花 20% 的时间手动清理 AI 生成物中的低质量代码。

后来这事被自动化了——后台 Agent 定期扫描，找文档不一致、架构违规和冗余代码，自动提交清理 PR。

清理的速度跟上了生成的速度，才能可持续地跑下去。

方法论5：写在 Slack 里的知识，对 Agent 来说等于不存在

所有团队知识都作为版本控制的制品放置在仓库中。

⚠️ OpenAI 自己也说了，这个结果"不应该被假设为在缺少类似投入的情况下可以复现"。每一项都需要大量前期投入，但思维方式（地图式文档、机械化约束、熵管理）是可以在任何规模上立即采用的。

二、Anthropic：GAN 式三智能体架构

2.1 背景：上下文焦虑问题

Anthropic 发现了"上下文焦虑"现象：Sonnet 4.5 在上下文快填满时会变得犹豫，倾向于提前收工——即使任务还没做完。

光靠压缩上下文不够。他们的最终解法叫 Context Resets：

1. 当 Agent 上下文接近饱和时，把当前任务状态、已完成工作、待办事项结构化提取出来
2. 启动一个全新的干净 Agent
3. 把结构化的交接文档交给新 Agent
4. 新 Agent 从干净状态继续工作

这就像程序碰到内存泄漏时——不是手动释放每一个内存块，而是直接重启进程从检查点恢复。

2.2 GAN 式三智能体架构

Anthropic Labs 2026年3月发布了受 GAN（生成对抗网络）思路启发的三智能体架构：

Planner（规划者）→ Generator（执行者）⇄ Evaluator（评估者）

这个架构解决两个核心问题：

2.3 一个关键发现

当他们把模型从 Sonnet 4.5 换成 Opus 4.6 后，Sprint 机制可以完全移除，Evaluator 从每个 Sprint 检查变成了最后只做一次检查。

Anthropic 的总结非常精辟：

"Every component in a harness encodes an assumption about what the model can't do on its own, and those assumptions are worth stress testing."

（Harness 中的每个组件都编码了一个关于"模型靠自己做不到什么"的假设，而这些假设值得定期压力测试。）

随着模型变强，不需要 Harness 了？不，是 Harness 的设计空间转移到了新的位置。

2.4 两种配置的成本对比

三、Stripe：每周 1300+ PR 无人值守

3.1 核心数据

Stripe 的 Minions 系统：开发者发一条 Slack 消息，Agent 就从写代码到跑 CI 到提 PR 全部搞定，人只在最后审查。

每周超过 1,300 个完全由 Minions 生产的、不含任何人写代码的 PR 被合并。

3.2 架构拆解

编排设计思路：不是把所有事情都交给 Agent 判断，也不是全部走确定性流程，而是一个混合状态机——该确定的地方确定（跑lint、推送代码），该灵活的地方灵活（实现功能、修CI错误）。

就像一条工厂流水线，有些工位是机器人固定动作，有些工位是人工灵活处理。

3.3 "牲口不是宠物"原则

传统模式：给每台服务器命名，像宠物一样精心维护。

Stripe 模式：Devbox 是"牲口"——用完就释放回池，不维护、不命名、需要时重新分配。

Devbox 预装了源码和服务，预热池随时可用。分配一个只需约10秒。

3.4 核心理念

"What's good for humans is good for agents."

为人类工程师投资的 Devbox、工具链和开发者体验，在 Agent 上也直接产生了回报。

Agent 应该跟人类工程师用同一套基础设施，只是一开始就得被当作一等公民来设计。

四、Mitchell Hashimoto：单人六步进阶

4.1 背景

Mitchell Hashimoto（Vagrant、Terraform、Ghostty 终端模拟器的作者）的实践路线和 Stripe 完全相反——他坚持一次只跑一个 Agent，保持深度参与。

4.2 六步进阶路线

4.3 AGENTS.md 的正确用法

Ghostty 项目里的 AGENTS.md，每一行都对应着一个过去的 Agent 失败案例。

这不是写完就扔的静态文档，而是一个持续积累的防错系统——Agent 犯了一个新类型的错误，就加一行规则，以后就不会再犯了。

4.4 一句总结

"我不打算跑多个 Agent，也不想跑。我坚持一次只跑一个 Agent，保持深度参与。"

五、Carlini：16 Agent 并行写 C 编译器

5.1 核心数据

Nicholas Carlini 约两周时间，跑了 16 个并行 Claude Opus 实例，约 2000 个 Claude Code 会话，产出了一个 GCC torture test 通过率 99% 的 C 编译器。

5.2 设计决策

日志不打印只写文件：

全部日志写进文件，用 grep 友好的单行格式 ERROR: [reason]。主动控制上下文污染。

测试子采样：

每个 Agent 只跑随机 1-10% 的测试子集。但子采样对单次运行是确定性的（同一 Agent 每次跑同样的子集），跨 VM 是随机的（不同 Agent 跑不同子集）。

这样集体覆盖了全部测试，而单个 Agent 不会花几个小时在测试上打转。

Agent 角色专业化：

• 核心编译器工作
• 去重（LLM 生成的代码经常重新实现已有功能）
• 性能优化
• 代码质量和文档

5.3 Carlini 的一句话

"我必须不断提醒自己，我是在为 Claude 写这个测试框架，不是为自己写。"

Harness 的设计目标是让 Agent 高效工作，不是为了人类方便。

六、案例横向总结

共同启示：

1. AGENTS.md 当目录不当手册
2. 约束必须机械化强制执行
3. 熵管理必须自动化
4. Harness 是需要持续维护的软件

标签：#AI #Agent #HarnessEngineering #OpenAI #Anthropic #Stripe #实战案例