Agent 的长期记忆应该保存什么
决策与理由
最终选了什么方案、为什么放弃其他方案、哪些约束来自用户或生产环境。只有结论没有理由，下一次很难判断条件是否已经变化。
失败与修复
尝试过的命令、错误原因、有效修复和仍未解决的风险。记录失败能避免新会话重复执行同一条无效路径。
外部状态引用
仓库、提交、版本、工单和证据文件的位置。记忆应指向可核对事实，而不是用一段摘要替代真实状态源。
恢复位置
任务进行到哪一步、哪些动作已经执行、下一步需要什么条件。它让崩溃恢复比“重新读完整聊天”更准确。
不该永久保存的内容也很重要。密钥、Cookie、真实联系人、客户资料和原始个人文件不应因为“方便记忆”进入长期日志。
AgentMesh Runtime 的多层召回
| 层 | 作用 | 优势 | 限制 |
|---|---|---|---|
| Neo4j 图召回 | 按实体与关系找到相关事件 | 适合项目、产品、人物和决策之间的连接 | 需要本地 Neo4j；不可用时自动降级 |
| SQLite FTS5 | BM25 关键词排序与 snippet | 本地、快速、结果可解释 | 词汇不重合时召回有限 |
| 文件 grep | 直接搜索原始日志与文本 | 依赖少，适合作为最后回退 | 排序和语义能力有限 |
| 可选 Gemini 向量 | 按嵌入相似度补充召回 | 能找到措辞不同但语义相关的内容 | 需要用户自己的 Key，当前是 O(n) 余弦，不是学习型重排 |
任一后端不可用时，其他层仍可继续服务。Runtime 的目标不是承诺“完美记忆”，而是在个人与小团队规模提供可理解、可降级的召回路径。
一套简单、可持续的使用方式
- 复杂任务开始前：运行
agentmesh-runtime memory recall "任务主题" --top-k 5，先读历史决策与失败。 - 工作过程中：把关键观察、决定、动作和验证写入有界记录，而不是等结束后凭记忆补日志。
- 任务结束后：用
memory ingest-file导入经过清理的会话记录。 - 新会话或重启后：用
rehydrate组合检查点、近期记忆与仓库状态。 - 结果异常时：先运行
doctor，确认 Neo4j、SQLite、同步账本和检查点是否健康。
如果你最关心中断后如何继续，请阅读 AI Agent 崩溃恢复指南。
常见问题
Runtime 是否自带大模型？
不带。它是记忆、工作循环记录和恢复脚手架，真正推理由你正在使用的 Agent 提供。
召回是否全部是语义搜索？
不是。默认组合 Neo4j、SQLite FTS5 和文件检索；可选向量召回需要用户自己的 Gemini Key。
记忆数据会上传吗？
不会。Runtime 完全在用户机器上运行，不需要 AgentMesh360 账户或 API Key。