Agent 不是缺大脑，是缺一个能跑稳的底盘

最近读到一篇 104 页的综述，题目叫 Agent Harness for Large Language Model Agents。

我第一反应其实是，终于有人把这个东西原原本本地定义清楚了。

过去两年大家聊 Agent，聊得最多的是什么？

是模型会不会规划，是不是会用工具，记忆能不能做长一点，Prompt 怎么写，Reflection 怎么加，multi-agent 怎么协作。

这些当然重要。

但说真的，越往生产环境里做，我越觉得大家可能把注意力放错地方了。

很多 Agent 不是死在模型不够聪明，而是死在一个更朴素的问题上。

它跑不稳。

工具调用没有边界，上下文越堆越乱，状态一断就丢，执行循环卡住没人知道，评估的时候你甚至说不清到底是模型差，还是外面那层工程壳子差。

这就是这篇综述里反复强调的一个点，Agent 系统可靠性的上限，往往不是模型决定的，而是 Harness 决定的。

这个判断挺刺耳的。

因为它等于在说，我们过去很长一段时间都在盯着大脑，但真正把大脑接到现实世界里的那套神经系统，反而没人认真拆。

我读完最大的感受是，2025 年大家都在喊 Agent，到了 2026 年，真正该被拿出来讨论的，可能是 Agent Harness。

也就是 Agent 的运行底盘。

不是哥们，这个词听起来很工程，很硬，很没传播感。

但它真的重要。

你想想看，一个模型要完成真实任务，它不可能只在聊天框里思考。它要读文件，要调工具，要写代码，要查数据库，要等任务结果，要恢复失败，要记录轨迹，还要在危险动作前被拦一下。

这些东西不在模型里面。

它们都在模型外面。

这层东西，就是 Harness。

这篇综述给了一个很干净的定义，H = (E, T, C, S, L, V)。

这是一个很难得的总结，也给了我们一个真正去拆解优化Harness的思路。

一共六件事：

E 是执行循环，决定 Agent 怎么观察、思考、行动，再观察、再行动。

T 是工具注册表，决定它能调用哪些工具，参数怎么校验，错了怎么办。

C 是上下文管理，决定哪些信息进窗口，哪些信息被压缩，哪些信息该忘掉。

S 是状态存储，决定任务进度、文件快照、运行中间态能不能被保存下来。

L 是生命周期钩子，决定每一步执行前后有没有鉴权、审计、拦截。

V 是评估接口，决定你能不能把 Agent 的行为轨迹记录成可分析、可复现、可比较的数据。

这六个东西合起来，才是一个 Agent 真正在现实世界里跑起来的底盘。

说真的，我以前也会下意识把 Harness 理解成框架。

比如 LangGraph 是不是 Harness，AutoGPT 是不是 Harness，ReAct 是不是 Harness。

但这篇综述把边界讲得更清楚。

ReAct 更像一个原始原语，它有 observe-think-act 的循环味道，但缺少正式的工具注册、状态管理和异常恢复。

AutoGPT 是早期单体 Harness，东西很多，但耦合太重，很多写入不是幂等的，一旦跑长任务，稳定性就很容易出问题。

MemGPT 更像一个很强的能力模块，尤其在上下文和状态这块很有想象力，但它通常还要挂到另一个执行循环里。

LangGraph 很适合表达执行拓扑，你可以把流程写成图，但上下文怎么管、状态怎么治理、安全怎么拦，很多时候还是要工程师自己补。

AIOS 就更接近完整的 OS 级抽象，它试图把调度、并发、资源隔离这些更底层的东西也一起管起来。

这些判断不一定所有人都同意。

但我觉得它有价值，因为它把一个长期混在一起的问题拆开了。

不是所有 Agent 框架都是 Harness。

也不是所有 Harness 都长得像框架。

Harness 更像一套运行时治理系统。

这块如果不清楚，后面很多讨论都会鸡同鸭讲。

更有意思的是，综述里列了一些数据，基本都指向同一个结论。

在不改模型的情况下，只改 Harness，性能能涨很多。

Pi Research 通过调整编辑工具格式和上下文组合，把某个任务表现从 6.7% 拉到 68.3%。

LangChain DeepAgents 加了中间件、总结逻辑和循环控制后，在 TerminalBench 2.0 上提升 26%。

AgencyBench 发现同一个 Agent 放在不同生态和不同 Harness 里，性能方差能到 31%。

HAL 那类标准化评估基础设施，则把评估周期从数周压到数小时。

这些数字看起来像论文里的表格。

但你把它翻译成人话，就是一句很简单的话。

模型能力是必要条件，但 Harness 经常是绑定约束。

我自己做 Data Agent 和 NL2SQL 的时候，对这个点感受特别深。

很多时候你会发现，模型不是完全不会。它其实知道大概该怎么做。

真正麻烦的是外面那一圈东西。

找表召回有没有稳定，schema 有没有同步，工具返回是不是结构化，执行 SQL 失败后怎么修，用户会话中间断了怎么继续，日志能不能追到每一步，线上出问题能不能复现。

这些东西不性感。

但它们决定了一个 Agent 是 demo，还是产品。

这也是为什么我觉得 Harness Engineering 这个词会越来越重要。

它不是一个新瓶装旧酒的 buzzword。

