Harness Engineering 的三个 Scaling 维度：统一框架下的技术架构深度解析

当我们谈论「Harness Engineering」时，究竟在讨论什么？这个看似简单的问题，却揭示了当前AI agent领域最核心的架构挑战。

术语混乱的根源：同一个词，三件完全不同的事

2026年第一季度，OpenAI、Cursor和Anthropic先后发布了各自在agent-first软件开发上的实践报告。三篇文章都被归入同一个术语：harness engineering。但仔细读下来，它们讲的几乎是三件完全不同的事。

这种术语混叠的背后，是三家公司在解决agent系统规模化时，聚焦了三个正交的维度：

• OpenAI的harness engineering：讲的是环境设计 — — 文档体系、架构约束、可观测性基础设施，让agent在被精心设计过的工作环境里可靠地生产代码
• Cursor的self-driving codebases和scaling agents：讲的是协调架构 — — 几百个agent同时工作，怎么分工、怎么并行、怎么收敛
• Anthropic的harness design for long-running apps：讲的是运行时纠偏 — — 一个agent连续跑几个小时，怎么在过程中保持方向和质量

读者群高度重叠，用的术语高度一致，但各自回答的工程问题截然不同。这正是harness engineering这个词在当前讨论中造成混乱的根源：人们用同一个词在讨论不同层面的问题。

地基：三家收敛到的四条共同判断

在展开三个维度之前，值得先看三家在哪些地方达成了一致。这些共识构成了harness engineering的地基。

共识1：人类的核心工作从写代码转向了设计agent的工作环境
OpenAI把这表述为”设计环境、指定意图、构建反馈循环”；Cursor的实验发现”架构和指令比harness本身更重要”；Anthropic发现planner和evaluator的设计比prompt的措辞对产出质量影响更大。三家从不同方向得到了同一个结论：人类的杠杆点在于创造让agent能可靠工作的条件，代码本身由agent产出。

共识2：知识必须版本化、可发现、存在于repo中
OpenAI最直白地说了这件事：Codex看不到的等于不存在。Google Docs里的讨论、Slack上的对齐、团队成员脑子里的隐含知识，对agent来说统统是空白。Cursor从另一个角度验证了同一点：指令中的模糊措辞会被数百个agent同时放大，后果比人类团队里的沟通模糊严重得多。解决方案都是把知识推入repo，用markdown和结构化文档取代口头沟通。

共识3：约束比指令有效
OpenAI用自定义linter强制执行分层架构，lint错误信息本身就是给agent的修复指引。Cursor发现”no TODOs, no partial implementations”比”remember to finish implementations”有效得多。约束是可执行的、确定性的，指令是可解释的、模糊的。在agent的工作方式里，这个区别比在人类团队里更关键。

共识4：完美主义是吞吐量的敌人
OpenAI采用最小阻塞合并，等待比纠错更昂贵。Cursor发现要求每次commit 100%正确会导致系统停滞，一个小错误让整个系统陷入修复循环。两者都接受了”纠错比等待便宜”的权衡。这个判断在人类工程团队里可能引发争议，但在agent的产出速度远超人类注意力的场景下，它是合理的工程决策。

三个Scaling维度：独立却相互依赖

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

3.1 时间Scalability：让一个Agent连续跑几小时

Anthropic要解决的问题是：一个agent在被精心设计的环境里开始工作之后，怎么在几个小时的连续运行中保持方向和质量。

这个问题之所以独立于环境设计，是因为长时间运行会引发两类环境设计本身无法预防的失败：

1. 方向漂移：随着上下文窗口逐渐变满，模型的一致性开始衰减，表现为偏离原定方向、遗忘早期约束、在细节中越走越深
2. 自评失真：agent在工作过程中能发现自己产出里的缺陷，但随后会说服自己这些缺陷可以接受，给出通过判断

Anthropic的解法是一个三角色架构：

