Agent Harness 已死？Cursor 早期工程师拆解 AI 编程代理真实架构

从提示工程到 Agent Harness：一个术语的进化史

如果你在过去两年里关注 AI 编程工具，大概已经注意到一个现象：每当模型能力跃升一次，围绕它的工程实践就会被重新命名一次。Jediah 是 Cursor 早期加入的工程师，也是团队中负责 agent harness 时间最长的人，最近随 Cursor 被收购加入 SpaceX。他在一次技术分享中，把这个演变过程梳理得很清楚：2023 年初最抢手的头衔是 prompt engineer，到 2025 年中期变成了 context engineer——专门负责在运行时为模型拼装最佳上下文，而直到今年年初，行业才终于用 agent harness 和 harness engineering 来描述他团队一直做的工作。

这个命名延迟本身就有意思。它说明外界先看到的是模型，后来才意识到真正决定体验的往往是模型外面那层"壳"。Jediah 把 harness 比作模型的"眼睛和手"：用户通过应用连接到 harness，harness 再把模型接到计算机和 MCP 等第三方服务上。他进一步把 harness 拆成两层——runtime 层负责 agent 在哪里运行、agent loop 怎么走、状态怎么存以便恢复，这部分「很像传统软件工程」；而 context 与 orchestration 层则是「狂野西部」，决定什么时候调用哪个模型、模型看到什么上下文，包括 prompt、工具、记忆、compaction 以及各种不为人知的技巧。Jediah 本人主要工作在这一层。

峰值之后：为什么所有人都在说 harness 已死

今年年初 Cursor 曾到达一个「harness 峰值」：团队用一个叫 Grind Swarm 的长时运行 harness 从零做出了一个浏览器，这个多模型 harness 编排了大量 agent 和机器，运行成本极高。Jediah 坦言，为了做出那个 demo，Cursor 大概宕机了一两次。

但峰值之后风向转得很快。Anthropic 的 Tariq 谈到他们删掉了 Claude Code 系统提示中的很大一部分，YC 的 Gary Tan 认为 harness 会逐渐消失、只有 skills 才重要，Jediah 自己和同事 Stefan 也写过他们如何移除 Cursor 中那些用来弥补模型智力缺口的护栏——比如曾经要用一个小模型专门把代码编辑应用到文件上，因为前沿模型做不好这件事；还有各种编码专用指令，教模型如何探索代码库、如何检查自己的工作。

这些声音的共同逻辑是：模型变聪明了，所以 harness 死了。而且有实证支撑。据 Jediah 引用的两项研究，UC Berkeley 的一项工作在 SWE-bench Lite 上测试了七种前沿模型搭配 Pi、Codex、Claude Code 等不同 harness，发现对新模型而言 harness 的选择对分数没有显著影响；Apple 与 EPFL 的另一项研究同样发现，专用的 MLE harness 在 MLE-Bench 上也没有带来大的差异。

SWE-bench（Software Engineering Benchmark）是评估 AI 编程能力最常用的基准之一，它从 GitHub 上真实的开源仓库中收集 issue 与对应的修复补丁，要求模型在给定代码库和 issue 描述的情况下自动生成能通过测试的补丁；SWE-bench Lite 是其精简子集，保留约 300 个任务，以降低评测成本。MLE-Bench 则把这一思路搬到机器学习工程：它由 OpenAI 提出，收录 Kaggle 上真实的机器学习竞赛题目，要求 agent 从数据探索、特征工程到训练与提交完整跑通流程，衡量的是端到端的实验工程能力而非单点代码生成。这两个基准的共同点在于把「模型能力」和「模型外层的脚手架」放在同一个分数里评估，因此当研究者比较同一模型搭配不同 harness 的得分时，实际上是在分离这两个来源——也正因如此，它们成为「harness 是否还重要」这场争论的核心证据来源。

数据飞轮：harness 正在让自己变得多余

Jediah 对这一证据的解读很坦诚：花哨的 harness 在今天确实不再增加编码智力，这一点是真的。过去 harness 做的那些补丁——教模型探索代码库、用 slash goal 之类机制让它长时间坚持、跑测试检查工作——模型已经原生吸收了。

他把背后的机制称为数据飞轮。harness 让越来越难的编码任务变得可触及，更多用户因此能借助 agent 实际去做这些任务，于是更多编码数据回流到实验室，模型原生学会这些技能，最终 harness 可以删掉当初为了让任务跑通而加的东西。这个循环解释了为什么「harness 已死」的说法会出现，也解释了为什么它只对了一半。

压缩（compaction）是长时运行 agent 的关键机制。模型的上下文窗口有限，当对话或任务历史超出预算时，harness 必须决定丢弃什么、保留什么、把哪些内容总结成更短的表示，这一过程就是 compaction。它不同于简单的截断：好的 compaction 会保留任务目标、已确认的事实、失败的尝试和当前计划，同时把冗长的工具输出压缩成摘要，从而让 agent 在多小时的自主工作中不丢失关键状态。这也是为什么 Jediah 把 compaction 归入 context 与 orchestration 层——它既是工程技巧，也直接影响 agent 能持续工作多久、成本多高。随着模型原生支持更长上下文和更好的记忆管理，原有的 compaction 策略往往会被简化或替换，这正是数据飞轮在 harness 内部发挥作用的一个具体例子。

反方论点一：harness 打开任务的新边疆

Jediah 明确说 harness 没死，给出两个理由。第一个是 harness 为模型解锁了新的任务前沿，他以 Grokbot 为例——这是他们做的自主同事产品，不只写代码，还覆盖各类知识工作，用长生命周期的协调者 bot 编排一组 worker agent。他打了个比方：像请一位高级律师直接对你负责、掌握策略，但把具体任务分派给手下的律师团队。

