Memory 不是插件，而是主权边界：Agent Harness 为什么会变成新的锁定层

引子

如果只看表层，这篇《Your harness, your memory》像是一篇为 Deep Agents 站台的产品文章。

它当然有产品立场，但如果只把它看成一次市场发言，就会错过这篇文章真正有价值的地方。它真正指出的是一个正在快速成形、但很多团队还没认真承认的事实：Agent 时代新的锁定点，不再只是模型能力，也不只是 API 价格，而是 harness 对 context、state 和 memory 的控制权。

过去两年，大家谈模型替换、模型对齐、Prompt 工程、工具调用，谈得都很多。但随着 Agent 系统开始从一次性对话走向长任务、跨 session、跨角色协作，一个更硬的问题开始浮出来：如果用户偏好、压缩摘要、执行历史、工件索引、任务进度、工作目录语义，全部都被某家 provider 的 harness 或托管 API 吃进去，那你到底还拥有多少自己的产品资产？

我的判断很直接：Memory 不应该被理解为一个附加功能，而应该被理解为 Agent 产品的主权边界。 你把这条边界交给谁，谁就更接近掌控你的长期体验、迁移成本和数据飞轮。

为什么 Harness 不会消失，反而会变成更核心的一层

Harrison 在原文里先做了一个判断：Harness 不会随着模型增强而消失。

这件事我同意，而且我认为重要性比很多人意识到的更高。

过去不少人有一种乐观假设，觉得模型越来越强以后，外层脚手架会越来越薄，最后大多数“Agent 框架”都会变成过渡技术。但真实情况恰好相反。模型能力越强，系统越会把新的复杂度推到模型外围：

• 工具如何选择和调度
• 长任务如何切片推进
• 上下文如何压缩和恢复
• 执行环境如何隔离
• 凭证如何代理
• 多 agent 如何分工和交接
• 用户状态如何跨 session 保持

这些事情没有一项属于“模型天然会做”。它们都需要一层持续存在的运行时来组织，而这层运行时就是 harness。

这也是为什么 Anthropic 在 Managed Agents 的工程文章里明确把系统拆成 session + harness + sandbox，为什么 LangGraph 把 durability、checkpoint、human-in-the-loop 视为 runtime 的核心，为什么 OpenAI 的 Responses API 在把 background mode、store、tool loop 一步步原语化。行业并没有在消灭 harness，而是在把 harness 做得更像正式的系统层。

为什么 Memory 不是独立插件，而是 Harness 管理上下文的结果

原文里最值得重视的一句判断，不是“memory 很重要”，而是 Sarah Wooders 那个几乎可以当成定义的话：memory isn’t a plugin, it’s the harness。

这句话听上去像口号，但从工程上看非常准确。

很多团队说自己“接了 memory”，实际做的事情往往只是：

• 把聊天记录存起来
• 用向量库召回几条历史片段
• 维护一个用户 profile
• 偶尔做一次长上下文压缩

这些都可以算 memory 的组成部分，但它们远远不等于完整的记忆系统。真正的问题是，memory 从来不是一张表或一个库，而是一整套关于 context/state 的系统设计：

• 哪些历史进入上下文，哪些不进
• 工具结果是保留全文、抽取摘要，还是沉淀成结构化事实
• 会话压缩后，哪些信息还能活下来
• 工作目录、技能元数据、系统约束怎样暴露给模型
• 长期偏好由谁写入、何时更新、按什么粒度召回
• 多轮执行中的 artifact 如何在不同 agent 之间被引用

换句话说，memory 不是存储层先行，而是 runtime contract 先行。

这也是为什么封闭 harness 最危险的地方，不在于“你看不到底层代码”，而在于你看不到那套上下文与状态管理协议。即使 provider 愿意导出一部分数据，也很难保证你能在另一套 harness 里恢复同样的行为。

真正形成锁定的，不只是数据，而是“记忆可操作性”

很多人会把 lock-in 理解为“数据在别人那里”，但在 Agent 领域，真正更深的锁定其实是另一层：你是否还拥有对记忆的操作权。

这里至少有三层递进。

第一层，状态型 API 锁定

如果你依赖 provider 的 server-side state，例如托管线程、后台压缩、服务端上下文延续，那么你切换模型、迁移供应商、复用历史任务的成本会明显上升。此时你失去的还主要是“迁移便利性”。

第二层，闭源 Harness 锁定

如果 harness 本身是黑箱，你不知道：

• 它如何抽取长期偏好
• 它如何决定什么该进入短期上下文
• 它怎样把工具结果变成可复用事实
• 它如何处理压缩摘要与历史工件

那你就不仅失去迁移便利性，还失去“行为可重建性”。即使导出了历史记录，你也不一定能在别的地方恢复出同样的 agent 体验。

