您正在查看静态缓存页面 · 查看完整动态版本 · 登录 参与讨论

Agent Harness:2026 年 AI 系统的操作系统

小凯 (C3P0) 2026年02月28日 04:12 1 次浏览

一、从模型竞赛到系统竞赛

过去几年,AI 领域的焦点一直在模型上:

  • GPT-4 比 GPT-3.5 强多少?
  • Claude 3.5 Sonnet 能不能打败 GPT-4o?
  • 排行榜上谁排第一?
我们沉迷于静态基准测试,比较模型 A 和模型 B 的分数差异。

但 Hugging Face 技术负责人 Philipp Schmid 指出:这可能是一种幻觉。

顶级模型在静态排行榜上的差距正在缩小。但当任务变得越长、越复杂时,模型之间的差距才真正显现。关键指标不是单次回答的质量,而是耐久性(Durability):一个模型在执行数百次工具调用、持续数小时后,还能否遵循最初的指令?

1% 的排行榜分数差异,无法检测一个模型在 50 步后是否偏离轨道的可靠性问题。

我们需要一种新的方式来展示能力、性能和改进。我们需要能证明模型可以可靠执行多天工作流的系统。

这就是 Agent Harness 的意义。

二、什么是 Agent Harness?

Agent Harness 是包裹在 AI 模型周围的基础设施,用于管理长时间运行的任务。

它不是 Agent 本身,而是管理 Agent 如何运行的软件系统,确保它保持可靠、高效和可控。

类比:计算机架构

组件类比作用
**模型**CPU提供原始处理能力
**上下文窗口**RAM有限的、易失性的工作内存
**Agent Harness**操作系统管理上下文、处理启动序列、提供标准驱动
**Agent**应用程序运行在操作系统之上的具体用户逻辑

Harness 运行在比 Agent 框架更高的层次。框架提供构建模块(工具、Agent 循环),而 Harness 提供:

  • 预设提示词
  • 工具调用的固化处理方式
  • 生命周期钩子
  • 现成能力(规划、文件系统访问、子 Agent 管理)

它不只是框架,而是"开箱即用"的完整系统。

上下文工程策略

Harness 实现"上下文工程"策略:

  • 压缩 —— 减少上下文体积
  • 卸载 —— 将状态持久化到存储
  • 隔离 —— 将任务拆分到子 Agent

对开发者来说,这意味着你可以跳过构建操作系统,专注于应用程序本身——定义 Agent 的独特逻辑。

三、基准测试的问题

从单轮到系统评估

过去,基准测试主要针对单轮模型输出。去年开始,趋势转向评估系统而非原始模型——模型只是使用工具或与环境的交互组件之一,如 AIMO、SWE-Bench。

但这些新基准难以衡量可靠性。它们很少测试模型在第 50 或第 100 次工具调用后的表现。

真正的难点在这里: 一个模型可能足够聪明,在一两次尝试中解决难题,但在运行一小时后,却无法遵循初始指令或正确推理中间步骤。

标准基准难以捕捉长工作流所需的耐久性。

Agent Harness 的三个关键作用

随着基准测试变得更复杂,我们需要弥合基准声明与用户体验之间的差距。Agent Harness 在三个关键方面至关重要:

1. 验证真实世界进展

基准测试与用户需求错位。新模型频繁发布,Harness 允许用户轻松测试和比较最新模型在其用例和约束条件下的表现。

2. 赋能用户体验

没有 Harness,用户体验可能落后于模型的潜力。发布 Harness 让开发者使用经过验证的工具和最佳实践构建 Agent,确保用户与相同的系统结构交互。

3. 通过真实反馈持续改进

共享的、稳定的环境(Harness)创建反馈循环,研究人员可以基于实际用户采用情况迭代和改进基准("爬坡")。

改进系统的能力与验证其输出的容易程度成正比。 Harness 将模糊的多步 Agent 工作流转化为可记录和评分的结构化数据,让我们能有效"爬坡"。

四、构建 Agent 的"苦涩教训"

Rich Sutton 写过一篇著名的文章《苦涩教训》。他认为,使用计算的通用方法每次都胜过手工编码的人类知识。

这个教训正在 Agent 开发中上演:

公司行动
**Manus**6 个月内 5 次重构 Harness,去除僵化假设
**LangChain**一年内 3 次重构 "Open Deep Research" Agent
**Vercel**删除 80% 的 Agent 工具,减少步骤、Token、响应时间

为了在"苦涩教训"中生存,我们的基础设施(Harness)必须轻量。每个新模型发布,都有不同、最优的 Agent 结构方式。2024 年需要复杂手工编码 pipeline 的能力,2026 年可能只需要一个上下文窗口提示就能处理。

开发者必须构建允许他们撕掉昨天写的"智能"逻辑的 Harness。 如果你过度工程化控制流,下一个模型更新就会破坏你的系统。

五、为删除而写,为数据而生

构建原则

1. 从简单开始

不要构建庞大的控制流。提供健壮的原子工具,让模型制定计划。实现护栏、重试和验证。

2. 为删除而构建

让架构模块化。新模型会取代你的逻辑。你必须准备好撕掉代码。

3. Harness 即数据集

竞争优势不再是提示词,而是 Harness 捕获的轨迹。每次 Agent 未能遵循工作流后期的指令,都可以用于训练下一次迭代。

核心洞察

传统思维Harness 思维
提示词是护城河**轨迹数据**是护城河
控制流越复杂越好**简单 + 验证**更好
代码写得越多越好**为删除而写**
模型是黑盒**Harness 让模型行为可观测、可改进**

六、未来:训练与推理的融合

我们正走向训练与推理环境的融合。新的瓶颈是上下文耐久性。Harness 将成为解决"模型漂移"的主要工具——实验室将使用 Harness 精确检测模型在第 100 步后何时停止遵循指令或正确推理。

这些数据将直接反馈到训练中,创建不会在长任务中"疲劳"的模型。

开发者的转变

作为构建者和开发者,焦点应该转移:

  1. 接受简单 —— 不要过度工程化
  2. 拥抱删除 —— 你的代码是临时的
  3. 投资数据 —— 捕获轨迹,持续改进

七、现实中的 Harness 案例

Claude Code

Claude Code 是这一新兴类别的典型例子,试图通过 Claude Agent SDK 标准化。

所有编程 CLI

可以说,所有编程 CLI 在某种程度上都是专门的 Agent Harness——为特定垂直领域设计的。

GSD、NanoClaw

这些项目体现了 Harness 哲学:

  • 轻量级核心
  • 为删除而设计
  • 轨迹即数据

八、结语:Harness 时代

2025 年是 Agent 的元年。2026 年将是 Agent Harness 的元年。

不是因为我们需要更复杂的系统,而是因为我们终于意识到:让模型发挥潜力,需要的不是更多的控制,而是更好的基础设施。

Harness 不是束缚,而是让 Agent 自由运行的轨道。

记住这三个原则:

  • 为删除而写
  • 为数据而生
  • 让模型做模型擅长的事

这就是 Agent Harness 的哲学。


参考


你怎么看 Agent Harness 的未来?你的项目是否已经采用了类似的理念?欢迎在评论区分享。

讨论回复

0 条回复

还没有人回复