Harness Engineering 的四大问题——三个 Scaling 维度的统一框架

来源: 微信公众号 + 多篇一手源 | 日期: 2026-04-07 原文: Harness Engineering 的四大问题 精读日期: 2026-04-07

本文整合了以下一手源进行交叉阅读：

一句话总结

Harness Engineering 不是一个概念，而是三个独立的 scaling 问题——时间（agent 怎么跑更久不崩）、空间（几百个 agent 怎么并行不乱）、交互（人怎么管得过来）——OpenAI、Cursor、Anthropic 各解其一，用同一个词讲着三件完全不同的事。

核心内容

一、混乱的根源：一个词，三件事

2026 Q1，三家公司几乎同时发布了 agent-first 开发的实践报告，都被归入”Harness Engineering”这顶帽子下。但细读三篇原文，它们讲的几乎是完全不同的工程问题：

• OpenAI：环境设计——文档体系、架构约束、可观测性基础设施
• Cursor：协调架构——几百个 agent 怎么分工、并行、收敛
• Anthropic：运行时纠偏——一个 agent 连续跑几小时怎么保持方向

鸭哥在博文中首先提出了这个洞察，微信原文作者将其进一步展开并加入了大量个人实践体感和对中文互联网洗稿现象的批判。

二、四条共识地基

在分化之前，三家在以下判断上达成了完全一致。这四条是后续所有分化的基础：

1. 人的核心工作从写代码变成设计 agent 的工作环境

OpenAI 原文最直接：三人团队五个月合并约 1500 个 PR，每人每天 3.5 个，零行手写代码。“Humans steer. Agents execute.” 团队的主要工作变成了：当 agent 做不好某件事时，问”环境里缺什么能力”而不是”怎么改 prompt”。

“When something failed, the fix was almost never ‘try harder.’ Human engineers always stepped into the task and asked: ‘what capability is missing, and how do we make it both legible and enforceable for the agent?’” —— Ryan Lopopolo, OpenAI

2. 知识必须版本化、可发现、存在于 repo 中

OpenAI 的教训最深刻：Codex 看不到的等于不存在。Google Docs 里的讨论、Slack 上的对齐、人脑里的隐含知识，对 agent 全是空白。他们把 AGENTS.md 从”百科全书”简化为”目录表”——大约 100 行，只做指引，深度知识推入 docs/ 结构化目录。

苏黎世联邦理工的研究证实了一个反直觉结论：LLM 自动生成的 AGENTS.md 反而让性能下降 20%+。手写的 60 行以内文件远好于自动生成的冗长版本——太长太泛太多废话，占上下文但不提供有效约束。

3. 约束比指令有效

OpenAI 用自定义 linter 强制执行分层架构（Types → Config → Repo → Service → Runtime → UI），lint 错误信息本身就是给 agent 的修复指引。Cursor 发现 “no TODOs, no partial implementations” 比 “remember to finish implementations” 有效得多。

Thoughtworks 的 Birgitta Böckeler 在 Martin Fowler 网站上发表的文章提供了一个更系统的心智模型：将 harness 分为 Feedforward（前馈） 和 Feedback（反馈） 两类控制，每类再分为 Computational（确定性） 和 Inferential（推理性）。确定性约束（linter、类型检查、架构测试）能可靠捕捉结构问题；推理性控制（AI code review、LLM-as-judge）处理语义问题但更贵且非确定性。

4. 完美主义是吞吐量的敌人

OpenAI：“corrections are cheap, and waiting is expensive.” Cursor 发现要求每次 commit 100% 正确会让系统停滞——一个小错让整个系统陷入修复循环。两家都接受了”纠错比等待便宜”的权衡。

Cursor 的数据：允许稳定的小错误率后，错误”arise then get fixed quickly, the error rate remains small and constant”，系统自然收敛。

三、维度一——时间 Scaling：让一个 Agent 跑几小时不崩（Anthropic）

核心问题：长时间运行引发两类 prompt 和文档防不住的失败。

失败模式一：方向漂移

上下文窗口填满后，模型一致性衰减。Anthropic 在 Sonnet 4.5 上观察到强烈的”context anxiety”——模型在接近自认为的上下文极限时提前结束工作。compaction（压缩）不够，因为不能给模型一个”干净的石板”。

失败模式二：自评失真

