Hindsight 记忆备份操作手册自动备份与灾难恢复【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsight你刚把生产机器换成新机器AI 智能体就失忆了项目上下文、用户偏好、积累几个月的业务知识随着旧数据库一起消失。问题不在代码而在你没做Hindsight 记忆备份——记忆全存在 PostgreSQL 里库没了智能体的认知就归零。下面带你走完首次备份、自动备份、出事恢复的完整链路。先搞清楚哪些记忆值得救Hindsight 把智能体记忆全部落在 PostgreSQL 中。hindsight-admin backup会在一个REPEATABLE READ事务里做快照保证 zip 里各表数据彼此一致。备份内容大致分六类数据内容丢失后果记忆银行与配置bank 定义、模型与检索配置智能体失去容器配置回到默认文档与分块原始对话、上传文件及其 chunk原始素材丢失事实难以重新推导记忆单元facts / experiences / observationsLLM 提炼后的事实、经验、观察最致命智能体认知基础丢即失忆实体与关系实体图、共现、记忆链接检索图谱塌掉多跳召回失效心智模型与指令长期世界观、行为约束行为风格重置内部运维表异步操作、审计日志、队列恢复后快照不完整记忆合并策略新事实按三种模式并入已有知识都是备份需要覆盖的对象。如果只记一句话记忆单元和心智模型是 LLM 从原始对话蒸馏出来的结果原始素材可以重新喂蒸馏结果无法重演。这就是备份包的核心。第一次备份三步走通完整链路hindsight-admin直连 PostgreSQL不走 HTTP API读取与 API 相同的配置所以要在部署了 API 的同一台主机或容器里执行环境变量自动继承。第 1 步安装工具。管理 CLI 随hindsight-api包一起分发pip install hindsight-api hindsight-admin --help成功标志--help能列出命令清单其中包含backup和restore。第 2 步配置数据库连接。CLI 默认指向内置的pg0开发库生产环境必须显式指向你的 PostgreSQLexport HINDSIGHT_API_DATABASE_URLpostgresql://user:passhost:5432/hindsight hindsight-admin worker-status成功标志worker-status返回任务列表可以为空且没有连接报错说明连对了库。第 3 步执行首次备份。mkdir -p /backups/hindsight hindsight-admin backup /backups/hindsight/first.zip成功标志文件生成且大小非空ls -lh可见 MB 级尺寸说明整个 schema 的快照已落盘。Docker 或 K8s 部署时用docker exec/kubectl exec进 API 容器执行同样的命令即可。 让备份自己跑起来手工备份靠自觉定时任务靠机器。把脚本放到/usr/local/bin/hindsight-backup.sh#!/bin/bash BACKUP_DIR/var/backups/hindsight DATE$(date %F) hindsight-admin backup $BACKUP_DIR/hindsight-$DATE.zip || echo backup failed 2 find $BACKUP_DIR -name *.zip -mtime 30 -delete再配一行 crontab0 2 * * * /usr/local/bin/hindsight-backup.sh每天凌晨 2 点自动备份并清理旧包。保留期改一处即可-mtime 30表示 30 天改成7就是 7 天90是一个季度。多租户部署下多租户备份用循环加--schema tenant_xxx逐个租户执行每个 schema 一个独立 zip恢复时可以互不影响。多租户记忆隔离由存储边界强制多租户备份与恢复沿同一边界进行。出事了恢复三步走故障发生时——库挂了、误删了、要回滚一次坏迁移——智能体记忆灾难恢复的路径是固定的选包、恢复、验证。选备份包。用ls -lh /var/backups/hindsight/列出目录挑日期正确、体积正常的那个并确认它属于哪个 schema。执行恢复。默认 schema 和单租户各一条命令hindsight-admin restore /backups/hindsight-2026-09-14.zip --yes hindsight-admin restore /backups/tenant-acme.zip --schema tenant_acme --yes--yes跳过交互确认适合脚本调用手工执行时去掉它先过一次确认提示再决定。⚠️高危操作restore会先删除目标 schema 中的全部现有数据再导入备份这是整体覆盖而非增量合并。执行前必须确认你手里还有一份覆盖当前状态的近期备份否则备份点之后新写入的数据会随覆盖一起消失。恢复后验证。三项都过了才算恢复完成并记录耗时与结果核对记忆银行数量与事故前一致可用银行列表接口抽查如curl -s http://localhost:8888/v1/default/banks抽 2–3 段已知关键对话确认原始文档还能查到发 2–3 个有代表性的 recall 请求做检索冒烟测试对比命中是否与事故前相当。按你的环境选策略不同环境的 PostgreSQL 备份策略不必一个节奏建议按下表分配环境备份频率保留期生产每日全量写入高峰可加小时级30 天另留一份长期归档开发每日全量7 天测试每周全量14 天RTO指故障后你最多能接受停多久RPO指你最多能丢多少数据。这两个数字直接决定备份间隔能接受丢 24 小时记忆就每日备一次只能接受丢 1 小时就得把间隔缩到小时级再配合数据库日志归档兜底。拿不准时先用每日 30 天起步跑一个月再调。五个最常踩的坑只备不练备份跑了半年没人验证过它能恢复——每月在测试环境做一次恢复演练恢复最新包并比对银行数量。备份不异地zip 和数据库在同一块盘上盘坏则双失——定期把 zip 同步到 S3 或异地 NAS本地只算最近的一份不算唯一一份。恢复前没确认目标环境把开发包恢复到生产库——执行前先看一眼当前HINDSIGHT_API_DATABASE_URL和--schema指向哪里。备份与版本不匹配升级后 schema 结构已变老包可能恢复失败——备份时记下 Hindsight 版本号大版本升级先用新版本做一份备份再切换。没有备份成功率监控连续三天失败你毫无察觉——脚本里检查退出码失败即告警。写在最后定期备份决定你能丢多少恢复演练决定这个丢多少是否真实异地存放决定单点故障能否带走一切。这周把首次备份做掉本月把恢复真跑一遍。延伸阅读官方文档 docs/official.md、AI 功能源码 plugins/ai/。【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsight创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考