角色演变与Harness的定义

Jedidiah Katz于2025年初加入Cursor，随后随公司被SpaceX收购。他回顾了从2023年“Prompt Engineer”到中期“Context Engineer”，再到年初确立的“Agent Harness/Harness Engineering”这一行业术语演变过程。Harness被比喻为模型的“眼睛和双手”，它包裹模型、引导其行为并连接外部世界。用户通过应用与Harness交互，而Harness则负责将模型连接到计算机系统及第三方服务（如MCP）。Katz将其划分为两层：作为基础的Runtime层，负责核心Agent循环的运行状态存储与工作恢复；以及被称为“狂野西部”的Context与Orchestration层，这通常也是人们谈论Harness时所指的部分。该层级控制模型调用的时机、可见上下文，包括提示词、工具使用以及记忆压缩等复杂技巧。在2025年初的“Harness巅峰期”，Cursor发布了基于长运行多模态Harness（Grind Swarm）从头构建的浏览器，尽管成本高昂且演示时曾导致服务中断，但这标志着Harness工程的重要里程碑。

“Harness已死”的证据与数据飞轮效应

随着模型智能的提升，行业开始质疑Harness的必要性。Anthropic的Tariq表示已大幅简化Claude Code的系统提示词，YC总裁Garry Tan认为Harness将消退仅留技能。Katz及其同事Stefan也指出，Cursor移除了大量用于修补模型智能短板的护栏（如用小模型处理代码编辑、强制探索代码库的指令）。近期研究支持了这一观点：UC Berkeley对七种前沿模型在Pi、Codex和Claude Code等不同Harness下的测试显示，在新颖智能模型上，Harness的选择对SWE-Bench Light得分无显著差异；Apple与EPFL的研究也发现专用MLE Harness对MLEBench结果影响不大。Katz认为，Harness正在通过“数据飞轮”效应使自身变得多余。随着更复杂的任务被纳入可达范围，更多用户尝试使用Agent，产生的编码数据反馈给实验室，最终使模型原生吸收这些技能。当模型足够强大时，Harness中用于维持任务完成的特定逻辑便不再需要。

Harness的新前沿：Grokbot与不可吸收的任务

尽管Harness在编码智能上的边际贡献递减，Katz坚持认为Harness并未死亡，而是开启了新的任务前沿。他以SpaceX的Grokbot为例，这是一个自主同事产品，不仅处理编码还涉及各类知识工作。Katz指出Grokbot采用了新型Harness架构。然而，并非所有任务都能被模型原生吸收。特别是在Context层之外的部分（如Runtime层的底层状态管理、持久化机制等），模型无法完全内化这些工程细节。因此，Harness的价值从“修补智能短板”转向了解锁模型原本无法独立解决的复杂任务领域。虽然简单的Shell访问Harness在基准测试中可能表现尚可，但在处理需要长期状态保持、多机协调及复杂第三方服务集成的真实场景时，精心设计的Harness依然是不可或缺的基础设施。Katz强调，理解这一转变对于构建下一代AI应用至关重要。

智能模型并未淘汰框架，反而催生了新的编排需求

随着大语言模型的智能化程度不断提升，许多开发者观察到在Cursor等工具中可以通过移除提示词（Prompting）和护栏（Guardrails）来简化流程，但在SpaceXAI开发的Grokbot项目中却出现了相反的趋势。我们实际上正在重新添加大量的提示词和新的安全护栏。这是因为Grokbot旨在解决的全新工作模式和领域（如关键网站流程、自动沟通等）中，模型尚未完全掌握这些复杂任务。例如，Grokbot需要处理制作幻灯片、预订旅行以及作为自主同事保持用户更新等任务。这里存在一个核心挑战：“行动”与“询问”的界限。Grokbot可以执行如给同事发邮件等具有潜在风险的操作，但必须确保用户只希望它以预期的方式进行。此外，通过记忆系统随时间学习工作方式也是当前的重点方向。

“Grokbot的框架正在使这些任务变得可行。当然，模型是其中很大的一部分，但框架有助于将它们纳入其自身的能力范围。”

对于熟悉编码Agent的用户来说，这些任务本身并不新鲜，但对于Grokbot而言它们更为重要，因为每个人都需要这类功能。目前正是框架（Harness）让原本难以完成的复杂任务变得可行。这完善了我们的数据飞轮：当编码能力被模型商品化后，框架解锁了新的前沿领域供模型解决，从而再次启动飞轮。这可能意味着进入编码之外的新任务域（如Grokbot所示），或者在软件工程职业中承担超出纯代码编写的工作。随着软件工程师职级升高，编码占比下降，其他职责变得关键。模型与框架共同驱动这一飞轮是理解当前技术演进的核心概念。

软件工厂与元框架：从单一Agent到多智能体协作

除了Grokbot，软件工厂（Software Factory）的概念展示了框架如何解锁新前沿。这是一种由多个Agent协调工作以解决完整软件开发生命周期的愿景，虽然尚未完全成熟，但行业内在此方面有大量创新。我们可以将其视为一种“元框架”（Meta Harness），即协调众多Agent共同工作的系统。以内部Bug修复流程为例：当有人报告Bug时，自动化系统会立即进行自动分类（Auto triage）；随后触发一个云Agent尝试修复Bug，该Agent利用工具展示修复前后的视频证据以证明问题已解决；最后，当修复部署或合并后，Rollouts产品会启动另一个Agent在生产环境中监控潜在问题。这种多阶段、多角色的自动化流程，正是框架价值的高级体现。前沿的Agent任务需要前沿的框架支持，这是关注框架的第一个理由。

模型无法吸收的部分：基础设施、安全与效率

