[音乐]

大家好，我是杰迪代亚（Jedidiah）。我在2025年初加入Cursor团队，是负责Agent Harness的最资深工程师之一。最近，随着Cursor被SpaceX收购，我也加入了SpaceX团队。今天，我想和大家聊聊Agent Harness是如何演变到今天的形态的，以及我认为它未来的发展方向。在开始之前，我想提出一个核心问题供我们探讨：Agent Harness已经死了吗？

[清嗓子] 让我们以更自然、流畅的方式开始这场演讲。在午饭前，我想确认一下大家的“软探测器”都还开着……好吧，说正经的。故事要回到2023年初，当时“提示词工程师”是最热门的头衔；到了2025年中旬，这一角色演变为“上下文工程师”，即通过编程方式动态为模型组装最佳上下文的专家。直到今年年初，业界才确立了“Agent Harness”和“Harness工程”这两个术语，用来描述我和我的团队长期以来所做的工作。

那么，Agent Harness里究竟包含什么？Harness就像是模型的“眼睛”和“双手”。它包裹着模型，引导它的行为，并将其连接到外部世界。用户通过应用程序与我们的Harness交互，而Harness则负责将模型连接到计算机以及第三方服务（如MCP协议）。我喜欢将Harness分为两个层级：运行时层，以及上下文与编排层。

运行时层构成了Harness的基础设施。它控制着核心Agent循环的运行位置，以及如何存储状态以便工作能够恢复。构建这一基础与传统软件工程非常相似。而上下文与编排层则更像是一片“狂野西部”。这也是人们谈论Harness时主要指代的部分。这些部分决定了何时调用哪些模型，以及它们能看到什么样的上下文信息。

这当然包括提示词和工具，还包括记忆压缩技术，以及许多你可能不知道的我们用来引导Agent按预期行为运作的技巧。这也是我主要工作的领域。在新的一年伊始，我们似乎达到了Harness工程的巅峰。Cursor宣布我们完全从头开始构建了一个浏览器，使用的是一个新的长期运行 Harness，名为“Grind Swarm”。

这是一个多模态Harness，它协调了大量的Agent和机器，运行成本非常高。实际上，为了演示这个功能，Cursor甚至可能宕机了一两次。然而，就像Agent领域的任何事物一样，在达到Harness的巅峰后仅仅几个月，网上就开始有人声称“Harness已死”。Anthropic的Tariq谈到他们如何删除了Claude Code中的大部分系统提示词；YC的Garry Tan认为Harness将会消失，只有技能（Skills）才重要。

甚至我和同事Stefan也撰文提到，我们移除了Cursor中许多用于修补模型智能短板的“护栏”机制。过去，我们会使用一个小模型来应用代码编辑到文件中，因为前沿大模型在这方面表现不佳。我们还拥有各种特定的编码指令，例如如何探索代码库以及如何检查工作成果。因此，如果所有这些人都说Harness已死，他们的意思是更聪明的模型杀死了它。

确实有很多证据支持这一观点。我想请大家思考一个非常简单的Harness场景：模型只能访问Shell以及我所有的密钥。（顺便提醒，请不要截图这张幻灯片，这是禁区。）在座有多少人认为这样一个极其简单的Harness在进行编码评估时，能表现得和更复杂的Harness一样好？也许有些人举手表示同意。有多少人认为会这样？请举手的同学示意一下。

只有少数人举手，但大多数人心里清楚答案。最近有几项研究试图调查这个问题。加州大学伯克利分校的一项研究在包括Pi、Codex和Claude Code在内的多种Harness上测试了七种不同的前沿模型。他们发现，特别是在更新、更聪明的模型上，Harness的选择对SweetBench Light的评分并没有产生显著差异。

另一项来自苹果和洛桑联邦理工学院（EPFL）的研究也得出了类似的结论：专用的MLE Harness在MLEBench上并没有带来显著的性能提升。那么，这里到底发生了什么？Harness真的死了吗？他们说得对吗？我认为证据表明：在当今时代，复杂的Harness不再能增加编码智能。这一点我是同意的，我知道这令人惊讶。

但是，我们过去在Harness中用来修补模型原始编码肌肉记忆短板的那些手段——比如教它如何探索代码库、如何通过类似“/goal”指令持久地长时间工作、以及如何运行测试来检查工作成果——这些技能已经被模型原生吸收了。为什么会发生这种情况？事实证明，Harness实际上通过一种我称之为“数据飞轮”的过程正在让自己变得多余。

