Agent Harness 与记忆的关系

推荐语

Agent Harness与记忆密不可分，闭源方案将让你失去对AI核心体验的控制权。

核心内容：
1. Agent Harness已成为构建AI系统的主流方式
2. 记忆功能是Harness的核心能力而非插件
3. 开源Harness才能确保对记忆数据的自主权

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

Agent Harness 正成为构建 AI Agent 的主流方式，而且这种方式不会消失。这些 Harness 与 Agent 的记忆紧密相关。如果你使用闭源的 Harness——尤其是通过专有 API 提供的——你实际上是将 Agent 的记忆控制权交给了第三方。记忆对于创造优秀且让用户粘性强的 Agent 体验至关重要。这会带来极强的锁定效应。因此，记忆——以及随之而来的 Harness——应该是开放的，这样你才能拥有自己的记忆。

Agent Harness 是构建 Agent 的方式，而且不会消失

过去三年，"最佳"的 Agent 系统构建方式发生了剧变。当 ChatGPT 刚推出时，只能做简单的 RAG 链（LangChain）。然后模型能力稍微提升了一些，可以创建更复杂的流程（LangGraph）。再之后，模型能力大幅提升，催生了一种新的脚手架——agent harnesses。

Agent harness 的例子包括 Claude Code、Deep Agents、Pi（为 OpenClaw 提供动力）、OpenCode、Codex、Letta Code，以及更多。

💡 Agent Harness 不会消失。

有人认为模型会逐渐吸收越来越多的脚手架。这是不对的。已经发生（而且会继续发生）的情况是：2023 年需要的大量脚手架不再需要了，但取而代之的是其他类型的脚手架。Agent 的定义就是 LLM 与工具和其他数据源交互的系统。LLM 周围总会有一个系统来促进这种交互。需要证据吗？当 Claude Code 的源代码泄露时，有 51.2 万行代码。那些代码就是 harness。即使是世界上最好的模型制造商也在大力投资 harness。

当 OpenAI 和 Anthropic 的 API 内置网络搜索等功能时——这些功能不是"模型的一部分"，而是位于它们 API 后面的轻量级 harness，通过工具调用来编排模型和这些网络搜索 API。

Harness 与记忆绑定

Sarah Wooders 写了一篇很棒的博客，解释为什么"记忆不是插件（它是 harness）"，我完全同意。

有人认为记忆是一个独立的服务，与任何特定 harness 分离。目前来看，这并不成立。

Harness 的一大责任是与上下文交互。用 Sarah 的话说：

将记忆插入 agent harness 就像把驾驶功能插入汽车。管理上下文，进而管理记忆，是 agent harness 的核心能力和责任。

记忆只是上下文的一种形式。短期记忆（对话中的消息、大型工具调用结果）由 harness 处理。长期记忆（跨会话记忆）需要由 harness 更新和读取。Sarah 列出了 harness 与记忆绑定的其他方式：

AGENTS.md 或 CLAUDE.md 文件如何加载到上下文中？技能的元数据如何展示给 agent？（在系统提示词中？在系统消息中？）agent 能否修改自己的系统指令？压缩后保留什么，丢失什么？交互是否存储并可供查询？记忆的元数据如何呈现给 agent？当前工作目录如何表示？暴露了多少文件系统信息？

现在，记忆作为概念还处于萌芽阶段。它还太早了。坦率地说，我们看到长期记忆通常不是 MVP 的一部分。首先你需要让 agent 正常工作，然后才能考虑个性化。这意味着（作为一个行业）我们还在探索记忆。这意味着还没有广为人知的常见记忆抽象。如果记忆变得更加普及，并且我们发现了最佳实践，独立的记忆系统可能会开始有意义。但目前不是。正如 Sarah 所说，"最终，harness 如何管理上下文和状态是 agent 记忆的基础。"

如果你没有自己的 harness，你就没有自己的记忆

harness 与记忆紧密相关。

💡 如果你使用闭源 harness，尤其是通过 API 提供的，你就不拥有自己的记忆。

这体现在几个方面。

轻微的不利：如果你使用有状态的 API（比如 OpenAI 的 Responses API，或 Anthropic 的服务端压缩），你就是在它们的服务器上存储状态。如果你想切换模型并恢复之前的对话线程——这就无法实现了。

