← 目录 EN →

脚手架工程（Harness Engineering）在讨论什么：三个扩展（Scaling）维度的统一框架

1. 一个词，三件事

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）有三个独立的维度。三家各自解了其中一个。

2. 地基：三家收敛到的共同判断

在展开三个维度之前，值得先看三家在哪些地方达成了一致。这些共识构成了脚手架工程（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% 正确会导致系统停滞，一个小错误让整个系统陷入修复循环。两者都接受了”纠错比等待便宜”的权衡（trade-off）。这个判断在人类工程团队里可能引发争议，但在智能体（agent）的产出速度远超人类注意力的场景下，它是合理的工程决策。

这四条共识是脚手架工程（harness engineering）最没有争议的部分。任何一篇讨论脚手架工程（harness engineering）的文章，如果连这四条都没有涉及，大概率还在讨论别的东西。

3. 三个扩展（Scaling）维度

在上述共识的基础上，三家各自在解决一个不同维度的扩展（scaling）问题。

3.1 时间可扩展性（Scalability）：让一个智能体（Agent）连续跑几小时

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 美元，核心功能无法正常使用。

3.2 空间可扩展性（Scalability）：让几百个智能体（Agent）并行工作

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）结构可能有不同的设计考量。

3.3 交互可扩展性（Scalability）：让人用最少的介入引导（steer）大量智能体（Agent）工作

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 自动为它创建独立工作空间（全新的 git 克隆（fresh git clone） + 隔离的智能体（agent）会话（session）），派 Codex 执行任务，完成后产出工作量证明（Proof of Work）（持续集成（CI）结果、演练（walkthrough）、有时甚至包括录屏）并开拉取请求（PR）。如果智能体（agent）中途失败，BEAM 的监督树（supervision tree）处理重启和退避（backoff），其他智能体（agent）继续运行。系统可以管理数百个并发的实现运行（implementation run）。

配置通过代码库（repo）内的 WORKFLOW.md 文件完成（YAML 前言（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），大多数可以在一分钟内审阅并自动合并。

4. 三个维度之间的关系

这三个维度看起来独立，实际上有依赖关系。理解这些依赖关系，比理解每个维度本身更重要。

最关键的依赖是：空间扩展（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）的一部分工作是为不同角色匹配不同模型，这个匹配会随着模型迭代持续变化。

5. 这个框架能帮你做什么

回到开头的问题：脚手架工程（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）的讨论覆盖的是其中一端，但读者值得知道它的适用边界在哪里。

参考来源