在这个过程中，Harness使得越来越难的编码任务成为可能。此时，更多用户可以利用Agent productive地尝试这些任务。这意味着更多的编码数据被共享给实验室（模型训练方）。最终，模型原生地学会了这些技能。当模型变得足够强大时，Harness甚至可以删除那些最初为了让任务运行而必须执行的操作。这是一个非常有趣的过程。

这就是为什么人们会说Harness已死。如果模型足够聪明，能在任何Harness中很好地编码，那你在乎什么呢？使用哪个Harness真的重要吗？Harness真的死了吗？我的回答是否定的，原因有两个。首先（我会详细阐述这两点），Harness实际上为模型开辟了任务解决的新前沿领域；其次，有些任务或Harness的某些部分（特别是上下文层之外的部分）是模型无法吸收的。

首先谈谈Harness如何解锁下一个前沿领域，我想聊聊Grokbot。在座有多少人试用过Grokbot？让我看到一些举手的人……太棒了，很好。对于那些还没试过的人来说，Grokbot是我们的一位自主同事，它能为你完成工作。不仅仅是编码，还包括各种知识性工作。我强烈推荐大家尝试一下。我不会做太多推销，但这是一款开创性的新产品，它已经创造了一个全新的类别。我们只谈谈Harness部分：Grokbot采用了一种新型 Harness，它不基于一次性操作运行。

聊天机器人，但长期运行的协调者机器人可以编排一群工作代理。你可以将其想象为聘请一位强大的律师，他直接与你打交道并拥有策略权，但他将任务外包给一组 paralegals（律师助理）。这就是 Grockbot 框架的一个有趣之处。我提到过，在 Cursor 中我们发现随着模型变得更聪明，我们不得不从框架中移除一些东西，比如提示词和护栏。但有趣的是，在 Grockbot 中，我们实际上发现自己在重新添加很多东西，增加新的提示词和护栏。这是因为在这种新的工作方式中，在 Grockbot 旨在解决的新领域里有很多新任务，而模型尚未完全掌握。

举几个例子来说明我们目前专注于 Grockbot 的一些事情：关键的网站流程，如制作幻灯片和预订旅行；沟通方面。自主同事需要让你了解它一直在做什么，而不会让你感到不堪重负。“行动”与“询问”是另一个重点。Grockbot 可以做很多在某些意义上有风险的事情，比如给你的同事发邮件。你希望我们能做到这一点，但你只希望我们以你预期的方式去做。当然，通过记忆随着时间推移学习你的工作方式也是另一个重点。

所以，那些可能已经用代码代理拓展边界的人可能会注意到这些任务都不是新的。但对于 GrokBot 来说，它们变得更加重要，因为每个人都在某种程度上需要这些功能。目前正是框架使这些任务变得可行。当然模型是其中很大一部分，但框架正在帮助将这些能力纳入其自身范围。回到我们的数据飞轮例子，GrokBot 让我们填补了循环中的最后一个箭头：当编码这样的能力被模型商品化时，实际上是框架解锁了一个新前沿供模型去解决，并再次启动飞轮。

这可能看起来像是承担代码领域之外的新任务，就像我们刚才在 GrokBot 中看到的那样；或者仅仅意味着承担软件工程中超越纯编码的任务。我相信这里的有些人可能在软件工程职业生涯中已经相当资深了，你们可能知道职位越高，实际做的编码工作就越少。所以工作中还有很多其他重要的事情需要考虑。这是我希望大家理解的核心思想：这个飞轮以及模型和框架如何共同驱动它。

关于框架如何解锁新前沿的另一个例子是，你们中的一些人可能听说过“软件工厂”的概念，即多个代理协调合作以解决整个软件开发生命周期。虽然这还远非一个已解决的愿景，但在框架层面行业正在发生大量创新。举一个可能如何体现的例子：内部有很多渠道，有人可能会向该渠道报告错误，然后自动化系统立即对该错误进行自动分类。接着它可能启动一个云代理来尝试修复该错误，该代理将使用我们的工具展示前后视频以证明已修复。

然后一旦修复部署或合并并开始运行，我们拥有发布产品（rollouts product），它会启动另一个代理在生产环境中监控任何问题。所以你可以将所有这些视为几乎像一个元框架（meta harness），它将许多代理编排在一起。这就是我希望大家看待这种方式的角度。所以，你应该关注框架的第一个原因是：前沿的框架对于处于代理任务的前沿是必需的。

