核心要点
- Agent harness 已经成为构建智能体的主流脚手架，而且不会消失。
- Memory 并不是一个可以随意插拔的外挂能力，而是与 harness 对上下文和状态的管理深度绑定。
- 如果你使用封闭的 harness，尤其是把状态和长期记忆都托管在厂商 API 背后，本质上就是把自己的记忆所有权交给第三方。
- 记忆会形成产品粘性和数据飞轮，因此模型厂商天然有动力通过 memory 制造锁定。
- 想真正拥有自己的 agent 记忆与迁移自由，就需要采用开放、可部署、模型无关的 harness。
原文链接 English Original
Agent harness 正在成为构建智能体的主流方式，而且这种形态不会消失。这类 harness 与 agent 的 memory 紧密绑定。如果你使用的是封闭式 harness——尤其当它隐藏在专有 API 背后时——你其实是在把自己 agent 的 memory 控制权交给第三方。Memory 对于打造优秀且具有用户粘性的 agent 体验极其关键，因此这会带来非常强的锁定效应。Memory——也因此包括 harness——应该是开放的，这样你才能真正拥有自己的 memory。
过去三年里，构建 agent 系统的“最佳”方法发生了剧烈变化。ChatGPT 刚出来时，我们能做的基本只是简单的 RAG chain（LangChain）。后来模型能力提升了一些，于是可以构建更复杂的流程编排（LangGraph）。再后来，模型变得更强，这催生了新一类脚手架——agent harness。
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 编排在一起。
Sarah Wooders 写过一篇非常好的文章，解释为什么“memory 不是插件，而是 harness 本身”，我对此完全认同。
有些人会觉得 memory 是一种独立服务，可以脱离具体 harness 存在。就目前这个阶段来说，这并不成立。
Harness 的一项核心职责，就是与上下文交互。正如 Sarah 所说：
要求把 memory 插进 agent harness，就像要求把“驾驶”插进一辆车一样。管理上下文，也因此管理 memory，本来就是 agent harness 的核心能力与责任。
Memory 只是 context 的一种形式。短期记忆（例如会话消息、大型工具调用结果）由 harness 负责处理。长期记忆（跨会话 memory）也需要 harness 负责写入和读取。Sarah 还列举了很多 harness 与 memory 绑定的方式：
AGENTS.md 或 CLAUDE.md 文件是如何被加载进上下文的？ 技能元数据是如何展示给 agent 的？（是在 system prompt 里？还是 system message？） Agent 能否修改自己的系统指令？ 上下文压缩后，哪些内容会保留，哪些会丢失？ 交互记录是否被存储并可查询？ Memory 元数据以什么形式呈现给 agent？ 当前工作目录如何表示？暴露了多少文件系统信息？
目前，memory 这个概念还处在非常早期的阶段，真的还很不成熟。坦白说，我们看到长期 memory 往往都不是 MVP 的组成部分。通常要先把 agent 基本跑通，然后才开始考虑个性化问题。这意味着整个行业仍在摸索 memory，也还没有形成成熟、通用的 memory 抽象。
将来随着 memory 被更广泛理解、最佳实践逐渐出现，独立的 memory 系统也许会开始变得合理。但现在还不是那个阶段。正如 Sarah 所说，“归根结底，harness 如何管理 context 和 state，构成了 agent memory 的基础。”
Harness 与 memory 的关系极其紧密。
如果你使用的是封闭式 harness，特别是它又隐藏在 API 背后，你就并不拥有自己的 memory。
这会以几种不同方式体现出来。
相对轻一点的问题是：如果你使用有状态 API（比如 OpenAI 的 Responses API，或者 Anthropic 的服务端压缩机制），那么状态实际上保存在它们的服务器上。这样一来，如果你想切换模型并继续之前的线程，就做不到了。
更糟的是：如果你使用一个封闭的 harness（比如 Claude Agent SDK，它底层用的是 Claude Code，而后者并不开源），那么这个 harness 如何与 memory 交互，对你来说是不可知的。也许它在客户端生成了一些 artifact，但这些 artifact 的结构是什么、一个 harness 应该如何使用它们，这些你都不知道。因此，这些能力也无法从一个 harness 迁移到另一个 harness。
但最糟糕的情况，是整个 harness——包括长期 memory——都被放在 API 背后。
在这种情况下，你对 memory 完全没有所有权，也几乎没有可见性，连长期 memory 也一样。你不了解 harness，也就不知道应该如何使用 memory。更糟糕的是，你甚至不真正拥有这些 memory！也许 API 暴露了一部分，也许什么都不暴露，这都不由你控制。
当人们说“模型会吸收越来越多的 harness”时，他们真正指的，其实就是这些与 memory 相关的部分会逐步被模型厂商塞到 API 背后。
这非常值得警惕——它意味着 memory 将被锁定在单一平台、单一模型之中。
模型提供商有极强的动机去这么做，而且他们已经开始这么做了。Anthropic 推出了 Claude Managed Agents。这几乎把所有东西都放到了 API 后面，并且锁定在他们的平台里。
即便整个 harness 没有完全进入 API，模型厂商也有动力把越来越多的能力移到 API 后面，而且他们已经在这么做了。例如：虽然 Codex 是开源的，但它生成的是加密过的压缩摘要，这些摘要无法在 OpenAI 生态之外使用。
他们为什么这么做？因为 memory 很重要，它能带来的锁定效应不是单靠模型本身就能获得的。
尽管 memory 还处在早期阶段，但大家都已经清楚它的重要性。它让 agent 能随着用户交互不断变好，也让你能构建数据飞轮。它使你的 agent 能针对每位用户进行个性化，逐步形成贴合其偏好与使用习惯的 agent 体验。
没有 memory，你的 agent 对于任何拥有同样工具的人来说都很容易复制。
有了 memory，你就在持续积累一套专有数据集——关于用户互动与偏好的数据。这套专有数据集能帮助你提供差异化、并且越来越聪明的体验。
到目前为止，切换模型厂商一直相对容易。它们的 API 都很类似，甚至几乎相同。没错，你可能需要稍微调整一下 prompt，但这并不算难。
之所以容易切换，是因为它们基本都是无状态的。
一旦有了状态，切换就会困难得多。因为这些 memory 很重要，而一旦切换，你就会失去它们。
我讲个故事。我们内部有一个邮件助手，它是基于 Fleet 上的一个模板构建的。Fleet 是我们用来构建企业级 OpenClaw 的无代码平台，这个平台内建了 memory。因此，在过去几个月里，我不断和这个邮件助手互动，它也逐渐积累了 memory。几周前，这个 agent 因为意外被删掉了。我当时特别恼火！我试着用同一个模板重新创建一个 agent，但体验糟糕多了。我不得不重新教它我的偏好、语气，几乎所有东西。
不过，邮件 agent 被删也让我意识到：memory 的力量和粘性到底有多强。
Memory 应该是开放的，并且应该归构建 agent 体验的人所有。它能让你积累一套真正由你控制的专有数据集。
Memory（也因此包括 harness）应该独立于模型提供商之外。你应该保有选择权，去尝试任何最适合你场景的模型。模型厂商则天然有动机通过 memory 制造锁定。
这正是我们构建 Deep Agents 的原因。Deep Agents：
要真正拥有自己的 memory，你就需要使用开放的 Harness。
欢迎现在就试用 Deep Agents。
感谢以下几位的审阅与想法：