日期：2026-03-30
2026 年第一季度，OpenAI、Cursor 和 Anthropic 先后发布了各自在 agent-first 软件开发上的实践报告。三篇文章都被归入同一个术语：harness engineering。但仔细读下来，它们讲的几乎是三件完全不同的事。
OpenAI 的 harness engineering 讲的是环境设计：文档体系、架构约束、可观测性基础设施，让 agent 在一个被精心设计过的工作环境里可靠地生产代码。Cursor 的 self-driving codebases 和 scaling agents 讲的是协调架构：几百个 agent 同时工作，怎么分工、怎么并行、怎么收敛。Anthropic 的 harness design for long-running apps 讲的是运行时纠偏：一个 agent 连续跑几个小时，怎么在过程中保持方向和质量。
这三篇文章的读者群高度重叠，用的术语高度一致，但各自回答的工程问题截然不同。这正是 harness engineering 这个词在当前讨论中造成混乱的根源：人们用同一个词在讨论不同层面的问题，而大量二手解读甚至还停留在两年前的 multi-agent 虚拟团队概念里，离这三篇文章的实际内容更远。
这篇文章尝试提供一个统一框架来理清这些讨论。核心论点是：harness engineering 的本质是让 AI 构建软件变得 scalable，而 scalability 有三个独立的维度。三家各自解了其中一个。
在展开三个维度之前，值得先看三家在哪些地方达成了一致。这些共识构成了 harness engineering 的地基，三个 scaling 维度是在这个地基上的分化。
人类的核心工作从写代码转向了设计 agent 的工作环境。 OpenAI 把这表述为”设计环境、指定意图、构建反馈循环”，Cursor 的实验发现”架构和指令比 harness 本身更重要”，Anthropic 发现 planner 和 evaluator 的设计比 prompt 的措辞对产出质量影响更大。三家从不同方向得到了同一个结论：人类的杠杆点在于创造让 agent 能可靠工作的条件，代码本身由 agent 产出。
知识必须版本化、可发现、存在于 repo 中。 OpenAI 最直白地说了这件事：Codex 看不到的等于不存在。Google Docs 里的讨论、Slack 上的对齐、团队成员脑子里的隐含知识，对 agent 来说统统是空白。Cursor 从另一个角度验证了同一点：指令中的模糊措辞会被数百个 agent 同时放大，后果比人类团队里的沟通模糊严重得多。解决方案都是把知识推入 repo，用 markdown 和结构化文档取代口头沟通。
约束比指令有效。 OpenAI 用自定义 linter 强制执行分层架构，lint 错误信息本身就是给 agent 的修复指引。Cursor 发现”no TODOs, no partial implementations”比”remember to finish implementations”有效得多。约束是可执行的、确定性的，指令是可解释的、模糊的。在 agent 的工作方式里，这个区别比在人类团队里更关键。
完美主义是吞吐量的敌人。 OpenAI 采用最小阻塞合并，等待比纠错更昂贵。Cursor 发现要求每次 commit 100% 正确会导致系统停滞，一个小错误让整个系统陷入修复循环。两者都接受了”纠错比等待便宜”的权衡。这个判断在人类工程团队里可能引发争议，但在 agent 的产出速度远超人类注意力的场景下，它是合理的工程决策。
这四条共识是 harness engineering 最没有争议的部分。任何一篇讨论 harness engineering 的文章，如果连这四条都没有涉及，大概率还在讨论别的东西。
在上述共识的基础上，三家各自在解决一个不同维度的 scaling 问题。
Anthropic 要解决的问题是：一个 agent 在被精心设计的环境里开始工作之后，怎么在几个小时的连续运行中保持方向和质量。
这个问题之所以独立于环境设计，是因为长时间运行会引发两类环境设计本身无法预防的失败。第一类是方向漂移：随着上下文窗口逐渐变满，模型的一致性开始衰减，表现为偏离原定方向、遗忘早期约束、在细节中越走越深。第二类是自评失真：agent 在工作过程中能发现自己产出里的缺陷，但随后会说服自己这些缺陷可以接受，给出通过判断。这两类问题需要的是运行时的独立纠偏机制，超出了 prompt 和文档能覆盖的范围。
Anthropic 的解法是一个三角色架构。Planner 把一句话需求扩展成完整的产品 spec，只做产品层面和高层技术方向的设计，不进入实现细节。Generator 按 spec 实现功能。Evaluator 拿着事先协商好的 sprint contract，用 Playwright 操作真实运行的应用来验证产出是否达标。Evaluator 和 Generator 之间没有共享的内部状态，这种独立性是它能纠偏的前提。
这个架构最有方法论价值的部分，在于它对 harness 组件生命周期的处理。每个 harness 组件都是对当前模型能力边界的一个假设。Context reset 假设模型无法在长上下文中保持一致性；sprint 分解假设模型无法在连续的长 session 中保持方向感；evaluator 假设模型会对自己的工作过度宽容。这些假设有不同的过期速度。从 Sonnet 4.5 到 Opus 4.5 到 Opus 4.6 三代模型，context reset 先被淘汰，sprint 分解随后被淘汰，evaluator 仍然有价值。作者在 Opus 4.6 发布后做的事是逐一移除旧组件、测试质量是否真的下降，而不是继续叠加新组件。
简化后的系统产出了一个数字音频工作站，运行约 4 小时，成本 124 美元，其中 generator 第一轮连续运行了 2 小时 7 分钟。对比基线：同样的 prompt 用单 agent 跑 20 分钟花 9 美元，核心功能无法正常使用。
Cursor 要解决的问题是：能否通过投入 10 倍的计算来获得 10 倍的有意义吞吐量。
他们选择了从零构建一个 web 浏览器引擎作为基准任务，用 Rust 编写，数百个 agent 并行运行一周，生成了超过一百万行代码。文章真正有价值的部分在于它坦诚记录了四次架构迭代的失败过程。
第一次尝试是所有 agent 地位平等，通过共享状态文件协调。这在分布式系统中是经典方案，但在 agent 场景下迅速失败。Agent 持锁太久、忘记释放，20 个 agent 的吞吐量退化到 1-3 个的水平。更深层的问题是行为上的：没有层级时，agent 变得回避风险，只做安全的小改动，困难问题无人负责。
第二次尝试分离了 Planner、Executor、Worker、Judge 四个角色，改善明显但被最慢的 Worker 瓶颈住。第三次把 Planner 合并进 Executor，结果角色过载导致病理行为：随机休眠、停止生成任务、自己动手写代码。
最终方案是递归 Planner-Worker 架构。根 Planner 拥有整个项目范围，当范围过大时生成子 Planner，递归进行。Worker 从 Planner 接收任务，在自己的 repo 副本上独立工作，完成后写一份 handoff（做了什么、发现了什么、有什么担忧）提交给请求任务的 Planner。Worker 之间互不感知，也不与其他 Planner 通信。信息严格向上流动。
这个架构实现了线性扩展的关键在于三点。规划层面，递归 Planner 让规划工作本身可以并行展开，避免单一 Planner 成为瓶颈。执行层面，Worker 完全隔离，各自在独立的 repo 副本上工作，消除了锁竞争。质量层面，他们移除了集中式的 Integrator 角色（它本来负责中央质量控制，但数百个 Worker 都要通过一个门才能合并代码，立刻成了瓶颈），接受一个小而稳定的错误率，让错误被其他 agent 自然修复。
峰值吞吐量约 1000 commits/hour。一个值得注意的发现是：当他们把 repo 从 monolith 重构为多个独立 crate 后，编译等待时间大幅缩短，吞吐量成倍提升。项目架构的选择直接影响了 agent 的工作效率，这意味着为 agent 优化的 repo 结构和为人类优化的 repo 结构可能有不同的设计考量。
OpenAI 要解决的问题从 harness engineering 文章延伸到了 Symphony（2026 年 3 月开源）：当 agent 的产出速度远超人类的注意力时，人应该通过什么界面来 steer 整个系统？
Harness engineering 文章本身描述的交互模式相对朴素：人写 prompt 描述任务，agent 跑（单次经常超过 6 小时，通常在工程师睡觉时执行），agent 产出 PR，通过 agent-to-agent review 循环迭代直到满意，人可以选择性地参与 review。三人团队五个月内合并了约 1500 个 PR，平均每人每天 3.5 个。
这个交互模式的 scalability 瓶颈很明显：人还是要逐个写 prompt、逐个触发任务。Symphony 解决的正是这个问题。它是一个用 Elixir/BEAM 构建的持久化守护进程，把项目管理工具（当前默认是 Linear）变成了 agent 的 job scheduler。工程师把需求写成 ticket，ticket 移到 Todo 状态时，Symphony 自动为它创建独立工作空间（fresh git clone + 隔离的 agent session），派 Codex 执行任务，完成后产出 Proof of Work（CI 结果、walkthrough、有时甚至包括录屏）并开 PR。如果 agent 中途失败，BEAM 的 supervision tree 处理重启和 backoff，其他 agent 继续运行。系统可以管理数百个并发 implementation run。
配置通过 repo 内的 WORKFLOW.md 文件完成（YAML frontmatter + Liquid 模板化的 prompt），这意味着 agent 策略跟代码一起版本控制。
这把人类的交互界面从”写 prompt 并触发”简化成了”写 ticket 并移动状态”。交互变得非常 sparse：上游是写 ticket 和维护 harness（文档、测试、架构约束），下游是 review Proof of Work 和 PR。中间的执行过程完全自主。反馈循环的重心从纠正 agent 的具体产出，转向改进 harness 本身：更好的测试、更好的文档、更好的约束。这些改进在所有未来的 agent run 中复利。
OpenAI 在 harness engineering 文章中对人类注意力的 scaling 有几层解法。第一层是让 agent 自我验证：通过 Chrome DevTools Protocol 接入、每个 worktree 独立的可观测性栈（Victoria Logs/Metrics/Traces），让”确保关键用户路径中没有超过两秒的 span”这样的高层目标变得对 agent 可执行，不需要人盯 dashboard。第二层是通过机械化约束取代人工 review：自定义 linter 强制执行架构不变量，lint 错误信息写成 agent 能理解的修复指引。第三层是自动化熵管理：编码”黄金原则”，定期跑后台 agent 扫描偏离、开修复 PR，大多数可以在一分钟内审阅并自动合并。
这三个维度看起来独立，实际上有依赖关系。理解这些依赖关系，比理解每个维度本身更重要。
最关键的依赖是：空间 scaling 会放大时间 scaling 中的问题。当你有一个 agent 在跑，方向漂移和自评失真的后果局限在一个 PR 里。当你有几百个 agent 同时跑，每个都在漂移、每个都在自我合理化，错误会以并行度的倍数积累。Cursor 在实践中确实遇到了这个问题：他们发现 agent 在长时间运行中会丧失焦点，需要定期 scratchpad 重写和 context summarization。但他们的解法偏向接受一个稳定的错误率并让系统自然收敛，而非引入独立的 evaluator。这两种策略哪个更优，目前还没有定论。
反过来，交互 scaling 依赖于时间和空间 scaling 的成熟度。Symphony 之所以能让人通过写 ticket 来 steer agent，前提是单个 agent run 足够可靠（时间维度）且系统能同时管理大量 run（空间维度）。如果每个 run 都需要人中途干预，ticket 驱动的模式就退化成了手动触发的批处理。
还有一个跨维度的共同发现：三家都在实践中发现，模型选择对角色的适配比预期更重要。Cursor 发现 GPT-5.2 在长时间自主运行中表现优于 Opus 4.5（后者倾向于提前停止和走捷径）。Anthropic 记录了从 Sonnet 4.5 到 Opus 4.6 三代模型上 harness 组件的演化路径。这意味着 harness engineering 的一部分工作是为不同角色匹配不同模型，这个匹配会随着模型迭代持续变化。
回到开头的问题：harness engineering 到底在讨论什么？
用这个框架去看，答案变得清晰。当有人说 harness engineering 时，先问：它在解决哪个维度的 scaling？是让 agent 跑更久（时间），还是让更多 agent 一起跑（空间），还是让人更省力地 steer（交互）？三个维度的工程问题不同，解法不同，trade-off 也不同。把它们混在一起讨论，注定混乱。
这个框架也能帮你判断市面上大量二手讨论的质量。如果一篇文章在讨论 harness engineering 但连这三个维度中的任何一个都没有触及，它大概率是在讨论更基础的东西：传统的 multi-agent 协作协议、两年前流行的 AI 虚拟团队概念、或者只是在用一个时髦的词包装已有的实践。这些讨论有其价值，但它们和 OpenAI、Cursor、Anthropic 正在做的事情处于不同的层面。
还有一个容易被忽略的维度。这三家讨论的 scaling 都在优化 agent 怎么工作：工作更久、同时工作更多、人更省力地管理。但 agent 工作的质量上限，很大程度上取决于它拿到了什么样的 context。同样的模型、同样的工具、同样的 prompt，接入一套经过一年积累和分层精炼的认知框架后，产出的性质会从”正确的废话”变成”有判断力的分析”。这个方向和 harness engineering 互补：harness 解决的是 agent 的工作方式和协调，context infrastructure 解决的是 agent 的认知密度。关于这个方向的详细讨论和开源参考实现，见为什么 AI 只会说正确的废话，以及怎么把它逼出舒适区。
最后值得指出一个边界。这三个维度的 scaling 解决的都是偏头部的需求：极复杂的系统、大型基础设施、甚至有实验性质的 AI 能力边界探索。对更广大的普通开发者和企业来说，他们的软件可能根本不需要几百个 agent 并行，也不需要一个 agent 连续跑 6 小时。AI 对软件的更深远影响，可能在另一个方向：让软件本身变得更简单、更一次性、更贴合具体使用者的需求。当交付物从成品软件变成支撑 AI 生成个性化应用的 Generative Kernel 时，harness engineering 解决的问题重要性会下降，因为需要被 harness 的系统复杂度本身在降低。这两个方向并行存在，服务于不同的场景。Harness engineering 的讨论覆盖的是其中一端，但读者值得知道它的适用边界在哪里。