前Cursor工程师：Agent Harness死了吗？数据飞轮与三样吸不走的东西

Agent Harness 的三年演变：从提示词工程师到 Harness Engineering

如果你在关注 AI Agent 领域，最近一定频繁听到两种声音：一种说 Harness 已死，另一种说 Harness 比以往更重要。前 Cursor Agent Harness 团队工程师 Jediah Katz 在 AI Engineer 的一场分享中，系统梳理了这个概念的演变与争论。

按照 Katz 的回顾，2023 年初最火的头衔是 Prompt Engineer，2025 年中演变为 Context Engineer——用代码在运行时动态拼出最优上下文。直到最近，业界才最终定名 Agent Harness 和 Harness Engineering。

Harness 的角色可以理解为模型的"眼睛和手"：它包裹在模型外面，把模型和现实世界连接起来。用户通过应用连到 Harness，Harness 再把模型连到电脑和 MCP 等第三方服务。Katz 把 Harness 拆成两层：Runtime 层负责核心循环在哪里跑、状态怎么存，让工作可以随时接着做；Context and Orchestration 层决定何时调用哪个模型、模型能看到什么上下文，包含提示词、工具、记忆、上下文压缩等大量工程技巧。

Agent Harness 是包裹在基础模型外部的软件层，负责将模型与现实世界（用户、工具、文件系统、第三方服务）连接起来。它通常包含两个子层：Runtime（核心循环的执行环境、状态持久化、任务恢复）和 Context & Orchestration（提示词构造、工具调用、记忆管理、上下文压缩、多模型路由等）。可以把它类比为操作系统之于 CPU：模型提供原始智能，而 Harness 决定这种智能如何被调度、约束和扩展。

Harness Engineering 则是指专门设计和优化这一层的工程实践，涉及提示词工程、工具设计、护栏（guardrail）设置、成本优化等，目标是在模型能力边界内最大化任务成功率与安全性。

Harness 的巅峰与"死亡"宣言

Katz 提到 Cursor 曾推出一套名为 GrindStorm 的多模型 Harness，为协调大量 Agent 和机器做出了一次浏览器演示，成本高到让 Cursor 一度宕机。但巅峰只持续了几个月，"Harness 已死"的声音就开始出现。

支持这一说法的证据来自多个方向：Anthropic 的 Tariq 提到他们把 Claude Code 的 System Prompt 删掉了一部分；YC 的 Gary Tan 认为 Harness 会逐渐消失，最后只有 Skill 重要；Katz 自己和同事也拆掉了 Cursor 里那些用来弥补模型智能短板的护栏——比如曾专门放一个小模型把代码改动写进文件，因为当时的前沿模型干不好这件事。

研究层面也有佐证。据 UC Berkeley 的一项测试，七种前沿模型在 Claude Code、Codex 等不同 Harness 上的 SWE-Bench Lite 分数没有显著差异，模型越新差异越小。Apple 和 EPFL 的研究在 M1 Bench 上得出了类似结论。

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

Katz 的核心解释是"数据飞轮"：Harness 让越来越难的编码任务变得可完成，更多用户因此真正用 Agent 去尝试这些任务，更多编码数据被分享给模型实验室，模型最终原生学会了这些技能——于是 Harness 可以把当初为跑通任务而加的东西删掉。

他举的例子很具体：教模型怎么探索代码库、怎么用斜杠命令、怎么长时间持续工作、怎么跑测试检查自己的工作。这些曾是 Harness 的职责，现在模型已经原生吸收。所以"Harness 死了"的准确含义是：花哨的 Harness 不再能给模型增加编码智能。

但这只是故事的一半。Katz 明确给出答案：Harness 没有死，理由有两个。

数据飞轮（Data Flywheel）在此语境下指一个自我强化的循环：Harness 通过降低任务门槛让更多用户尝试 Agent，用户产生的交互数据（如代码修改、测试运行、错误修复）被反馈给模型实验室用于训练，模型能力提升后原生掌握这些技能，Harness 便可移除对应的辅助逻辑。这一机制解释了为何 Harness 的某些功能会“过时”，但同时也意味着 Harness 需要不断向模型尚未掌握的新领域迁移。

理由一：Harness 为模型打开下一个前沿

