Agent框架已死？Cursor工程师用数据反驳

Agent Harness 真的死了吗？一场来自 Cursor 工程师的硬核拆解

最近，B站上一位UP主翻译的演讲视频引发了AI编程圈的讨论。演讲者是Cursor的资深工程师Jediah，他自2025年初加入Cursor，是agent harness（智能体框架）团队任职最久的工程师，近期因公司被SpaceX收购而一并加入。他在演讲中直面一个尖锐的问题：Agent Harness是不是已经死了？

这个问题的背景是，过去几个月里，多位行业意见领袖公开唱衰harness——Anthropic的Tariq说他们删掉了Cloud Code的大部分系统提示词，YC的Gary Tan认为harness会消退、只有skills才重要。连Jediah自己和同事都写过文章，讲他们如何移除了Cursor里那些为弥补模型智力短板而设的护栏。

Jediah没有回避这些说法，而是用研究和产品实践给出了一个更精细的答案：让harness变聪明的那部分确实在消亡，但harness本身并不会死。

从提示词工程到Agent Harness：概念的演进

Jediah先梳理了行业术语的变迁。2023年初，最火的头衔是prompt engineer（提示词工程师）；到2025年中期，变成了context engineer（上下文工程师），负责以编程方式为模型动态组装最佳上下文；而直到最近，行业才终于用agent harness和harness engineering来描述Cursor团队早已在做的工作。

他把harness拆成两层。运行时层是地基，控制核心agent在哪里运行、agent循环如何执行、状态如何存储以支持任务恢复，这部分很像传统软件工程。上下文与编排层则更像“狂野西部”，决定何时调用哪个模型、模型看到什么上下文——包括提示词、工具，还有记忆、压缩等一系列机制。这也是大多数人谈论harness时所指的部分。

SWE-bench Lite 是 SWE-bench 的精简版本，用于评估语言模型解决真实 GitHub issue 的能力。完整版 SWE-bench 包含 2294 个来自 12 个流行 Python 仓库的 task，而 Lite 版精选了 300 个任务，在保持代表性的同时大幅降低评测成本。每个任务要求模型根据 issue 描述修改代码库，并通过隐藏的单元测试验证修复是否正确。该基准已成为衡量编程 agent 实际工程能力的重要标尺，也是本文中讨论 harness 效果的核心实验平台。

“巅峰Harness”与随后的唱衰潮

Cursor曾用一个叫Grind Swarm的长时运行harness从零造出一个浏览器，多模型编排大量agent和多台机器，成本极高，甚至导致Cursor服务短暂宕机一两次。但仅仅几个月后，网上就开始说harness已死。

支撑这一观点的证据并非空穴来风。据Jediah引用，UC Berkeley的一项研究让七种前沿模型在Pi、Codex、Cloud Code等多个harness上跑SWE-bench Lite，发现在更新、更聪明的模型上，harness的选择对分数没有显著影响。Apple和EPFL的另一项研究也发现，专用的MLE harness在MLE-bench上差别不大。

Jediah承认这个结论：**花哨的harness在当下确实不再增加编程智力。**曾经需要手把手教模型的技能——探索代码库、长时间持续工作、跑测试检查结果——已经被模型原生吸收。原因在于他所说的“数据飞轮”：harness带来更难的编程任务，更多用户能借助agent完成这些任务，更多编程数据回流给实验室，模型原生学会这些技能，于是harness可以删掉当初为了跑通任务而加的补丁。

为什么harness不会死：两个核心理由

理由一：harness为模型打开新的任务边疆

Jediah以Cursor的自主同事产品GrokBot为例。它采用一种新型harness，不是基于一次性对话，而是由长生命周期的协调者bot编排一组工作agent——就像一位直接对你负责、掌握策略的资深律师，把具体事务分派给律师助理团队。

有意思的是，在Cursor里他们一直在删harness里的东西，但在GrokBot里却在加回大量提示词和护栏。因为在新场景里——制作幻灯片、预订差旅、主动沟通、区分“行动还是询问”、通过记忆学习用户习惯——模型还没掌握。这些任务让数据飞轮补上最后一环：当编程能力被模型商品化，恰恰是harness打开新边疆，再次启动飞轮。

