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 复制一份。