Agent Memory 应该放在 Runtime 还是 Application？
Agent Memory 是个很容易被讲乱的词。
有的人说 memory，就是把聊天记录存起来。
有的人说 memory，是向量库。
有的人说 memory，是用户画像。
还有的人说 memory，是 Agent 自己总结出来的经验。
这些都可能对，也都可能不够准。
我更愿意先问一个土一点的问题：
这段信息将来会影响谁的行动？
答案不同，memory 的位置就不同。
先别急着建 memory 表
很多项目一上来就建：
agent_memories
user_memories
conversation_memories
然后把模型说过的话、用户说过的话、摘要、偏好、工具结果，一股脑塞进去。
短期看很快。
长期看很痛。
因为你很快会遇到这些问题：
这条 memory 是事实，还是模型猜测？
谁写入的？
什么时候过期？
用户能不能删除？
下次是否一定进入上下文？
业务系统改了以后，memory 是否失效？
多个 Agent 共享时，谁负责冲突？
错误 memory 导致误操作，trace 能不能定位？
如果这些问题答不上来，memory 越多，Agent 越乱。
Memory 至少分四类
我建议先把 memory 拆成四类。
1. Context Memory
2. Run State Memory
3. User / Product Memory
4. Domain / Business Memory
它们不是同一种东西。
Context Memory
Context Memory 是为了本次任务继续推进。
比如：
用户当前目标
最近几步做了什么
测试失败原因
已经读过哪些文件
哪些工具结果被截断
当前计划是什么
它主要由 Runtime 管。
因为它直接影响 Context Builder：本轮给模型看什么，不给模型看什么，哪些必须保留，哪些可以摘要。
这类 memory 不一定要长期保存。它更像运行案卷。
Run State Memory
Run State Memory 是为了恢复和审计。
比如：
runId / stepId / traceId
tool ledger
permission decisions
checkpoint
预算状态
文件写入前后 hash
它必须由 Runtime 管。
Application 可以展示它，但不应该随便改。
如果这类状态被业务层随手覆盖，resume 和 rollback 就不可信了。
User / Product Memory
User Memory 是用户偏好和产品层事实。
比如：
用户喜欢中文回答
默认使用 pnpm
某个团队禁止自动执行 shell
用户常用项目路径
某个 workspace 的代码风格
这类更接近 Application。
因为它涉及用户账户、隐私、权限、删除、导出、跨设备同步和产品体验。
Runtime 可以读取它，用来构建上下文或策略，但写入要谨慎。
'模型觉得用户喜欢 X'不应该自动变成长期偏好。
Domain / Business Memory
Business Memory 是业务系统里的事实。
比如：
订单状态
客户合同
工单 SLA
库存数量
代码仓库权限
CRM 里的客户标签
这类通常不应该被 Agent Memory 复制一份。
Runtime 应通过工具实时读取权威系统，或者缓存带版本和过期时间的只读摘要。
业务事实最怕被模型摘要成'差不多'。
差不多，在业务系统里就是错。
一个简单判断表
可以用这张表决定 memory 放哪：
| 信息类型 | 主要归属 | 原因 |
|---|---|---|
| 当前任务进度 | Runtime | 影响下一步模型上下文 |
| 工具调用账本 | Runtime | 影响恢复和幂等 |
| checkpoint | Runtime | 影响 resume / rollback |
| 用户偏好 | Application | 涉及账号、隐私、删除和同步 |
| 团队策略 | Application + Runtime | 应用保存，Runtime 执行 |
| 业务事实 | Business System | 权威来源不应复制成记忆 |
| 长期经验摘要 | Application 审核后保存 | 需要写入策略和可解释来源 |
注意这里不是二选一。
很多 memory 会跨层。
比如'用户默认不允许联网'：
Application 保存这个偏好。
Runtime 在 PermissionGate 里执行。
Trace 记录这次拒绝来自哪个 policy。
Context Builder 只给模型看到必要约束。
这才是正确姿势。
Runtime 不能随便写长期记忆
我比较反对让 Agent 自动把每轮对话总结成长期 memory。
原因很简单：模型会误读。
用户说：
这次先别跑测试。
模型可能总结成：
用户不喜欢运行测试。
这就坏了。
用户说：
这个项目暂时用 npm。
模型可能写成：
用户偏好 npm。
也不对。
长期 memory 写入应该有来源、范围和置信度：
type LongTermMemory = {
id: string;
subject: "user" | "workspace" | "team" | "project";
content: string;
source: {
runId: string;
traceId: string;
evidenceRef: string;
};
scope: string;
confidence: "explicit" | "inferred" | "low";
expiresAt?: string;
createdBy: "user" | "system" | "agent_suggested";
approvedByUser: boolean;
};
最关键的是 confidence。
用户明确说的，和模型推断的，不是同一等级。
Context Builder 是 memory 的入口
Memory 最终要不要影响模型，取决于 Context Builder。
不是所有保存过的信息都应该进入上下文。
Context Builder 要按预算和风险筛选：
当前目标必须进
安全策略必须进
最近失败优先进
用户明确偏好可进
低置信度推断少进
过期 memory 不进
业务事实通过工具实时查
这也是我说 Context Engineering 是 Runtime 核心模块的原因。
Memory 存在哪里是一回事。
Memory 怎样进入模型视野，是另一回事。
如果没有 Context Builder，memory store 只是一个越来越脏的仓库。
Memory 要进入 Trace
如果某条 memory 影响了 Agent 行动，trace 里应该看得见。
比如模型没有运行测试，因为上下文里放了：
project_policy: nonInteractive=true, shell_readonly=false
trace 至少要记录：
context.memory.used: project_policy
memory.source: app_policy_store
policy.version: 2026-08-16
decision: shell denied
否则事故复盘时会很尴尬：
'Agent 为什么没跑测试？'
没人知道。
模型说它以为不能跑。
Runtime 说 policy 禁止了。
Application 说用户偏好里没有这条。
最后大家翻聊天记录。
这就是 trace 缺失。
Memory 和 Checkpoint 不要混
Checkpoint 不是长期 memory。
Checkpoint 保存的是一次 run 能不能安全恢复。
Memory 保存的是未来任务可能会用到的信息。
这两个东西可以互相引用，但不要混成一张表。
比如：
checkpoint:
step 7 已执行 write_file
文件 hash 从 A 到 B
用户批准 approval_42
memory:
这个 workspace 默认使用 pnpm
前者是恢复证据。
后者是上下文偏好。
如果你把 checkpoint 当 memory，下次任务可能带入无关运行状态。
如果你把 memory 当 checkpoint，恢复时会丢失工具副作用证据。
这两个错都很难排。
向量库不是 Memory 的全部
很多人谈 memory，马上想到 vector database。
向量库有用。
它适合做语义检索：
历史问题
文档片段
用户笔记
相似工单
代码摘要
但向量库不是 memory 架构。
它回答的是'哪些内容语义相近'。
它不回答：
这条信息是否仍然有效？
谁授权使用？
是否是权威事实？
是否能跨 workspace 使用？
是否能进入本次模型上下文？
是否影响权限决策？
是否需要用户可删除？
所以向量库应该是 memory subsystem 的一个索引，不是整个 memory subsystem。
我会怎么设计第一版
第一版不要贪。
我会这样做：
Runtime:
- RunState
- RunStep
- ToolLedger
- Checkpoint
- ContextDigest
Application:
- UserPreference
- WorkspacePreference
- TeamPolicy
- MemorySuggestion
Business:
- Order / Ticket / Customer / Repo 权威数据
ContextBuilder:
- 统一读取这些来源
- 按预算筛选
- 写 debug report
长期 memory 写入先做'建议'，不要自动入库：
Agent suggested:
用户似乎偏好 pnpm。
证据：
run_12 中用户明确要求'这个仓库以后用 pnpm'。
作用域：
workspace: agent-runtime-engineering
是否保存？
用户点确认后再保存。
这样慢一点，但可信。
结论
Agent Memory 应该放在 Runtime 还是 Application？
我的答案：
运行状态放 Runtime。
用户偏好放 Application。
业务事实留在业务系统。
进入模型上下文由 Context Builder 统一调度。
影响行动的 memory 必须进 trace。
不要把 memory 做成一个万能垃圾桶。