Agent 能发现自己产出的缺陷，但随后说服自己这些缺陷可以接受。Anthropic 原话：“agents tend to respond by confidently praising the work—even when, to a human observer, the quality is obviously mediocre.”

解法：GAN 启发的三角色架构

Evaluator 的关键：不是读代码，而是像用户一样操作——导航、点击、截屏、打分。Sprint contract 在开工前由 Generator 和 Evaluator 协商确定”完成标准”。

Anthropic 原文中的 Evaluator 调校过程极有价值：开箱即用的 Claude 是很差的 QA agent。它会识别问题，然后合理化，最后批准。需要多轮人工审阅 evaluator 的日志，找到判断偏差点，逐步调整 prompt，几轮后才达到合理的评判水平。

最核心的洞察：harness 组件的生命周期管理

每个 harness 组件本质上是对当前模型能力边界的一个假设。这些假设有不同的过期速度：

“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, both because they may be incorrect, and because they can quickly go stale as models improve.” —— Prithvi Rajasekaran, Anthropic

Harness 的演化方向不是越来越厚，而是随模型进步不断减薄。 每次新模型发布，应该做的第一件事是去掉一些组件看看会不会出事，而不是继续往上堆。

数据对比：

$9 的废物 vs $124 的可用产品——ROI 是无穷大。

四、维度二——空间 Scaling：让几百个 Agent 并行不乱（Cursor）

核心问题：能否通过投入 10x 计算获得 10x 有意义吞吐量？

基准任务：从零用 Rust 构建 web 浏览器引擎，数百个 agent 并行跑一周，超过百万行代码。

四次架构迭代的失败记录（这是全文最有价值的部分）：

第一次：扁平化自协调（失败）

所有 agent 地位平等，共享状态文件 + 锁协调。分布式系统经典方案，但在 agent 场景下迅速崩溃。Agent 持锁太久、忘记释放、尝试非法锁操作。20 个 agent 的吞吐量退化到 1-3 个。

更深层的行为问题：没有层级时，agent 变得回避风险，只做安全的小改动，困难问题无人认领。“With no hierarchy, agents became risk-averse. They avoided difficult tasks and made small, safe changes instead.”

第二次：结构化角色（瓶颈）

分出 Planner、Executor、Worker、Judge 四角色。改善明显但被最慢的 Worker 瓶颈住，且前置规划太刚性，无法动态调整。

第三次：连续执行器（角色过载）

Planner 合并进 Executor。结果角色过载导致病理行为——随机休眠、停止生成任务、自己动手写代码、声称已完成。一个 agent 同时承担”规划、探索、研究、派发任务、检查 worker、审查代码、执行编辑、合并输出、判断完成”——太多冲突目标挤一个 context 窗口。

微信作者的洞察：“人类在这种情况下会摸鱼，agent 在这种情况下会抽风。”

第四次：递归 Planner-Worker（成功）

线性扩展的三个关键： 1. 规划可并行：递归 Planner 避免单点瓶颈 2. 执行完全隔离：每个 Worker 独立 repo 副本，消除锁竞争 3. 去中心化质量控制：移除了集中式 Integrator（瓶颈），接受稳定小错误率

关键数据：峰值约 1000 commits/hour，横跨 10M tool calls，一周内无需人工干预。

两个重要额外发现：

1. 项目架构影响 agent 效率：将 monolith 重构为多个独立 crate 后，编译等待大幅缩短，吞吐量成倍提升。为 agent 优化的 repo 结构和为人类优化的可能不同——人可以等 30 秒编译，几百个 agent 同时编译是灾难性 I/O 瓶颈。

2. 模型选型比想象中重要：GPT-5.2 在长时间自主运行中表现优于 Opus 4.5。Opus 4.5 的问题是”stops earlier, takes shortcuts when convenient, yields control quickly”。模型聪不聪明和模型肯不肯干是两回事。

五、维度三——交互 Scaling：让人管这一切不累死（OpenAI + Symphony）

核心问题：agent 产出速度远超人类注意力带宽时，人应该通过什么界面来 steer 整个系统？

OpenAI 的三层减负：

第一层：让 agent 自我验证

通过 Chrome DevTools Protocol 让 agent 看到 DOM 快照和截屏，每个 worktree 配独立可观测性栈（Victoria Logs/Metrics/Traces）。“ensure no span in critical user journeys exceeds two seconds” 变成 agent 可执行的指令，不需要人盯 dashboard。