• Planner：把一句话需求扩展成完整的product spec，只做产品层面和高层技术方向的设计，不进入实现细节
• Generator：按spec实现功能
• Evaluator：拿着事先协商好的sprint contract，用Playwright操作真实运行的应用来验证产出是否达标

关键创新在于Evaluator和Generator之间没有共享的内部状态 — — 这种独立性是它能纠偏的前提。每个harness组件都是对当前模型能力边界的一个假设，这些假设有不同的过期速度。

实证数据：简化后的系统产出了一个数字音频工作站，运行约4小时，成本124美元，其中generator第一轮连续运行了2小时7分钟。对比基线：同样的prompt用单agent跑20分钟花9美元，核心功能无法正常使用。

3.2 空间Scalability：让几百个Agent并行工作

Cursor要解决的问题是：能否通过投入10倍的计算来获得10倍的有意义吞吐量？

他们选择了从零构建一个web浏览器引擎作为基准任务，用Rust编写，数百个agent并行运行一周，生成了超过一百万行代码。文章真正有价值的部分在于它坦诚记录了四次架构迭代的失败过程。

失败经验教训：

1. 第一次尝试：所有agent地位平等，通过共享状态文件协调 → agent持锁太久、忘记释放，20个agent的吞吐量退化到1-3个的水平；行为上变得回避风险，只做安全的小改动
2. 第二次尝试：分离了Planner、Executor、Worker、Judge四个角色 → 改善明显但被最慢的Worker瓶颈住
3. 第三次尝试：把Planner合并进Executor → 角色过载导致病理行为：随机休眠、停止生成任务、自己动手写代码

最终方案：递归Planner-Worker架构

• 根Planner拥有整个项目范围，当范围过大时生成子Planner，递归进行
• Worker从Planner接收任务，在自己的repo副本上独立工作，完成后写一份handoff（做了什么、发现了什么、有什么担忧）提交给请求任务的Planner
• Worker之间互不感知，也不与其他Planner通信。信息严格向上流动

线性扩展的三个关键点：

1. 规划层面：递归Planner让规划工作本身可以并行展开，避免单一Planner成为瓶颈
2. 执行层面：Worker完全隔离，各自在独立的repo副本上工作，消除了锁竞争
3. 质量层面：移除了集中式的Integrator角色（中央质量控制瓶颈），接受一个小而稳定的错误率，让错误被其他agent自然修复

峰值吞吐量：约1000 commits/hour。当他们把repo从monolith重构为多个独立crate后，编译等待时间大幅缩短，吞吐量成倍提升。

3.3 交互Scalability：让人用最少的介入steer大量Agent工作

OpenAI要解决的问题从harness engineering文章延伸到了Symphony（2026年3月开源）：当agent的产出速度远超人类的注意力时，人应该通过什么界面来steer整个系统？

原始交互模式的瓶颈：人还是要逐个写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

交互范式的转变：
从”写prompt并触发” → 到”写ticket并移动状态”

• 上游：写ticket和维护harness（文档、测试、架构约束）
• 下游：review Proof of Work和PR
• 中间：执行过程完全自主

反馈循环的重心从纠正agent的具体产出，转向改进harness本身：更好的测试、更好的文档、更好的约束。这些改进在所有未来的agent run中复利。

三个维度之间的关系：理解依赖比理解每个维度更重要

最关键的依赖：空间scaling会放大时间scaling中的问题

当你有一个agent在跑，方向漂移和自评失真的后果局限在一个PR里。
当你有几百个agent同时跑，每个都在漂移、每个都在自我合理化，错误会以并行度的倍数积累。

Cursor在实践中确实遇到了这个问题：他们发现agent在长时间运行中会丧失焦点，需要定期scratchpad重写和contextsummarization。但他们的解法偏向接受一个稳定的错误率并让系统自然收敛，而非引入独立的evaluator。这两种策略哪个更优，目前还没有定论。