另一个例子是“软件工厂”：bug被自动分诊、云端agent尝试修复并用前后对比视频证明、合并部署后另一个agent在生产环境监控问题。这相当于一个元harness在编排多个agent。

理由二：有些harness部件模型无法吸收

Jediah列出三类模型吃不掉的部分。

**基础设施与运行时。**agent任务从几分钟延长到数小时、数天甚至更久，不可能跑在会休眠的个人笔记本上，必须上云。

**信任与安全。**一个只有bash和明文API key的简单harness确实能解编程题，但你不会真把全部密钥交给模型。企业需要把权限收窄到特定agent和特定人员，也需要护栏防止灾难性操作或一万美金的API账单。

效率。前面两项研究虽然发现eval分数差异不大，但都发现每个任务的成本差异显著。Jediah过去一个月专注优化GrokBot harness的效率，通过调整缓存命中率、token效率、模型组合，在不牺牲质量的前提下显著降低了成本、提升了速度。

Hyrum 定律（Hyrum's Law）由 Google 工程师 Hyrum Wright 提出，意为：当一个 API 有足够多的用户时，无论你在文档中承诺什么，所有可观察的行为都会被某些用户依赖。在 agent harness 的语境下，这意味着一旦某个内部机制（如特定的提示词格式、工具调用顺序、状态存储方式）暴露给用户或开发者，就会形成事实上的契约，后续修改将面临兼容性负担。因此 Jediah 主张减少 harness 内部机制对用户的暴露面，以降低变更成本、加快迭代速度。

数据飞轮（Data Flywheel）是理解 harness 自我淘汰机制的关键概念。其循环逻辑是：harness 降低使用门槛，让更多用户借助 agent 完成更难的编程任务；这些任务产生大量高质量的编程轨迹数据（包括成功与失败的尝试、代码修改、测试结果等）；数据回流至模型实验室用于训练；模型原生习得原本需要 harness 补丁才能实现的技能；于是 harness 可以移除这些补丁。这个飞轮越转越快，导致 harness 中“教模型做事”的部分不断被商品化，但也正因如此，harness 才能腾出精力去开拓模型尚未掌握的新任务领域，再次启动飞轮。

下一步：harness将走向何方

Jediah给出几个预判。飞轮正在加速，产品再次跑在模型前面，harness会先变乱再被清理，因此需要设计得更容易上线和下线新功能。一个体现是harness内部机制对用户暴露得越来越少——借Hyrum定律，凡暴露给用户的，用户就会依赖，少暴露则变更管理更轻、迭代更快。

另一个趋势是为agent设计原语（primitives）。原语是可组合、可扩展的构建块，加功能不增加agent的复杂度，删功能也不必大动代码。他举例“订阅”原语：agent需要响应事件唤醒，比如有人在Slack发帖、PR的CI变红、或到了某个时间点，用一个框架统一处理，而不是每个都做单独集成。

他们还集中追踪所有“垫片”（shim）——那些为修补模型坏行为而加的确定性护栏，比如GrokBot回复太慢时轻推一下。每次模型触发垫片都会记录，有bot盯着仪表盘，某个垫片不再触发时，就自动提PR说可以清理了。

最后，Jediah判断harness正在走向更高的抽象层级：上一代harness由一堆LLM调用组合而成，新一代则把agent本身作为核心构建块。他还预测，六个月内90%的agent工作将跑在笔记本之外。

结论：昨天的harness死了，明天的harness长存

回到最初的问题，Jediah的答案是分层的：让harness在编程上变聪明的那部分，确实死了，那是数据飞轮在起作用；但harness作为打开新任务边疆、提供信任、效率与基础设施的载体，不会消失。用他的话说——昨天的harness或许已死，但长生命周期的agent harness万岁。

对于开发者而言，这轮讨论的实际意义在于：不必纠结于“要不要用harness”的二元问题，而应关注harness在成本、安全、长时运行和新任务域上的价值，这些恰恰是模型自己无法替代的。