第三层，托管式 Agent API 锁定

最强的一层，是 provider 直接把 harness、sandbox、memory、runtime 全部打包成托管服务。开发者拿到的是极低门槛的 agent 基建，但同时让渡的是更核心的东西：

• 状态主权
• 体验解释权
• 架构演化主动权
• 长期迁移能力

这时 lock-in 的本质已经不是“模型换起来麻烦”，而是你的产品经验资产正在被寄存在别人定义的运行时里。

为什么 Memory 会成为 Agent 产品的真正护城河

Harrison 这篇文章里还有一个判断我觉得非常现实：没有 memory，Agent 更容易被复制；有 memory，Agent 才会形成真正的差异化体验。

这点在静态 API 时代并不明显，因为那时候大家拼的是模型效果、提示词和少量工作流封装。你换一个 provider，虽然会麻烦，但不至于把产品体验整个打回原形。

但一旦 Agent 产品开始依赖下面这些能力，事情就变了：

• 记住用户的风格与禁忌
• 继承长期偏好与审批习惯
• 在多次会话之间接续任务状态
• 保留历史工件和操作上下文
• 持续学习组织内部流程与协作方式

此时 memory 承载的已经不是“聊天历史”，而是产品真正的经验资本。谁掌握这层资本，谁就更接近拥有数据飞轮和体验飞轮。

我甚至会把问题说得更直接一点：未来很多 Agent 产品的真正 moat，不是模型，也不是 UI，而是长期记忆如何被写入、解释、调用和迁移。

开放 Memory 并不等于“自己建个库”

不过，原文如果要继续往前走一步，还必须补上一个常被忽略的边界：开放 memory 不等于只把数据放回你自己的数据库。

如果没有更稳定的 schema 和运行时约束，所谓“自有 memory”也可能只是另一种脆弱实现。真正有价值的开放层，至少要回答几类问题：

1. 记忆对象是什么 是事实、偏好、任务状态、工件索引，还是行为规则？

1. 更新策略是什么 哪些信息要热路径写入，哪些适合后台整理，哪些只能人工确认？

1. 召回协议是什么 什么时候按语义召回，什么时候按任务作用域召回，什么时候按显式绑定召回？

1. 生命周期是什么 哪些是 session 内短期状态，哪些是长期 profile，哪些是项目级 artifact，哪些必须可过期、可撤销、可回滚？

1. 迁移接口是什么 如果今天从 provider A 切到 provider B，或从 harness X 切到 harness Y，哪些状态可以被完整导出和重放？

所以我更倾向于把目标叫做 memory fabric，而不是 memory plugin。它不是一个点功能，而是一层跨 runtime、跨 agent、跨 session 的状态面。

接下来行业会怎么分层

我不认为未来会是“开放赢，封闭输”这种简单叙事。

现实更可能是两层市场同时成立。

第一层，效率优先市场

大量团队会接受托管 harness 和托管 memory，因为他们真正需要的是：

• 更快上线
• 更少系统负担
• 更稳定的安全和审计
• 更少的基础设施维护

对于这类团队，牺牲一部分状态主权，换更低门槛和更强默认能力，是合理交易。

第二层，主权优先市场

另一类团队会越来越在意：

• 是否能迁移模型与 provider
• 是否能解释和重建长期体验
• 是否能把 memory 纳入自己的治理体系
• 是否能让 agent runtime 成为自己的基础设施资产

这类团队最终会更重视开放 harness、外置状态、可导出 session、可迁移 artifact，以及更明确的 memory schema。

也就是说，未来真正的竞争未必是“谁能做出 memory 功能”，而是谁能做出既开放、又可治理、还能真正服务生产任务的 memory runtime。

对今天做 Agent 的团队，最该先问的不是“要不要 memory”，而是“memory 归谁管”

如果把这篇文章压缩成一个最实际的问题，那就是：

你的 memory，到底归谁管？

不是谁帮你存，而是谁定义：

• 记忆的形状
• 记忆的入口
• 记忆的压缩方式
• 记忆的召回规则
• 记忆的迁移出口

如果这些关键规则都掌握在外部托管 harness 手里，你今天获得的是速度，明天付出的可能就是主权。

所以我会把结论说得比 Harrison 再往前一步：

Memory 不只是 Agent 的增强功能，而是 Agent 产品的主权边界；Harness 不只是工程壳，而是这条主权边界的实际控制层。

未来几年里，最值得关注的，不是谁先把“记忆”包装成一个看起来神奇的功能，而是谁先把 memory 做成一个开放、可治理、可迁移、又能与 runtime 深度协同的系统层。

这才是 Agent 时代真正更深的基础设施。