第二个原因是，框架中有一些部分是模型无法吸收的。让我们谈谈这些部分。首先是需要让自主同事可靠的底层基础设施和运行时环境。在过去的一年多里，我们从代理处理典型任务只需几分钟发展到几小时、几天甚至更久。显然这在可能会休眠的个人笔记本电脑上无法工作，如果你真的想要一个自主同事，它必须在云端运行。

接下来是信任和安全问题。是的，就像我们之前看到的，一个简单的框架仅包含 bash 和所有 API 密钥文件就能解决编码任务，但你可能不想把所有 API 密钥都交给模型。或者如果你对此无所谓，我敢肯定你的安全主管会有意见。因此这显然非常重要：我们希望拥有针对特定代理和特定人员限制权限的公司环境；同时也需要护栏，以防有人某天醒来发现发生了灾难性的操作或产生了 10,000 美元的 API 费用。

最后是效率问题。回想我之前展示的两项研究，其中框架的选择对评估分数没有显著影响，但这两项研究实际上都发现任务成本存在显著差异。在过去一个月里我专注于优化 Grok Bot 框架的效率。通过调整变量如缓存命中率、提高令牌效率以及模型组合，我们显著降低了 Grok Bot 的成本和速度，且未对质量造成任何影响。用户对此非常赞赏，看到这一点真的很棒。

现在虽然关于如何做到这一点的细节可以单独做一次演讲，但关键要点是：你使用代理来工作的越多，拥有最高效的框架就越重要、越有价值。到现在你可能已经确信框架仍然很重要了。那你可能会问：“接下来是什么？”这里有几个我预期的趋势：首先，这个飞轮正在加速，我们现在进入了一个新时代，产品再次比模型发展得更快。这意味着框架在变得整洁之前会变得更加混乱，会有更多的东西被发布出来。

因此我们预计人们将构建和设计他们的框架以便于快速上线和下线新功能。我们已经看到的一种表现形式是，在 Grok Bot 和其他类似产品中暴露给用户的框架内部工作机制越来越少。你们中的一些人可能听说过 Hyrum's Law（海拉姆定律），它指出任何你暴露给

用户最终会依赖这些系统。显然，给予用户更少的可见性是有权衡的，即他们对正在发生的事情了解得较少，但一个优势是减少了需要处理的变化管理，并且可以更快地进行迭代。

目前我们看到的这一趋势的另一种表现形式是更加专注于为智能体设计基础组件（Primitives）。这些基础组件类似于构建模块的接口，可以被组合和扩展以形成强大的功能。拥有基础组件后，你可以在不使智能体变得复杂的情况下添加新功能，也可以在无需对代码库进行繁琐重构的情况下移除功能。这仅仅是良好的工程实践。

在我们智能体框架中引入的一个基础组件示例被称为“订阅”。智能体需要一种根据事件唤醒的机制。这些事件可能包括有人在 Slack 中发帖、该智能体关注的拉取请求（PR）上的持续集成（CI）状态变红，或者是特定的一天中的某个时间。

与其为每件事设置单独的集成，我们采用了一个框架和一个工具供模型或智能体使用来订阅事件。此外，我们还做了一件很酷的事情：我之前提到过我们拥有确定性的护栏来修补模型的不良行为。例如，如果 GrokBot 没有足够快地响应用户，我们可能会给它一点提示说：“嘿，用户在等你。”

虽然这些做法有点像黑客手段，但我们宁愿现在就修复它们，也不愿等待下一个模型检查点的发布。为了使代码库不那么混乱并减少未来迭代时的麻烦，我们集中跟踪所有这些被称为“垫片”（shims）的东西。每当模型使用其中一个时，它都会被记录日志。

现在有一个机器人监控这个仪表盘，一旦某个垫片不再触发，该模型或智能体就会提交一个拉取请求（PR），指出这个垫片可以清理掉了。我认为框架的下一步发展是向更高层次的抽象迈进。上一代框架是通过组合大量的 LLM 调用来构建的，而我们现在看到的新框架（如 GrokBot 和软件工厂）则是将智能体作为核心构建模块。

最后，我预测在六个月内，90% 的智能体工作将在笔记本电脑上运行。事情已经朝着这个方向发展了，我认为这对于实现真正能够按照我们期望方式与我们协作的自主智能体来说是必不可少的。

那么，框架死了吗？那些让它变得更擅长编码的部分确实如此，这是飞轮效应在起作用。但是，正如我们所见，框架是智能体解锁工作新前沿的方式。此外，框架带来的信任、效率和基础设施都不会消失。因此，昨天的框架可能已经死亡，但明天智能体框架万岁。