Agent Harness 已死？模型变强后，Harness 的价值何在

要点：Agent Harness 是否已被更聪明的模型淘汰？前 Cursor 工程师 Jediah Katz 在 AI Engineer NYC 的演讲中给出了一个反直觉的答案：淘汰的只是过时的 Harness 层，而 Harness 本身正在开启新一轮任务边界。

从提示词到 Harness：一个概念的演化史

Jediah Katz 的职业生涯恰好踩在了 AI 工程范式的转折点上。2025 年初加入 Cursor 时，他负责的是当时还被称为「Prompt Engineering」的工作；到 2025 年中，这个角色演变成了「Context Engineering」——程序化地为模型拼装最优上下文；直到最近，行业才正式用「Agent Harness」和「Harness Engineering」来命名他和团队一直在做的事。

Harness 是什么？Jediah 用了一个形象的比喻：它是模型的「眼睛和手」。用户通过应用连接 Harness，Harness 再连接模型、计算机和 MCP 等第三方服务。他将其拆为两层：Runtime 层（控制 agent 循环运行位置、状态存储，确保工作可恢复）和 Context & Orchestration 层（决定调用哪个模型、模型看到什么上下文，包括提示词、工具、记忆、压缩等）。前者更像传统软件工程，后者则是「狂野西部」——也是大多数人谈论 Harness 时所指的部分，正是 Jediah 的主战场。

Context Engineering 指的是不修改模型权重、仅通过程序化方式为模型构造最优输入上下文的工程实践，涵盖系统提示词、工具描述、检索到的记忆、对话历史压缩策略等。它区别于早期的 Prompt Engineering：后者聚焦于手工打磨单条提示词的措辞，而 Context Engineering 把上下文视为需要在运行时动态拼装和管理的资源，强调在有限上下文窗口内做取舍与排序。随着 agent 任务变长，上下文会不断膨胀，如何压缩历史、何时注入记忆、如何让工具 schema 保持精简，都成为独立于模型能力之外的工程问题，这也是 Harness 中 Context & Orchestration 层的核心工作内容。

「Harness 已死」论的证据链

高峰出现在新年之际。Cursor 宣布用名为 Grind Swarm 的长运行 Harness 从零构建了一个浏览器——这个多模型 Harness 编排大量 agent 和机器，成本极高，甚至一度拖垮了 Cursor 自身的基础设施。

然而仅仅几个月后，社区风向骤变。Anthropic 的 Tariq 谈到了从 Claude Code 中删除了大量系统提示；YC 的 Gary Tan 认为 Harness 将消退，只有 skills 才重要；Jediah 自己和同事 Stefan 也撰文描述了 Cursor 移除大量「护栏」的过程——比如曾经需要一个小模型专门将代码编辑应用到文件（因为前沿模型不擅长此道），以及各种编码专用指令（如何探索代码库、如何检查工作）。

这些声音的共同论点是：更聪明的模型正在杀死 Harness。

证据似乎很充分。UC Berkeley 的一项研究用七种前沿模型测试了 Pi、Codex、Claude Code 等多个 Harness，发现在较新、较聪明的模型上，Harness 的选择对 SWE-bench Lite 分数没有显著影响。Apple 和 EPFL 的另一项研究同样发现，专用的 MLE Harness 在 MLE-bench 上也没有带来大的差异。

Jediah 对此的回应出人意料地坦诚：「一个花哨的 Harness 在今天确实不再增加编码智能。这是真的，我知道这很令人惊讶。」

SWE-bench Lite 是 SWE-bench 的精简子集，包含数百个来自真实开源仓库的 GitHub issue，要求系统生成能通过对应测试的补丁。它被广泛用作衡量编码 agent 端到端解决真实软件工程问题能力的基准。MLE-bench 则把基准对象换成了机器学习工程：任务来自 Kaggle 竞赛，要求 agent 完成数据探索、特征工程、模型训练与提交等完整流程。这两个基准的共同特点是评估的是「系统整体」而非「模型单次输出」，因此天然适合用来检验 Harness 的贡献——当研究者控制模型不变、只替换 Harness 时，分数差异就反映了 Harness 层的边际价值。

数据飞轮：Harness 如何让自己过时

为什么会出现这种情况？Jediah 提出了一个核心概念：数据飞轮。

Harness 将越来越难的编码任务变得可及，更多用户能用 agent 有效地尝试这些任务，于是更多编码数据被共享给实验室，模型最终原生学会了这些技能——然后 Harness 就可以删掉当初为了让任务跑通而添加的那些东西。

这是一个自我淘汰的循环。也正因如此，人们才会说「Harness 已死」。

但 Harness 真的死了吗？两个理由说不

Jediah 的答案是否定的，理由有二。

理由一：Harness 正在开启新的任务边界

他以 Cursor 的新产品 Grokbot 为例。这是一个「自主同事」，不仅做编码，还处理各类知识工作。它的 Harness 采用长生命周期的协调者 bot，编排一支 worker agent 舰队——就像雇了一位高级律师，直接与你对接、掌握策略，但把具体任务分派给一群律师助理。