第一个理由是 Harness 在解锁模型尚未攻克的新任务。Katz 以 Grok Bot 为例——一款自主同事产品，不只写代码，而是处理各种知识工作。它的 Harness 不是一次性对话，而是由长期存活的协调者机器人编排一整支 Worker Agent 队伍，像一位律师对接客户、把活分派给助理。

有意思的反转是：在 Cursor 他们随着模型变强一直往外删提示词和护栏，但在 Grok Bot 里反而又加回了很多。原因是新领域的任务模型还没拿下：关键网站操作流程（做幻灯片、定行程）、沟通（让用户随时知道进展又不被淹没）、直接做还是先问用户、通过记忆慢慢学会用户的工作方式。

Katz 还提到"软件工厂"（Software Factory）的例子：有人在频道里报 bug，自动化立刻做分诊，启动云端 Agent 尝试修复，调用工具录下修复前后对比视频证明问题解决，部署后 rollout 产品再启动另一个 Agent 在生产环境盯着。这近乎是一个 meta-harness，把很多 Agent 编排在一起。

理由二：三样模型吸不走的东西

第二个理由是 Harness 里有些部分模型吸收不掉。Katz 列出三样：

基础设施与 routing。 Agent 处理典型任务的时长已从几分钟变成几小时、几天甚至更长，这不可能跑在某人的笔记本上。想要自主同事，就必须跑在云上。

信任与安全。 一个只有 bash、把所有 API key 放在一个文件里的简单 Harness 也能完成编码任务，但没人愿意真把密钥交给模型。企业需要权限收窄到具体 Agent 和具体的人，还需要护栏防止灾难性操作或天价账单。

效率。 前面两项研究虽然发现 Harness 对评测分数影响不大，但都发现每个任务的成本存在显著差异。Katz 过去一个月专注优化 Grok Bot 的缓存命中率、token 效率和模型组合，显著降本提速且质量不打折。

海勒姆定律（Hyrum's Law）由 Google 工程师 Hyrum Wright 提出，原意是：当 API 有足够多的用户时，无论文档如何规定，所有可观察的行为都会被某些用户依赖。Katz 将其引申到 Harness 设计：一旦产品暴露了内部机制（如特定的提示词结构或工具调用方式），用户就会基于这些机制构建工作流，导致后续难以更改。因此现代 Harness 倾向于隐藏内部实现，只暴露稳定的抽象接口。

Katz 的四个预判

对于 Harness 的走向，Katz 给出几点判断：

飞轮正在加速，产品迭代速度又一次跑到模型前面，Harness 在被清理干净之前会先变得更乱。因此造 Harness 时要设计得更容易上线也更容易下线新功能。他引用海勒姆定律：暴露给用户的任何东西，用户最终都会依赖上它——所以现在产品暴露给用户的 Harness 内部机制越来越少。

为 Agent 设计原语（primitive）成为趋势。Katz 团队做了一个"订阅"原语：与其为 Slack 消息、CI 变红、定时事件各做一套集成，不如做一套框架和工具，让模型或 Agent 自己订阅事件。

他们用 sim 集中管理确定性护栏，每个 sim 被触发都会记录，机器人盯着看板，一旦某个 sim 不再触发就自动提 PR 清掉。

Harness 正在走向更高抽象层级：上一代是把一堆 LLM 调用组合起来，新一代把 Agent 当作核心构建单元。Katz 还预测，6 个月之内 90% 的 Agent 工作会跑在笔记本之外。

Primitive（原语）在 Agent 设计中指一套最小化、可组合的基础能力单元。Katz 团队设计的“订阅”原语即是一例：不分别为 Slack 消息、CI 事件、定时任务写集成，而是提供一个通用的事件订阅框架，让模型或 Agent 自行订阅所需事件。原语化的好处是降低集成复杂度、提高复用性，并使 Harness 更容易适应新场景。这类似于编程语言中的基础类型和操作符，通过组合原语可以构建出丰富的行为。

结论

Katz 的收尾很干脆：让 Harness 更擅长编码的部分，死了，那是数据飞轮在起作用；但 Harness 是 Agent 解锁下一个工作前沿的方式，而信任、效率、基础设施哪都不会去。昨天的 Harness 也许已经死了，明天的 Agent Harness 万岁。