Agent Harness死了吗？Cursor工程师深度拆解

「Agent harness 已死」——过去几个月，这句话在 AI 工程圈反复出现。Anthropic 的 Tariq 砍掉了 Claude Code 大部分系统提示，YC 的 Gary Tan 认为 harness 会消失，Cursor 团队自己也删掉了大量为弥补模型短板而设的护栏。

但 Cursor 早期核心工程师 Jediah Katz 给出了相反答案：死去的是「补智力」的旧 harness，而真正承载基础设施、信任与效率的新 harness 才刚刚开始。 他提出的「数据飞轮」和「新前沿」框架，是目前理解 harness 演进最清晰的视角之一。

什么是 Agent Harness：模型的眼睛与手

Jediah 把 harness 定义为「包裹模型、操控模型、并将它连接世界」的那层系统。用户通过应用连接 harness，harness 再连接模型、计算机和第三方服务（如 MCP）。

他将其拆为两层：

• Runtime 层：决定 agent 循环在哪里运行、状态如何存储以便任务恢复。这层更像传统软件工程，强调稳定性与可恢复性。
• Context 与编排层：决定何时调用哪个模型、模型看到什么上下文。包括提示词、工具，也包括记忆、压缩等容易被忽视的技巧。Jediah 称之为「狂野西部」。

理解这个分层，是判断「harness 是否已死」的前提——因为两层受到模型进化的冲击完全不同。

证据：模型变强，harness 的增益确实在消失

2025 年中，Cursor 用名为 Grind Swarm 的长时运行 harness 从零构建了一个浏览器，多模型、多机器编排，代价是「让 Cursor 挂了一两次」。那是 harness 的巅峰时刻。然而仅几个月后，「harness 已死」的声音就起来了。

支撑这一判断的不只是从业者的直觉，还有实证研究。据 Jediah 引用的两项研究：

• UC Berkeley 的研究：用 7 个前沿模型在 Pi、Codex、Claude Code 等多种 harness 上测试，发现对于较新的、更聪明的模型，harness 的选择在 SWE-bench Lite 得分上没有显著差异。
• Apple 与 EPFL 的联合研究：同样发现专用 MLE harness 在 MLE-bench 上带来的差异不大。

Jediah 坦率承认这一结论：「花哨的 harness 在当下不再增加编码智力，这是真的。」过去那些教模型探索代码库、长时间持久工作、跑测试验证结果的护栏，模型已经原生吸收了。

SWE-bench Lite 与 MLE-bench 是上述两项研究使用的评测基准，理解它们的构造有助于判断结论的适用范围。SWE-bench 由普林斯顿大学等机构提出，从真实 GitHub 仓库中抽取 issue 与对应的修复补丁，要求 agent 生成能通过隐藏测试的代码改动；Lite 是其筛除歧义样本后的精简版本，约 300 题，成本可控因而被广泛用于 harness 横评。MLE-bench 则由 OpenAI 推出，取材于 Kaggle 竞赛，考察 agent 完成数据清洗、特征工程、训练与提交的端到端机器学习工程能力。两者的共同点是：任务定义清晰、成功信号可自动判定，因此特别适合衡量「编码智力」。但这也意味着它们难以反映长时间运行、权限边界、人机协作与成本约束等 harness 真正擅长的维度——这正是研究显示 eval 得分趋同、而每任务成本仍有显著差异的原因。

数据飞轮：harness 如何让自己变得多余

这是整场演讲最核心的机制。Jediah 称之为「数据飞轮」：

1. harness 把越来越难的编码任务变得可及；
2. 更多用户能借助 agent 有效尝试这些任务，产生更多编码数据；
3. 数据回流给模型实验室，模型原生学会这些技能；
4. harness 删除原本用于让任务跑通的补丁。

这个循环解释了一个反直觉现象：harness 的最大成功，是让自己的一部分功能被淘汰。 但飞轮并未在此终止——当编码能力被模型商品化后，恰恰是 harness 开启下一个前沿，让飞轮重新转动。

为什么 harness 没死：两个不可替代的理由

理由一：harness 开启新前沿

Jediah 以 GrokBot 为例——一个面向知识工作的自主同事产品，采用长时存活的协调者 bot 编排一组 worker agent 的 harness，类似「高级律师配一队律师助理」。