有趣的反转在于：Cursor 在编码场景中不断删除提示词和护栏，但在 Grokbot 中却重新加回了这些东西。原因是新领域中的任务模型还没掌握：制作幻灯片、预订差旅、自主沟通（既要让你了解进展又不能信息过载）、行动与询问的边界（比如给同事发邮件这种有风险的操作要按你的意图执行）、通过记忆学习你的工作方式。这些任务在编码 agent 中或许不新鲜，但对 Grokbot 的用户而言普遍且关键——而此刻正是 Harness 让它们变得可行。

这补全了数据飞轮的最后一块拼图：当编码等能力被模型商品化后，恰恰是 Harness 解锁新的前沿任务，再次启动飞轮。新的前沿可能是编码之外的领域，也可能是软件工程工作中编码之外的部分——毕竟职位越高，写代码越少。

另一个例子是「软件工厂」愿景：多个 agent 协调完成完整软件开发生命周期。在 Cursor 内部，bug 报告到频道后，自动化立即分类，启动云 agent 尝试修复，agent 留下修复前后的视频证据，部署后 rollouts 产品再启动另一个 agent 监控生产问题。这像一个「元 Harness」，编排众多 agent 协同工作。

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

首先是基础设施与运行时。过去一年多，agent 任务时长从几分钟到几小时、几天甚至更长。这不可能跑在某人的笔记本电脑上——电脑会休眠。真正的自主同事必须运行在云端。

其次是信任与安全。一个只有 bash 和明文 API 密钥的简单 Harness 确实能解编码任务，但你大概不想把所有 API 密钥交给模型——就算你愿意，安全主管也会有话说。企业需要将权限细化到特定 agent 和特定人员，也需要护栏来避免某天早上醒来面对灾难性操作或一万美元的 API 账单。

最后是效率。前述两项研究虽然都发现 Harness 选择对评估分数影响不大，但两项研究同样发现每任务成本存在显著差异。Jediah 上个月专注于优化 Grokbot Harness 的效率，通过调整缓存命中率、token 效率、模型组合等变量，在不损失质量的前提下显著降低了成本和延迟，用户反馈积极。随着你用 agent 做越来越多的工作，最高效的 Harness 将越来越有价值。

垫片（shim） 在软件工程中原本指一层薄薄的兼容代码，用于在不改动底层系统的前提下弥合接口差异。在 Harness 语境中，shim 指的是确定性的补丁式逻辑——比如在模型响应过慢时插入一个催促、在特定工具调用失败时强制重试、或对输出格式做后处理修正。它们之所以存在，是因为当前模型在某些环节还不够可靠，而团队又不愿等到下一个模型版本。shim 的问题是会随模型进步而过时，堆积过多会让 Harness 变得难以维护，因此需要集中登记并持续监测其触发频率，一旦某个 shim 长期不再生效就及时移除。

下一步：Harness 的四个趋势

飞轮正在加速，产品再次跑在模型前面。 这意味着 Harness 会先变得更乱再被清理，更多功能会被快速发布。因此团队需要以「易于上架和下架功能」的方式设计 Harness。一个体现是暴露给用户的 Harness 内部机制越来越少——受 Hyrum 定律影响（暴露给用户的东西终将被依赖），减少可见性虽有取舍，但能降低变更管理负担、加快迭代。

为 agent 设计原语（primitives）。 原语是可组合、可扩展的构建块接口。有了原语，添加新功能不会让 agent 更困惑，删除功能也无需复杂重构。例如 Cursor 各 agent Harness 中的「订阅」原语：agent 需要响应事件唤醒（Slack 有人发帖、PR 上 CI 变红、特定时间点），与其为每种场景做独立集成，不如提供一个统一框架和工具让 agent 订阅事件。

集中管理「垫片」（shims）。 确定性的护栏本质上是补丁——比如 Grokbot 响应不够快时给个小推动。团队不愿保留这些 hack，但也不想等下一个模型检查点。于是他们集中追踪所有 shims，模型每次使用都会记录。现在有个 bot 监控仪表盘，当某个 shim 不再触发时，agent 会自动提交 PR 说「这个 shim 可以清理了」。

Harness 向更高抽象层级迁移。 上一代 Harness 由一堆 LLM 调用组合而成；Grokbot 和软件工厂这类新 Harness 则以 agent 为核心构建块。Jediah 还预测：六个月内，90% 的 agent 工作将不在笔记本电脑上运行——这已是既定方向，也是实现真正自主 agent 的必要条件。

结语

回到最初的问题：Harness 死了吗？Jediah 的回答是分层的：让 Harness 更擅长编码的那些部分，确实死了，那是飞轮在起作用；但 Harness 作为解锁下一任务前沿的方式，以及它带来的信任、效率与基础设施，不会消失。「昨天的 Harness 或许已死，但明天的 Agent Harness 万岁。」