有趣的反转在于：在 Cursor 里团队一直在删 harness 中的东西，删提示、删护栏；但在 Grokbot 里，他们反而把很多这类东西加了回去。原因在于新工作方式和新领域中有大量模型尚未掌握的任务，比如制作幻灯片、预订差旅等关键网站流程，比如自主同事需要在不淹没你的前提下同步进展，比如行动与询问的边界——Grokbot 可以替你给同事发邮件，但必须按你意图的方式发，再比如通过记忆随时间学习你的工作方式。

这些任务对写过编码 agent 的人来说并不新鲜，但对 Grokbot 而言重要得多，因为每个人都有类似需求，而目前正是 harness 让这些任务变得可行。把这一环接回数据飞轮：当编码这类能力被模型商品化之后，是 harness 解锁新前沿、让模型去解决，从而再次启动飞轮。另一个例子是软件工厂——多个 agent 协作覆盖完整软件开发生命周期。Jediah 描述了内部的形态：有人在频道里报 bug，自动化立即分诊，随后云 agent 尝试修复并用工具生成修复前后的视频作为证明，合并部署后由 rollouts 产品再起一个 agent 监控生产问题。这几乎是一个编排众多 agent 的元 harness。

反方论点二：有些东西模型吸收不了

第二个理由是 harness 中有些部分模型无法吸收。Jediah 列出三类。其一是基础设施与 runtime：过去一年多，agent 处理典型任务的时长从几分钟走到几小时、几天甚至更长，这不可能跑在某台会休眠的个人笔记本上，要做真正的自主同事就必须在云端运行。其二是信任与安全：一个只有 bash 和你所有 API key 的简单 harness 确实能解编码任务，但公司需要把权限收敛到特定 agent 和特定人，也需要护栏，避免某人一觉醒来面对灾难性操作或一万美元的 API 账单。

其三是效率。前面两项研究虽然发现 harness 对评测分数影响不显著，但也都发现每任务成本存在显著差异。Jediah 说自己过去一个月专注优化 GrokBot harness 的效率，通过调整缓存命中率、token 效率和模型组合，在质量不受影响的前提下显著降低了成本、提升了速度。他的结论是：你越多地用 agent 干活，一个高效 harness 就越有价值。

提示缓存（prompt caching）是降低 agent 运行成本最重要的手段之一。在 agent loop 中，系统提示、工具定义和历史对话在每一轮都被重复发送给模型，如果每次都按全价计费，长任务成本会迅速膨胀。主流模型厂商允许把前缀部分缓存起来，命中缓存的 token 以大幅折扣计价，但缓存有生命周期、有最小长度要求，且只有前缀完全一致才能命中。因此 harness 的缓存命中率高度依赖上下文如何拼装：把稳定的内容放在前面、把变化的内容放在后面、避免在开头插入时间戳或随机 ID。Jediah 所说的效率优化，很大程度上就是在不牺牲质量的前提下重新组织上下文，使更多 token 落在缓存命中区间内，同时通过模型组合把简单步骤交给更便宜的模型。

接下来会发生什么

Jediah 给出几个趋势判断。飞轮在加速，产品再次跑得比模型快，这意味着 harness 会先变得更乱再被清理，团队需要把 harness 设计成易于上线和下线新功能。一个表现是 Grokbot 等产品越来越少向用户暴露 harness 内部运作，这呼应了 Hyrum 定律——你暴露给用户的东西，他们就会依赖——少暴露的代价是可见性下降，好处是变更管理负担更小、迭代更快。另一个表现是更重视为 agent 设计原语（primitives）：可组合、可扩展的构建块接口，加新功能不增加 agent 的复杂度，删功能不需要大重构。他们加的一个原语叫 subscriptions，让 agent 能响应事件唤醒——Slack 里有人发帖、CI 在某个 PR 上变红、或者某个时间点，都用同一套框架和工具，而不是每个集成单独做。

他还提到团队对确定性护栏的处理方式：这类补丁（比如 Grokbot 回复太慢时轻推一下）是权宜之计，但与其等下一个模型 checkpoint，不如现在修。为了让代码库不越来越乱，他们把所有 shim 集中登记，模型每次使用都会记录，然后有一个 bot 盯着仪表盘，某个 shim 不再触发时就自动提 PR 说可以清理了。此外，harness 正在向更高抽象层移动：上一代 harness 由一堆 LLM 调用组合而成，新的 harness 以 agent 为核心构建块。他预测六个月内 90% 的 agent 工作会跑在笔记本之外。

回到标题那个问题：让 harness 变得更擅长编码的那部分，确实死了，那是飞轮在起作用。但 harness 是 agent 解锁下一任务前沿的方式，它带来的信任、效率和基础设施也不会消失。昨天的 harness 或许已死，明天的 agent harness 长存。

Hyrum 定律（Hyrum's Law）由 Google 工程师 Hyrum Wright 提出，原意是：当一个 API 有足够多的用户时，无论文档如何承诺，所有可观察的行为都会被某些用户依赖，因此任何实现细节的改变都可能构成破坏性变更。Jediah 把它引申到产品层面：harness 内部暴露给用户的日志、中间步骤、工具调用细节、状态文件格式，一旦被用户看见并写进自己的工作流或脚本，就变成了事实上的接口。这也是为什么新一代 agent 产品倾向于减少对内部的暴露——代价是调试和可观测性变弱，收益是团队可以自由地增删 harness 内部机制，而不必担心破坏用户依赖。对 harness 工程师而言，这条定律意味着「暴露即承诺」，可见性设计本身就是架构决策。