有趣的反转是：在 Cursor 里团队不断删除提示词和护栏，而在 GrokBot 里他们重新加回这些东西。原因是新领域（制作演示文稿、预订差旅、通信、判断「行动还是询问」、跨时间记忆）模型还没掌握，harness 是让这些任务变得可行的关键。

这一逻辑也延伸到软件工程本身：资历越深的工程师写代码越少，harness 要覆盖的是编码之外的职责。更进一步是「软件工厂」——bug 上报后自动分诊、启动云 agent 修复、留下前后对比视频、合并部署后由另一个 agent 监控生产。这本质上是一个元 harness，编排多个 agent 协同完成完整开发生命周期。

理由二：模型无法吸收的部分

• 基础设施与运行时：任务时长已从分钟级扩展到小时、天甚至更长，不可能跑在一台会休眠的笔记本上，必须云端常驻。
• 信任与安全：一个只有 bash 和你全部 API key 的极简 harness 确实能解编码题，但没人愿意把密钥交给模型。权限需要收窄到特定 agent 和特定人员，还需要防止「一觉醒来出现灾难性操作或一万美元 API 账单」的护栏。
• 效率：前述两项研究虽然发现 eval 得分差异不大，但都发现每任务成本差异显著。Jediah 透露自己近一个月专注优化 GrokBot 的缓存命中率、token 效率和模型组合，在不损失质量的前提下大幅降低了成本、提升了速度。

MCP（Model Context Protocol） 是文章中 harness 连接第三方服务的标准通道，由 Anthropic 于 2024 年末提出并开源。它定义了一套客户端—服务器协议：外部工具、数据源或服务以实现 MCP server 的方式暴露能力（如读写数据库、调用工单系统、访问文件），而 harness 作为 MCP client 将这些能力以统一格式注入模型上下文。其价值在于把「每家服务一套私有插件」收敛为可复用的接口层，使 harness 不必为每个集成单独适配。不过 MCP 只解决「能力如何被描述和调用」，并不解决权限收窄、审计与成本控制——这些仍属于 harness 自身的职责，也解释了为何 Jediah 认为基础设施层不会被模型吸收。

缓存命中率与 token 效率 之所以成为 harness 优化的重点，与主流大模型 API 的计费与推理机制直接相关。多数厂商对请求前缀提供 prompt caching：若连续请求的开头部分（系统提示、工具定义、早期对话）完全一致，这部分可按大幅折扣计价甚至跳过重复计算，同时显著降低首 token 延迟。反之，任何细微改动都会使缓存失效，成本与延迟随之回升。因此 harness 在设计上下文时需刻意保持前缀稳定、把易变内容后置，并控制历史压缩策略。这也说明「每任务成本差异显著」并非偶然：同样的模型与任务，不同的上下文编排可以带来数倍的成本差距，而这部分能力无法被模型权重吸收。

下一步：harness 的五个演进趋势

Jediah 对未来的判断可以归纳为几点：

• 飞轮在加速，产品再次跑在模型前面，harness 会先变乱再变整洁，因此设计上要让功能「易上易下」。
• 对用户暴露的 harness 内部细节越来越少。他引用「Hiram 定律」：暴露给用户的东西，用户就会依赖。减少可见性换来更低的变更管理成本和更快的迭代。
• 为 agent 设计原语（primitives）。例如统一的「订阅」原语，让 agent 响应 Slack 消息、CI 变红或特定时间等事件，而非为每种事件做单独集成。
• 中心化追踪 shim。那些为修补模型行为而加的确定性护栏（如提醒「用户在等你」）会被集中记录，当某个 shim 不再触发，监控 bot 会自动提 PR 建议清理。
• 抽象层级上移。上一代 harness 由一串 LLM 调用组合而成，新一代 harness（如 GrokBot 和软件工厂）以 agent 为基本构建块。
• 六个月内 90% 的 agent 工作将离开笔记本，跑在云端。

结语：旧 harness 已死，新 harness 长存

Jediah 的结论锋利而辩证：让 harness 变聪明的部分确实死了，那是飞轮在起作用；但 harness 作为开启新任务前沿、提供信任、效率与基础设施的载体，不会消失。

对构建者而言，这意味着一个务实的方向：不要再去写教模型如何编码的护栏——那会被下一个 checkpoint 吞掉；把精力放在 runtime 可靠性、权限安全、成本效率，以及为新领域设计可组合的原语上。昨天的 harness 已死，明天的 agent harness 万岁。