记忆不是插件，而是 Agent Harness 的核心能力！

科技前沿 • 2026-04-15 20:17 • 阅读 2

大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。

本文已收录在Github，关注我，紧跟本系列专栏文章，咱们下篇再续！

🚀 魔都架构师 | 全网30W技术追随者
🔧 大厂分布式系统/数据中台实战专家
🏆 主导交易系统百万级流量调优 & 车联网平台架构
🧠 AIGC应用开发先行者 | 区块链落地实践者
🌍 以技术驱动创新，我们的征途是改变世界！
👉 实战干货：编程严选网

自从我们开始开发 MemGPT（现在的 @Letta_AI）以来，@charlespacker 和我经常被问到一个问题：

“我该怎么把你们的记忆系统接入到我的 agent 里？”

在我看来，这个问题本身就不太成立。把记忆“接入”一个 agent harness，就好比问“怎么把驾驶功能装进一辆车”。上下文管理（也就是记忆管理）本来就是 agent harness 的核心能力和职责。如果一个 harness 不负责管理上下文，那它还有什么作用？

基于历史会话数据（或其处理结果）做 RAG，确实可以作为一种插件——但检索只是记忆的一小部分。而且即便只看检索，实际效果也很难显著优于简单的 grep。

由于 RAG 经常被当作“记忆”来宣传，MemGPT 也常常被误解为一个 RAG 工具或可插拔的记忆模块。但实际上，在“harness”这个概念出现之前，MemGPT 本质上就是一个有状态的 agent harness。智能体的记忆，来自于 harness 提供的工具（用于重写 prompt 和管理外部状态），再加上 harness 自身的上下文管理机制。

归根结底，harness 会做出大量“看不见”的关键决策，而这些是外部插件无法控制的：

AGENTS.md 或 CLAUDE.md 是如何加载进上下文的？
技能（skill）的元数据是如何呈现给智能体的？（是在 system prompt 中，还是 system message 中？）
智能体能否修改自己的系统指令？
上下文压缩（compaction）时，哪些内容会被保留，哪些会丢失？
交互记录是否会被存储，并支持查询？
记忆的元数据是如何展示给智能体的？
当前工作目录如何表示？暴露了多少文件系统信息？

不同的 harness 对这些问题都有不同的实现方式。你的上下文窗口里，很可能已经包含了各种通过 system message 注入的提示信息，只是你看不到而已。

举个例子：在最近对 Claude Code 记忆系统的分析中（基于泄露的源码），可以看到一个多层级的记忆体系是如何直接构建在 harness 内部的。

而 Letta Code（一个以记忆为核心的 agent harness）更进一步：它将智能体的记忆映射到一个由 Git 支持的文件系统中，并允许后台的“记忆子代理”并行地对其进行修改，这些子代理专注于 prompt 重写和主动记忆管理。

Letta 最近发布的 Context Constitution（上下文**）总结了一套智能体在管理上下文时应遵循的通用原则，而这些原则与 harness 的设计是深度耦合的。

https://x.com/Letta_AI/status/?s=20

归根结底，harness 如何管理上下文和整体状态，决定了智能体记忆的本质。

如果你想体验“以记忆为核心”的 agent harness，可以试试 Letta Code（支持 Codex 方案 + 自带密钥 BYOK），并关注 @Letta_AI：

npm install -g @letta-ai/letta-code

记忆不是插件，而是 Agent Harness 的核心能力！

相关推荐