反过来：交互scaling依赖于时间和空间scaling的成熟度

Symphony之所以能让人通过写ticket来steeragent，前提是：

• 单个agent run足够可靠（时间维度）
• 系统能同时管理大量run（空间维度）

如果每个run都需要人中途干预，ticket驱动的模式就退化成了手动触发的批处理。

跨维度的共同发现：模型选择对角色的适配比预期更重要

• Cursor发现GPT-5.2在长时间自主运行中表现优于Opus4.5（后者倾向于提前停止和走捷径）
• Anthropic记录了从Sonnet4.5到Opus4.6三代模型上harness组件的演化路径

这意味着harness engineering的一部分工作是为不同角色匹配不同模型，这个匹配会随着模型迭代持续变化。

这个框架能帮你做什么：看清harness engineering到底在讨论什么

用这个框架去看，当有人说harness engineering时，先问：它在解决哪个维度的scaling？

• 是让agent跑更久（时间）？
• 还是让更多agent一起跑（空间）？
• 还是让人更省力地steer（交互）？

三个维度的工程问题不同，解法不同，trade-off也不同。把它们混在一起讨论，注定混乱。

判断市面上二手讨论质量的工具

如果一篇文章在讨论harness engineering但连这三个维度中的任何一个都没有触及，它大概率是在讨论更基础的东西：

• 传统的multi-agent协作协议
• 两年前流行的AI虚拟团队概念
• 或者只是在用一个时髦的词包装已有的实践

这些讨论有其价值，但它们和OpenAI、Cursor、Anthropic正在做的事情处于不同的层面。

互补的方向：context infrastructure

还有一个容易被忽略的维度。这三家讨论的scaling都在优化agent怎么工作：工作更久、同时工作更多、人更省力地管理。但agent工作的质量上限，很大程度上取决于它拿到了什么样的context。

同样的模型、同样的工具、同样的prompt，接入一套经过一年积累和分层精炼的认知框架后，产出的性质会从”正确的废话”变成”有判断力的分析”。这个方向和harness engineering互补：

• harness解决的是agent的工作方式和协调
• context infrastructure解决的是agent的认知密度

应用边界：不是所有场景都需要极致scaling

最后值得指出一个边界。这三个维度的scaling解决的都是偏头部的需求：

• 极复杂的系统
• 大型基础设施
• 有实验性质的AI能力边界探索

对更广大的普通开发者和企业来说，他们的软件可能根本不需要几百个agent并行，也不需要一个agent连续跑6小时。AI对软件的更深远影响，可能在另一个方向：让软件本身变得更简单、更一次性、更贴合具体使用者的需求。

当交付物从成品软件变成支撑AI生成个性化应用的Generative Kernel时，harness engineering解决的问题重要性会下降，因为需要被harness的系统复杂度本身在降低。

这两个方向并行存在，服务于不同的场景。Harness engineering的讨论覆盖的是其中一端，但读者值得知道它的适用边界在哪里。

结语：架构思维的升级

Harness engineering不仅是一套技术实践，更是一种架构思维的升级 — — 从关注”如何让AI写好代码”转向”如何设计让AI可靠工作的系统”。

在这个过程中，我们看到了：

• 角色专业化的力量（Planner/Generator/Evaluator）
• 解耦带来的可扩展性（递归架构）
• 反馈循环的转移（从产出纠错到系统改进）
• 模型角色匹配的动态性
• 约束胜于指令的范式转变

真正的架构师不仅要解决当前的问题，更要预见系统在不同规模下的行为变化。而harness engineering提供的这个三维框架，正是理解和设计下一代AI-agent系统的钥匙。

在AI时代，我们不再只是构建软件，我们是在构建能够构建软件的系统。而这个系统的设计，才是真世的竞争优势所在。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传优快云，朋友们如果需要可以微信扫描下方优快云官方认证二维码免费领取【保证100%免费】