Harness 不是给 Agent 加能力，是为模型构造世界

花了一天多的时间看了一下最近很火的 DeepSeek Harness 源码。

从产品层面来说，它目前当然还算不上成功，但它 “everything is plugin” 的思想给了我很大的启发，也让我开始重新理解 Harness 究竟是什么。

我们通常会把 Harness 理解成 tools、skills、context、memory、security、sandbox 这些东西的集合。但看完 DeepSeek Harness 之后，我越来越觉得，这些其实都只是表象。

真正重要的是：Harness 甚至可以把 agent loop 本身做成可替换的 plugin。

这件事情其实很漂亮。

因为这意味着 Harness 可能根本不是一个"给 Agent 加能力"的框架，而是一套为模型构造世界的装置。

这里的"世界"不是哲学意义上的抽象概念，而是模型在每一步能够看到什么、能够理解什么、能够操作什么，以及行动之后能够得到什么反馈。

Umwelt：环境不等于世界

这让我想起 Jakob von Uexküll 的 Umwelt 理论。

Uexküll 认为，生物所处的"环境"和这个生物真正生活其中的"世界"并不是一回事。不同生物虽然处在同一个物理环境里，但因为感知能力和行动能力不同，它们实际上生活在不同的 Umwelt——环境世界中。

最经典的例子是蜱虫。

森林对于人来说有树木、道路、阳光、动物；但对于蜱虫而言，这个世界可能只由几个非常有限的信号组成：哺乳动物散发的气味、体温、触觉。对蜱虫来说，森林里绝大多数东西根本不存在于它的 Umwelt 中。

所以，世界并不是一个已经完整存在、等待主体去观察的东西。

世界是由主体能够感知什么、能够对什么采取行动，以及行动能够带来什么反馈共同构成的。

一个 Coding Agent 的世界有多大

这件事情放到 AI 上突然变得很有意思。

一个 Coding Agent 的"世界"并不是整个代码仓库，更不是整个互联网。

如果它只能看到当前文件、几个工具的返回结果、git diff 和 CI 状态，那么这就是它的 Umwelt。

Agent 与 Workflow，只是世界自由度不同

所以我现在越来越倾向于认为，应该叫 AI Harness，而不只是 Agent Harness。

因为最终产物未必是 Agent。

当你给模型构造了一个高度封闭、状态明确、行动路径固定的世界，它可能表现为 workflow。

当你给它一个开放的世界、丰富的工具、持续的反馈和自主决策空间，它才更接近我们通常所说的 Agent。

甚至还可能出现一些我们现在还没有很好命名的东西。

也就是说，Agent、Workflow 或其他 AI 系统形态，本质上可能只是不同"世界自由度"下的产物。

一旦接受这个视角，Harness 的核心设计问题也会发生变化。

不再是：

我该给 Agent 什么工具？

而变成：

我在这一步呈现一个什么样的世界，才能让正确的行动成为显然的那个？

这两种问题其实完全不同。

前者是在设计能力列表。

后者是在设计 Umwelt。

Memory 该记的是世界与先验之间的差值

而且这可能会进一步改变我们理解 Context 和 Memory 的方式。

既然给 LLM 的本质上是一个世界，那么是不是可以先让它探索这个世界，再根据探索结果形成一份关于世界的描述？

但后来我又觉得，也许真正值得保存的并不是"世界的描述"，而是：

世界与模型先验之间的差值。

因为 LLM 本身已经带着一个庞大的先验模型进入世界。

很多东西根本不需要重新告诉它。

真正容易让它犯错的，往往是那些与它原有认知不同的、这个具体世界里的现实。

比如一个代码仓库存在一些非常反直觉的约束；一个公司的内部系统有特殊的权限规则；一个任务的业务逻辑和公开知识完全不同。

所以 Memory 也许不应该只是：

这个世界是什么。

而应该更多记录：

这个世界和你原本以为的世界有什么不同。

这或许比简单地堆积 context 更接近长期记忆真正有价值的部分。

Harness 同时也是一份契约

另一方面，Harness 也不仅仅是一套认识论装置，它还是一份契约。

审批弹窗、权限模式、sandbox、审计日志，这些东西表面上是在限制 Agent，实际上编码的是人和系统之间的信任关系：

你允许它看到什么，可以让它做什么，哪些行动必须经过确认，以及发生问题以后如何追责。

所以 Harness 同时决定了两件事情：

模型能够认识一个什么样的世界，以及模型能够在这个世界里做什么。

这也是为什么我觉得这种架构可能尤其适合 AI Coding。

Coding 本身就天然具有比较清晰的环境边界：repository、filesystem、terminal、git、CI、issue、review。

不同能力之间也相对容易解耦。

于是我们完全可以把不同的"世界组件"做成 plugin，再通过不同的组合构造不同的 Coding Environment。

把 Environment 本身也做成可扰动的

这进一步让我想到 Agent Evaluation。

如果 Harness 本身就是世界构造器，那么 Agent Evaluation 其实不一定应该只固定一套 benchmark environment，然后比较不同 Agent。

我们或许可以反过来：

把 Environment 本身也做成可组合、可替换、可扰动的。

通过 plugin 定义不同的工具、权限、状态、反馈机制和环境约束，再主动对环境加入各种扰动。

于是评测的就不再只是：

Agent 在这个 benchmark 上能拿多少分。

而是：

什么样的世界组合，能够让这个 Agent 稳定完成任务？它对世界发生什么变化最敏感？它在哪些 Umwelt 下会失效？

最终甚至可以反过来寻找一个"最优世界"。

收尾

也就是说，未来的 Harness 也许不只是 Agent 的运行时。

它更像是一套世界构建、世界约束以及世界评测系统。

而所谓 Agent Engineering，某种意义上也许并不是在教模型"怎么做事"。

而是在设计一个世界，让模型在这个世界里，能够自然地做对事情。