第二层：机械化约束替代人工 review

自定义 linter 强制执行架构不变量，lint 错误信息写成 agent 能理解的修复指引。Agent 凌晨三点跑了 7 小时，架构完整性也不会被破坏。人类的 review 逐步被 agent-to-agent review 循环取代。

第三层：自动化熵管理

编码”黄金原则”，定期跑后台 agent 扫描偏离、开修复 PR，大多数一分钟内审阅自动合并。团队原来每周五花 20% 时间清理”AI slop”，改用自动化后这个负担消失。

Symphony：从写 prompt 到写 ticket

2026 年 3 月开源的 Symphony 把人类的交互简化为 ticket 驱动：

工程师写 ticket → ticket 移到 Todo → Symphony 自动创建独立工作空间
→ 派 Codex 执行 → 产出 Proof of Work（CI 结果 + walkthrough）
→ 开 PR → agent 中途挂了，BEAM supervision tree 处理重启

选 Elixir/BEAM 不是情怀——BEAM 的 supervision tree 天然适合管理大量长时间运行、随时可能挂的独立进程。配置通过 repo 内的 WORKFLOW.md 完成（YAML frontmatter + Liquid 模板化 prompt），agent 策略跟代码一起版本控制。

人类的交互变得极度稀疏：上游写 ticket + 维护 harness，下游 review Proof of Work + PR。反馈循环的重心从纠正 agent 的具体产出，转向改进 harness 本身——更好的测试、文档、约束在所有未来 agent run 中复利。

六、三个维度之间的依赖关系

鸭哥和微信作者都认为这部分比维度本身更重要：

空间 scaling 放大时间 scaling 的问题

一个 agent 跑偏，后果局限在一个 PR。几百个同时跑，每个都在漂移、自我合理化，错误以并行度的倍数积累。Cursor 实践中确实遇到了——需要定期 scratchpad 重写和 context summarization。

Anthropic 的独立评审 vs Cursor 的系统自愈，哪个更优目前没定论。微信作者的判断：独立评审捕捉方向性偏差更强，系统自愈处理实现层小错更高效。

交互 scaling 依赖前两者的成熟度

Symphony 能让人通过写 ticket steer agent，前提是单个 run 足够可靠（时间维度）且系统能同时管理大量 run（空间维度）。如果每个 run 都需人中途干预，ticket 驱动就退化成批处理。

跨维度：模型适配比想象中重要

Cursor 发现 GPT-5.2 长时间自主优于 Opus 4.5，Anthropic 记录了三代模型上 harness 组件的淘汰路径。Harness engineering 的一部分工作是为不同角色匹配不同模型，这个匹配随模型迭代持续变化。

七、OpenAI 五条原则的工程含义

微信原文对这五条做了深度重新解读，而非简单引用：

八、Thoughtworks 的补充框架：Feedforward vs Feedback

Birgitta Böckeler 的文章提供了一个正交于三维度框架的分类体系：

           Feedforward (前馈)          Feedback (反馈)
          ┌──────────────────┐    ┌──────────────────┐
确定性    │ Code mods         │    │ Linters, Tests    │
(Computational) │ Bootstrap scripts │    │ ArchUnit tests    │
          └──────────────────┘    └──────────────────┘
          ┌──────────────────┐    ┌──────────────────┐
推理性    │ AGENTS.md, Skills │    │ AI code review    │
(Inferential) │ 编码规范文档     │    │ LLM-as-judge     │
          └──────────────────┘    └──────────────────┘

她的核心洞察：

• Harnessability（可驯服性） 不是所有代码库都一样的。强类型语言天然有类型检查作为 sensor；清晰的模块边界支持架构约束规则。Greenfield 可以从第一天就内建 harnessability，Legacy 系统最需要 harness 但最难建。
• Harness Templates 可能成为未来企业工程的标准——一套预定义的 guides + sensors，绑定到特定的技术栈和架构拓扑。
• Ashby 定律：调节器必须至少有与被调节系统同等的多样性。承诺一种拓扑是多样性缩减（variety-reduction），使全面 harness 变得可行。

九、二手源的实战补充

三篇二手源各自贡献了一手源中没有的独特视角：

LangChain：只改 harness 不换模型，Terminal Bench 2.0 从 Top 30 到 Top 5