它是在提醒我们，Agent 的工程重心正在往运行时迁移。

过去我们喜欢说 Prompt Engineering。

后来大家开始说 Context Engineering。

再往后，很可能就是 Harness Engineering。

Prompt Engineering 解决的是，怎么把一句话写好。

Context Engineering 解决的是，怎么把信息流组织好。

Harness Engineering 解决的是，怎么让一个会思考、会调用工具、会产生副作用的系统，在真实世界里稳定、安全、可观测地跑下去。

这里面最容易被低估的是安全。

很多朋友一听 Agent 安全，就会想到输出有没有违规，有没有说不该说的话。

但 Agent 真正危险的地方不是它说了什么。

是它能做什么。

当一个 Agent 有 Bash，有数据库权限，有浏览器，有邮件，有云资源，它读到一段恶意内容，然后照着里面的隐含指令去执行，这就不是聊天机器人安全了。

这是系统安全。

综述里提到间接提示词注入和能力提升，我觉得这块会是接下来几年最麻烦的工程问题之一。

你不能指望模型每次都自觉。

也不能把安全策略全写进 Prompt 里，然后祈祷它别忘。

真正靠谱的做法，是把策略拦截放在 Harness 的 L 组件里。

危险工具调用前拦一下，高风险参数校验一下，文件写入和网络访问做审计，必要时要求人工确认。

听起来很笨。

但生产系统很多时候就是靠这些笨办法活下来的。

还有一个点也挺关键，评估。

现在很多 Agent leaderboard，我一直有点警惕。

不是说它们没用，而是你得知道它到底在测什么。

一个模型放在 A Harness 里跑，和放在 B Harness 里跑，结果可能完全不一样。

工具格式不同，上下文压缩不同，错误恢复不同，环境初始化不同，最终分数当然不同。

所以你测到的，很多时候不是纯模型能力。

你测到的是模型加 Harness 这个组合。

这就会带来一个很现实的问题，如果评估环境不标准，leaderboard 上的高低，可能混进了大量工程实现差异。

OSWorld 里那种环境漂移导致 false negative 的问题，就是这个方向的典型例子。

所以 V 组件才重要。

它不是为了写日志而写日志。

它是为了让 Agent 的行为能被复盘，能被比较，能被外部 benchmark 消费。

不然你线上出了一个奇怪结果，只能看着一坨自然语言对话发呆。

那种感觉我太熟了。

一时间无语凝噎。

说到这里，其实还能顺着聊到协议。

MCP 现在很火，因为它解决的是工具怎么接的问题。

A2A 解决的是 Agent 之间怎么通信的问题。

但我自己的感觉是，协议只是开始。

真正难的是协议接进来之后，Harness 怎么治理这些能力。

工具越多，系统不一定越强。

很多时候，工具越多，Agent 越容易迷路。

Stripe 那个 Minions 的实践就很有意思，它们不是无限堆工具，而是给 Agent 一个高度定制的工具子集。

这话听起来有点反直觉。

但挺符合工程直觉。

一个人进厨房，如果你给他一整面墙的刀具和机器，他不一定更会做饭。

你给他一把合适的刀，一个干净的案板，一个明确的流程，他反而更稳定。

Agent 也是这样。

能力不是越开放越好，能力要被组织。

这就是 Harness 的价值。

当然，讲到这里也不能把模型能力贬得一文不值。

模型还是核心发动机。

没有发动机，底盘再稳也跑不起来。

但反过来也成立。

发动机再猛，如果刹车、传动、悬挂、仪表盘都不行，你不敢开上路。

这篇综述让我喜欢的地方就在这里。

它没有继续神化模型，也没有用工程黑话故弄玄虚。

它只是把大家在生产环境里反复踩到的坑，归纳成了一套可以讨论的语言。

执行循环失控，上下文爆炸，工具误用，状态丢失，副作用不可控，行为不可观测。

这些词看起来很抽象。

但每一个背后都是事故现场。

你做过 Agent，就知道它们一点都不抽象。

我有时候觉得，2026 年做 Agent 的分水岭，可能不是你会不会调 Prompt，也不是你会不会接 MCP。

而是你有没有能力回答几个更朴素的问题。

你的 Agent 跑飞了，谁能停它？

你的上下文爆了，谁来决定丢什么？

你的工具调错了，谁来兜底？

你的状态断了，能不能续上？

你的结果错了，能不能复盘？

你的评估涨了，确定不是 Harness 偷偷帮了忙？

这些问题听起来都不够浪漫。

但真正的生产力，往往就藏在这些不浪漫的地方。

回到最开始那句话。

过去我们太喜欢盯着大脑了。

模型是不是会规划，推理链是不是够长，工具调用是不是更聪明。

但一个 Agent 真正进入现实世界之后，它需要的不只是聪明。

它需要一个能承受现实摩擦的身体。

能记住，能恢复，能刹车，能留痕，能被审计，能被评估。

这就是 Harness。

我不知道 Agent Harness 这个词最终会不会成为行业共识。

但我挺确定一件事，接下来真正把 Agent 做进生产系统的人，都会越来越关心这层东西。

因为 demo 可以靠模型惊艳一下。

产品不行。

产品要靠 Harness 活下来。

大时代啊，朋友们。

谢谢你看我的文章，我们，下次再见。