Harness Engineering 的三种可扩展性
原文把 OpenAI、Cursor、Anthropic 看似分散的工程实践，收束成一个更有解释力的框架：真正需要扩展的不是“代理数量”，而是任务持续时间、工作空间容量，以及人与系统之间的交互密度。
这篇文章真正统一了什么
原文试图回答一个被大量 “multi-agent” 叙事掩盖的问题：为什么 OpenAI、Cursor、Anthropic 这些看起来完全不同的实践，最后会指向同一类工程基础设施。
真正被统一的对象，不是 agent 数量，而是三种可扩展性。
- 时间可扩展性：让任务连续运行更久，跨越人工注意力边界与会话边界。
- 空间可扩展性：让更多仓库、文件、上下文和并行工作区同时进入系统。
- 交互可扩展性：把原本需要频繁人工介入的对话、审阅、切换与反馈，压缩成更高密度的系统能力。
关键规模信号
这些数字来自不同来源、不同 benchmark，但它们共同说明了一件事：系统已经不再只是回答问题，而是在工程环境中持续制造产出。
一张表看懂三个可扩展性维度
| 维度 | 核心问题 | 代表实践 | 被突破的瓶颈 | 文中可见信号 |
|---|---|---|---|---|
| 时间 | 任务如何持续运行，而不是被人工节奏打断 | OpenAI Harness、Anthropic long-running apps | 会话超时、人工等待、长链路中断 | 1500 PR / 5个月；2h07m 平均成功运行 |
| 空间 | 系统如何同时处理更大的代码库与更多工作区 | Cursor background agents、million-line benchmark | 代码库规模、上下文装载、并行工作容量 | 1000 commits/小时；100万行代码；数百 agents |
| 交互 | 人与系统之间的反馈成本如何继续下降 | 文章作者的统一归纳 | 审阅密度、切换开销、反馈延迟 | 更多自动拆分、回放、协作和异步审阅能力 |
共同地基不是“多代理”，而是工作环境设计
原文最重要的判断之一，是把 attention 从 “agent 数量” 移回 “agent 所处环境”。
这意味着，团队如果只讨论是否做多代理，而不先建设任务状态、上下文装载、审阅接口和执行边界，最后通常只会得到更昂贵的 prompt orchestration。
时间可扩展性：让任务跨越人的注意力边界
OpenAI 与 Anthropic 对同一问题给出了两种不同角度的回答：不是让模型“一次更聪明”，而是让系统“持续做事更久”。
长时运行不是 token 问题，而是 runtime 问题。
Anthropic 给出的 benchmark 尤其重要，因为它把 long-running apps 从概念拉回到了工程实况：平均成功运行时长达到 2 小时 7 分钟，最昂贵的单次运行花费 124 美元，而基线只需要 20 分钟和 9 美元。
真正的门槛不只是模型价格，而是 durable execution、状态恢复、失败回退、异步观察和人类介入点的设计。
空间可扩展性：让更多代码和更多工作区同时被纳入系统
Cursor 展示的是另一个方向的扩展：任务不一定更久，但工作空间更大、并行度更高、代码范围更宽。
- 背景 agents 峰值可达到每小时 1000 次 commit。
- 在 100 万行代码仓库中，系统可以连续运行约 1 周完成任务。
- 这类系统的关键资产不是更长的聊天记录，而是可调度的工作空间与上下文基础设施。
交互可扩展性：把人机协作压缩成系统能力
这部分不是单独 benchmark 的直接复述，而是文章作者的进一步抽象。换句话说，下面这一层带有 作者推演 属性，不是某个单一来源的官方指标。
- 更细粒度的任务拆分与自动回放。
- 更低摩擦的人工介入点，而不是整轮接管。
- 更结构化的审阅、签收、回退与继续执行。
- 更强的上下文基础设施，让人类不必重复提供同一批信息。
公开脉络在一周内迅速收束
一张图看懂三种扩展如何耦合
对团队落地的含义
- 先建设 harness，再谈 agent swarm。
- 先判断你受限于时间、空间还是交互，再决定投什么基础设施。
- 大型代码库团队优先补 context infrastructure，而不是只追更大的模型。
- 长时运行能力需要明确的人类介入点，否则成本会迅速失控。
- harness engineering 并不是所有软件的必选项；对小型、一次性、低复杂度任务，更轻量的上下文杠杆可能更划算。