这是迄今最干净的控制实验。模型固定为 GPT-5.2-Codex，只调整 harness（系统 prompt、工具、中间件），分数从 52.8% 提升到 66.5%，排名飙升 25+ 位。关键发现：

• Self-verification 是最大杠杆：最常见的失败模式是 agent 写完代码，重读一遍，觉得”看起来没问题”就停了。加入 PreCompletionChecklistMiddleware（退出前强制跑验证）效果显著。
• Reasoning “三明治”策略：规划阶段用 xhigh reasoning，实现阶段用 high，验证阶段再拉回 xhigh。比全程 xhigh 好——全程高推理反而因超时得分更低（53.9% vs 63.6%）。
• Trace-driven 改进循环：用 agent 分析自己的 trace 来发现系统性失败模式，类似 boosting——聚焦上一轮的错误案例。

HumanLayer：Sub-agents 是”上下文防火墙”

HumanLayer 一年实战的核心结论：Sub-agents 的价值不在于模拟”前端工程师/后端工程师”的角色分工（这不 work），而在于 context isolation。每个 sub-agent 在独立的小 context 窗口里处理离散任务，只有浓缩结果回流到父线程，避免中间噪音污染主线程。

他们的实用经验： - CLAUDE.md 保持 60 行以内，手写，不自动生成 - 太多 MCP 工具是有害的——工具描述填满 context，把你推入”dumb zone” - 验证机制必须 context-efficient——早期他们让 agent 跑完整测试套件，4000 行通过的测试淹没了 context window，agent 开始对着测试文件幻觉。改为”成功静默，只显示失败” - Hooks 做确定性控制——退出前自动跑 formatter + typecheck，有错误就逼 agent 继续修，成功则完全静默

LangChain Anatomy：Harness 与模型的共进化

Vivek Trivedy 指出一个微妙的动态：前沿 coding model 是在其 harness 上做 post-training 的（Claude 在 Claude Code 上训练，GPT-5 Codex 在 Codex harness 上训练）。这造成了过拟合——Codex 模型和 apply_patch 工具紧密耦合，换到其他 harness 性能就下降。

但过拟合是双刃剑：Opus 4.6 在 Claude Code 中排 Terminal Bench #33，换一个 harness 反而到 #5。这意味着 模型的”最佳 harness”不一定是它被训练的那个。

十、框架的边界

微信作者和鸭哥都明确指出了适用边界：

不在框架内的讨论： - 两年前的 multi-agent 虚拟团队（“AI 模拟产品经理、设计师”）——跟 Cursor 让几百个同质 agent 并行编码完全是两回事 - 换了皮的 Prompt Engineering——把 system prompt 叫做 harness 的一个”组件” - 纯概念讨论——Agent = Model + Harness 配马和缰绳，然后就没了

判断文章质量的快速标准：有没有讨论失败模式。只有成功故事和原则总结的文章，大概率还没进入这个领域的核心。

更根本的边界：三个维度的 scaling 解决的都是偏头部需求——极复杂系统、大型基础设施。对大多数普通开发者，AI 对软件更深远的影响可能在另一方向：让软件本身变得更简单、更一次性、更贴合具体需求。当交付物从成品软件变成 Generative Kernel 时，harness engineering 的重要性会下降——因为需要被 harness 的系统复杂度本身在降低。

金句摘录

• “Agent 看不到的东西不存在。” —— OpenAI
• “Agents tend to respond by confidently praising their own work—even when, to a human observer, the quality is obviously mediocre.” —— Anthropic
• “No TODOs, no partial implementations” 比 “remember to finish implementations” 有效得多。—— Cursor
• “模型聪不聪明和模型肯不肯干是两回事。” —— 微信原文
• “人类在这种情况下会摸鱼，agent 在这种情况下会抽风。” —— 微信原文
• “Corrections are cheap, and waiting is expensive.” —— OpenAI
• “Every component in a harness encodes an assumption about what the model can’t do on its own.” —— Anthropic
• “The interesting work for AI engineers is to keep finding the next novel combination.” —— Anthropic
• “下次有人跟你说 harness engineering 时，可以先问一句：你在解哪个维度的 scaling？如果答不上来，大概率还在聊缰绳和马。” —— 微信原文
• “The next time your coding agent isn’t performing the way you expect, before you blame the model, check the harness. It’s just a skill issue.” —— HumanLayer
• “We went from Top 30 to Top 5 on Terminal Bench 2.0. We only changed the harness.” —— LangChain
• “A coding agent has no social accountability, no aesthetic disgust at a 300-line function, no intuition that ‘we don’t do it that way here.’” —— Birgitta Böckeler, Thoughtworks

