一些大模型，高分低能，为何？

这篇文章的思路来自 Philipp Schmid，由 minghao 推荐
https://www.philschmid.de/agent-harness-2026

很多人，会有这个体验
有些模型，在排行榜上分数很高，但实际用起来经常翻车
问个问题还行，让干活就开始犯蠢

原因很简单

排行榜测的是单轮能力，或者几轮简单交互

但真实场景里，你让 Agent 跑一个复杂任务，可能要调用几十上百次工具，跑几个小时

排行榜 1% 的差距，测不出 50 步之后的差异

这就是「持久性」问题

有些模型，可能足够聪明，一两次尝试就能解开难题
但跑了一个小时后，可能无法遵循最初的指令，或者在中间步骤的推理出错

怎么解决？
Philipp Schmid 提了一个概念，叫 Agent Harness

Harness 是什么

Harness 本意是马具、挽具，引申为「驾驭某物的装置」

软件领域最常见的用法是 test harness 测试框架

Agent Harness 是同样的思路：
包裹在 AI 模型外层，管理 Agent 长周期运行的基础设施层

用计算机来类比：

模型是 CPU，提供原始算力

上下文窗口是内存，有限的、易失的工作记忆

Agent Harness 是操作系统，管理上下文、处理启动流程、提供标准驱动

Agent 是应用程序，运行在操作系统之上的具体用户逻辑

Philipp Schmid 画的示意图，一目了然

Harness 的层级比 Agent 框架更高

框架提供的是构建模块，工具接口、Agent 循环的实现

Harness 提供的是预设 Prompt、工具调用的规范化处理、生命周期钩子，以及开箱即用的能力，规划、文件系统访问、子 Agent 管理

对开发者来说，这意味着可以跳过「造操作系统」，直接专注于定义 Agent 的独特逻辑

目前通用型 Harness 还很少。Claude Code 是这个品类的典型代表，Claude Agent SDK 和 LangChain DeepAgents 也在尝试标准化

Harness 能做三件事

验证真实进展
新模型频繁发布，Harness 让用户能快速测试最新模型在自己场景下的表现，而不是看排行榜猜

释放模型潜力
没有 Harness，用户体验可能落后于模型能力。好的 Harness 让开发者能用经过验证的工具和最佳实践来构建 Agent

创造反馈闭环
Harness 把模糊的、多步骤的 Agent 工作流转化为可记录、可评分的结构化数据。哪一步出了问题，一目了然

苦涩教训

Rich Sutton 写过一篇文章叫《苦涩的教训》

核心观点：利用算力的通用方法，每次都能打败手工编码的人类知识

这个教训正在 Agent 开发领域上演

Manus 在六个月内重构了五次 Harness，去除僵化的假设

LangChain 一年内重新架构了三次「Open Deep Research」Agent

Vercel 砍掉了 80% 的 Agent 工具，换来更少的步骤、更少的 Token、更快的响应

每次新模型发布，都有不同的最优 Agent 架构方式

2024 年需要复杂手工流水线的能力，到 2026 年可能只需要一个上下文窗口内的 Prompt 就能搞定

如果过度设计控制流，下一次模型更新就会让系统崩溃

怎么做

至于该怎么做，原作者给到了三条原则：

从简单开始
不要构建庞大的控制流。提供健壮的原子工具，让模型自己规划。实现护栏、重试和验证

为删除而构建
让架构模块化。新模型会替代你的逻辑，必须随时准备好撕掉代码

Harness 就是数据集
竞争优势不再是 Prompt，而是 Harness 捕获的轨迹数据。每一次 Agent 在工作流后期未能遵循指令的失败案例，都可以用来训练下一代模型