除了解锁新任务，框架中还有部分核心要素是模型本身无法吸收的。首先是运行自主同事所需的基础设施和运行时环境。过去一年多，Agent处理典型任务的时间从几分钟延长至数天甚至更久。这种长时运行无法依赖可能休眠的个人笔记本电脑，必须在云端稳定运行。其次是信任与安全。虽然简单的框架（仅包含Bash和API密钥文件）足以解决编码任务，但将API密钥直接暴露给模型存在巨大风险。企业需要针对特定Agent和用户进行权限缩小（Scoped down），并设置护栏以防止灾难性操作或意外产生高额API费用。最后是效率问题。虽然之前的两项研究表明框架选择对评估分数影响不大，但两者都发现任务成本存在显著差异。在过去一个月中，通过优化缓存命中率、Token效率和模型组合，我们大幅降低了Grokbot的成本和速度延迟，且未牺牲质量。随着Agent工作量的增加，拥有最高效的框架变得愈发重要和价值巨大。

未来趋势：产品迭代加速与框架设计的演变

目前我们已进入一个新时代，产品的移动速度再次超过模型的发展速度。这意味着框架在变得整洁之前会经历一段混乱期，会有更多功能被快速推出。因此，我们预期人们将设计更易于推送（Ship）和撤回（Unship）新功能的框架。一个明显的趋势是，Grokbot及其他类似产品中，暴露给用户的内部机制越来越少。这符合Hyrum定律（任何你向用户公开的接口，最终都会被视为契约的一部分）。为了应对快速迭代的需求，隐藏内部复杂性并简化用户交互界面成为框架设计的关键方向。这种转变不仅提升了用户体验的简洁性，也降低了因过度暴露内部逻辑而导致的维护负担。框架正从“功能堆砌”转向“高效、安全且易于管理的自动化中枢”，以支撑日益复杂的Agent生态系统。

赋予用户更少可见性以换取迭代速度

在构建依赖用户的系统时，减少用户对内部运作机制的可见性是一种必要的权衡。虽然这牺牲了一定的透明度，但其核心优势在于大幅降低了变更管理的复杂度。通过简化交互逻辑，团队能够以更快的速度进行迭代。这种设计哲学并非为了隐藏问题，而是为了让系统更专注于核心功能的交付。当用户不再被复杂的后台逻辑所困扰时，他们能更快地建立起对系统的依赖和使用习惯。这种以简驭繁的策略使得产品能够在激烈的市场竞争中迅速响应变化，确保持续的进化能力。

"Now, obviously there's tradeoffs to giving users less... but one advantage is that there's less change management to deal with, and you can iterate much faster."

设计可组合的Agent基础构件（Primitives）

当前趋势的一个显著特征是对Agent基础构件（Primitives）设计的重视。这些构件如同积木般的接口，具备高度的可组合性和可扩展性。通过模块化设计，开发者可以在不增加Agent复杂度的前提下添加新功能；同样地，移除旧功能也无需进行繁琐的代码重构。这是软件工程中的最佳实践。以"订阅（subscriptions）"为例，Agent需要一种机制来响应外部事件唤醒自身。无论是Slack上的新帖子、CI管道中PR状态的变更，还是特定时间的触发器，过去可能需要为每种事件建立独立的集成。现在，通过统一的订阅框架和工具模型可以直接使用。这种统一接口的设计极大地简化了事件处理的逻辑，提升了系统的灵活性和可维护性。

集中化管理的确定性护栏（Shims）

为了弥补模型在特定场景下的不足，团队引入了确定性的护栏（deterministic guardrails）来修补模型的不良行为。例如，当GrokBot响应用户过慢时，系统会介入提示"用户在等待你"。虽然这些措施类似于临时补丁（hacks），但团队倾向于立即修复而非等待下一个模型版本发布。为了保持代码库的整洁并加速未来的迭代，所有这类修补程序被称为"shims"并被集中式追踪和管理。每当模型使用某个shim时，操作都会被记录。系统配备了一个监控机器人，一旦检测到某个shim不再触发（即模型行为已改善），该机器人会自动提交PR建议清理过时的代码。这种自动化闭环确保了基础设施的持续优化，避免了技术债务的累积。

"So in order to make our code base... be less messy and have less of a worse time iterating the future, we track all these things, which we call shims centrally..."

抽象层级提升与未来预测

Agent Harness（代理工具链）正经历向更高层级抽象的演进。早期的Harness主要由一系列LLM调用组成，而新一代如GrokBot和软件工厂则将Agent本身作为核心构建块。这种转变标志着从工具辅助向自主代理的跨越。基于这一趋势，演讲者预测在6个月内，90%的Agent工作将在本地笔记本（laptop）上运行。这一预测基于对真正自主代理需求的判断：只有具备本地高效处理能力，Agent才能以用户期望的方式与我们协作。尽管Harness在提升编码智能方面的特定作用可能因模型进步而减弱（飞轮效应），但Harness所承载的信任机制、效率提升和基础设施价值依然不可或缺。昨天的Harness可能已死，但明天的Agent Harness将开启工作的新前沿。

"I predict that within 6 months, 90% of agent work is going to run off the laptop..."

结论

智能模型的提升通过“数据飞轮”效应使Harness在编码领域的边际贡献递减，基准测试显示模型选择对得分无显著差异。然而，Harness并未消亡，而是转向解锁长时状态管理、多机协调及复杂第三方集成等模型无法内化的任务前沿。在Grokbot与软件工厂场景中，Harness通过提供云端基础设施、确定性安全护栏及高效运行时环境，解决了信任与成本问题。未来框架设计将向更高层级抽象演进，通过隐藏内部复杂性以加速迭代，并构建可组合的Agent基础构件。Harness的核心价值已从修补智能短板转变为支撑复杂自主协作的基础设施，其效率与安全机制成为不可或缺的关键要素。