Justin 视角

对投资判断的参考价值

1. Infra 层的投资机会清晰化。三个维度各自催生不同的基础设施需求：

   • 时间 Scaling → Evaluator-as-a-Service、Agent QA 平台（对标 Anthropic 的三角色）
   • 空间 Scaling → Agent 编排引擎、隔离执行环境（对标 Cursor 的递归 Planner-Worker）
   • 交互 Scaling → Agent 调度平台（对标 OpenAI 的 Symphony）
   • 但要注意：这些能力正在被三大厂内化，独立创业的窗口期可能很窄

2. “Harness 随模型减薄”意味着 pure-play harness 公司面临平台风险。如果每次模型升级都淘汰一层 harness，那建在特定 harness 需求上的商业模型可能很脆弱。更有韧性的方向是：解决那些不随模型进步消失的问题——比如 Evaluator（自评失真在三代模型上都存在）和 Entropy Management（熵增是热力学定律，不会因为模型变强而消失）。

3. 模型选型的复杂化是一个信号。Cursor 发现不同模型适合不同角色，这意味着未来的 agent 系统是多模型混编的。路由/适配层可能是一个有价值的中间件位置。

4. “为 agent 优化的 repo 结构”是一个被低估的方向。Cursor 发现从 monolith 重构为多 crate 后吞吐量成倍提升。这暗示未来可能出现”Agent-Native Software Architecture”的新范式——不是为人类可读性优化，而是为 agent 可操作性优化。

与当前工作的关联

我们自己用 Claude Code 的实践直接映射到这个框架： - CLAUDE.md + skills 系统 = OpenAI 的”给地图不给手册” + 知识推入 repo - hooks 机制 = Feedforward/Feedback 控制的确定性约束 - cross-review skill = 弱化版的 Evaluator（但没有 Anthropic 那样的完全状态隔离）

可以行动的 takeaway： - 审视现有 skill 和 CLAUDE.md，问”哪些约束是确定性可执行的”，能改成 hook/linter 的就改 - 在模型升级时，主动做”减法实验”——移除一个 harness 组件，看输出是否真的变差 - 关注 Symphony 的开源实现，可能是我们 cc-remote 项目的参考架构

值得进一步深挖

• OpenAI Symphony 的开源代码和架构细节
• ETH Zurich 论文关于自动生成 AGENTS.md 的性能退化数据
• Cursor 的 Rust 浏览器项目开源代码——作为 multi-agent 大规模协作的 benchmark
• LangChain 的 Terminal Bench 2.0 结果——只改 harness 不换模型，排名从前 30 到前 5

延伸阅读

一手源（已精读）

• OpenAI: Harness Engineering — Ryan Lopopolo, 2026-02-11
• Cursor: Towards Self-Driving Codebases — Wilson Lin, 2026-02-05
• Cursor: Scaling Long-Running Autonomous Coding — Wilson Lin, 2026-01-14
• Anthropic: Harness Design for Long-Running Apps — Prithvi Rajasekaran, 2026-03-24
• 鸭哥: Harness Engineering 在讨论什么 — yage.ai, 2026-03-30

二手源（已参考）

• Martin Fowler / Thoughtworks: Harness Engineering for Coding Agent Users — Birgitta Böckeler, 2026-04-02
• LangChain: The Anatomy of an Agent Harness
• LangChain: Improving Deep Agents with Harness Engineering
• HumanLayer: Skill Issue - Harness Engineering for Coding Agents

值得追踪的人物/公司

• Ryan Lopopolo (OpenAI) — Symphony 架构师，agent-first 开发的先行者
• Wilson Lin (Cursor) — multi-agent 空间 scaling 的核心研究者
• Prithvi Rajasekaran (Anthropic Labs) — GAN 启发的 evaluator 架构设计者
• Birgitta Böckeler (Thoughtworks) — 企业级 harness 工程的系统化思考者
• 王巍 (onevcat) — iOS 开发者，在 Let’s Vision 大会分享了 AI Agent 实践，公开了完整 PDF 和流程