不利：如果你使用闭源 harness（比如 Claude Agent SDK，它在底层使用 Claude Code，而 Claude Code 不是开源的），这个 harness 以你不知道的方式与记忆交互。也许它在客户端创建了一些工件——但这些工件的形状是什么？harness 应该如何使用它们？这是未知的，因此无法从一个 harness 传递到另一个。

💡 但最糟糕的是——当整个 harness，包括长期记忆都位于 API 后面时。

在这种情况下，你对记忆零所有权或可见性，包括长期记忆。你不了解 harness（这意味着你不知道如何使用记忆）。但更糟糕的是——你甚至不拥有记忆！也许某些部分通过 API 暴露，也许没有部分暴露——你对此没有控制权。

当人们说"模型会吸收越来越多的 harness"时——他们真正的意思就是这个。他们的意思是这些与记忆相关的部分会进入模型提供商提供的 API 后面。

💡 这令人极其担忧——这意味着记忆会锁定在单一平台、单一模型上。

模型提供商有极强的动机这么做。而且他们已经开始这么做了。Anthropic 推出了 Claude Managed Agents。这会将所有东西都放在 API 后面，锁定在他们的平台上。

即使整个 harness 不在 API 后面，模型提供商也有动机将更多功能移到 API 后面——而且已经在做了。例如：即使 Codex 是开源的，它生成加密的压缩摘要（无法在 OpenAI 生态系统之外使用）。

他们为什么要这样做？因为记忆很重要，而且它能创造仅靠模型无法获得的锁定效应。

记忆很重要，而且创造锁定

虽然记忆还早，但很明显，每个人都认为它很重要。它让 agent 随着用户互动而改进，并允许你建立数据飞轮。它让你的 agent 能够针对每个用户进行个性化，并建立一种适应用户需求和使用模式的 agent 体验。

💡 没有记忆，你的 agent 很容易被任何拥有相同工具的人复制。

有了记忆，你就建立了一个专有数据集——用户互动和偏好的数据集。这个专有数据集让你能够提供差异化的、越来越智能的体验。

到目前为止，切换模型提供商相对容易。它们有相似甚至相同的 API。当然，你需要稍微更改提示词，但这并不难。

但这都是因为它们是无状态的。

一旦有任何状态关联，切换就变得难得多。因为这个记忆很重要。如果你切换，就会失去对它的访问权。

让我讲个故事。我内部有一个邮件助手。它基于 Fleet 中的模板构建，Fleet 是我们用于构建企业级 OpenClaws 的无代码平台。这个平台内置了记忆，所以过去几个月我与邮件助手互动时，它建立了记忆。几周前，我的 agent 意外被删除了。我很生气！我尝试用相同的模板创建一个 agent——但体验差多了。我必须重新教它我的所有偏好、我的语调、一切。

我的邮件 agent 被删除的积极方面——它让我意识到记忆的强大和粘性。

开放记忆，开放 Harness

记忆需要开放，由构建 agent 体验的人拥有。这让你建立自己实际控制的专有数据集。

记忆（以及随之而来的 harness）应该与模型提供商分离。你应该有自由选择最适合你用例的模型。模型提供商有动机通过记忆创造锁定。

这就是我们要构建 Deep Agents 的原因。Deep Agents 是开源的。是模型无关的。使用开放标准，如 agents.md 和 skills。拥有插件，支持 Mongo、Postgres、Redis 等存储记忆。可部署：（1）通过 LangSmith Deployment（可自托管，可在任何云上部署，可以携带自己的数据库作为记忆存储）；（2）通过任何标准 Web 托管框架。

为了拥有你的记忆，你需要使用开放 Harness。

今天就试试 Deep Agents。

感谢一些人的评审和建议：

Sydney Runkle，他在 Deep Agents 和记忆方面做了很多很棒的工作。Viv Trivedy，他是 agent harness 领域的领导者。Nuno Campos，他在金融 agent 的上下文工程方面有很棒的写作。Sarah Wooders，她是 Letta 的 CTO，Letta 是一家始终站在有状态 agent 前沿的公司。