AI Infra：状态要分离，记忆要中立
当各大厂纷纷推出类 openclaw 服务，就有了各种各样的“虾”，加上各种 AI Chatbot、AI Cli，每天要有很多很多孤立的窗口。我们需要属于自己的“集中”记忆。
一、为什么 openclaw 类服务必然走向“记忆层分离”
先看约束条件，也就是分散的部署：
| 约束 | 本质问题 | 结果 |
|---|---|---|
| 多厂商模型 | 上下文不可迁移 | agent 被锁死 |
| 多设备运行 | 状态不同步 | 用户体验断裂 |
| 长期交互 | token窗口有限 | 历史被压缩/丢失 |
| 多agent协作 | 无共享状态 | 无法形成系统级智能 |
“状态（memory）必须独立于模型和执行体存在”，也就是：Model ≠ Agent ≠ Memory
今天大多数 openclaw 类服务的问题在于，memory 被隐式绑定在“某一个 agent 实例 + 某一个厂商 API”里，这直接导致无法迁移、无法协作、无法进化。
个体很难有技术能力把这些分散的记忆管理起来，于是出现了一个“中立”记忆层服务的空间。
二、“中立记忆层”是什么
市场上很多以 AI agent 记忆服务为基础的项目，从技术栈上看，会让很多人会把它理解为：向量数据库 + RAG系统 + 用户知识库，但这样少了一些内容。
从系统角度，记忆层至少包含 4 类结构：
| 层级 | 类型 | 示例 | 是否结构化 |
|---|---|---|---|
| L1 | 短期上下文 | 当前任务状态 | 半结构 |
| L2 | 语义记忆 | 用户偏好、知识片段 | 向量+文本 |
| L3 | 过程记忆 | agent如何完成任务 | 强结构 |
| L4 | 社会记忆 | 多agent共享状态 | 图结构 |
真正稀缺的是 L3（过程记忆）和 L4（协同记忆）
三、“中立”的核心设计约束
“中立”不是商业中立，而是系统中立：
3.1 不依赖模型
- 不绑定 OpenAI / Anthropic / 本地模型
- memory 可以被任意 agent 读取和写入
3.2 不依赖执行环境，必须共享同一 memory substrate
- CLI agent（iflow）
- Telegram bot（picoclaw）
- 本地 agent
- 浏览器 agent
3.3. 不依赖协议（或协议最小化）
不被单个 SDK 绑定，不依赖私有协议（不是说微信），理想状态：
Memory = HTTP3 / KV / Graph API
四、聚合并迭代的记忆，是 Agent的能力基线
中立且聚合的记忆，改变的不是功能，而是能力上限。没有记忆层，AI是“工具”；有记忆层，AI才是“系统”
4.1 对比：没有记忆层（当前主流）
- agent = stateless function
- 每次从零开始
- 智能无法累积
4.2 有记忆层
- agent = stateful system
- 能形成：用户模型、世界模型、自我优化路径
五、“分散部署，协同进化”是一个有趣的命题
这个命题成立有三个必要条件：
5.1 本地优先（Local-first）
- memory 存在用户侧（VPS / device）
- 不是中心云
否则，又变成平台垄断（容易迁移的云服务也算一种本地优先的变体）
5.2 可交换（Interoperable）
Agent A → 贡献经验 → Agent B 可复用
这意味着 memory 需要支持：
- 标准化 schema
- 版本控制
- provenance（来源追踪）
5.3. 可进化（Evolvable）
记忆不是“存”，而是：压缩（summarization）、抽象（pattern extraction）、重写（self-reflection）
这部分如果不做，memory 会迅速退化为垃圾堆，上下文的价值被稀释
总结定义：“Agent Memory Layer = 一个独立于模型与执行体的、可演化的状态系统，用于支持跨agent的长期认知积累与协作。”