Hindsight 智能体记忆备份完全指南4 步自动备份 灾难恢复实操手册【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsightHindsight 的智能体记忆存在 PostgreSQL 中一次磁盘故障就可能让数月积累的知识清零。本指南带你看清 Hindsight 记忆自动备份与灾难恢复的全部实操首次备份四步走、定时任务、多租户备份与恢复验证。故障场景数据库损坏后智能体记忆全部消失假设你的编码智能体已经用 Hindsight 运行了半年用户偏好、项目约定、踩过的坑、历史决策全部沉淀在记忆银行里。某天数据库文件损坏或者更常见的——某次误操作执行了DROP SCHEMA重启之后智能体失忆它不认识你的项目不知道哪些 API 已经被废弃所有历史对话的上下文也找不回来。重新积累这些知识可能需要几周而代价是你和用户的信任。Hindsight 官方在 admin-cli 文档中把备份和恢复做成了hindsight-admin命令的一部分整条链路就是backup生成 zip 归档 → 定时执行 → 出事时restore一键回灌。下面按这个链路拆开讲。保什么、存哪、用什么保核心概念速览一句话版本Hindsight 记忆备份 用hindsight-admin backup把 PostgreSQL 里与记忆相关的所有表导出成 zip 归档恢复时用restore原样写回。问题答案保什么记忆银行及其配置、文档与分块、实体及关系、记忆单元事实/经验/观察、实体共现与记忆链接、心智模型与指令、Webhooks 与文件存储以及异步操作、审计日志等内部运维表存在哪PostgreSQL 数据库。默认操作public模式多租户部署用--schema指向各租户模式用什么保hindsight-admin backup产出的 zip 文件。整个导出在REPEATABLE READ可重复读隔离级别事务里完成保证所有表是同一个时间点的一致快照两个实现细节值得知道CLI 不走 HTTP API而是直连数据库基于二进制COPY协议所以它只支持 PostgreSQL且要跑在和 API 服务同一台主机或容器里这样能自动继承相同的环境配置。命令实现见 hindsight_api/admin/cli.py备份表清单与真实 schema 的一致性由 test_admin_backup_restore.py 守护。 四步完成 Hindsight 首次记忆备份第 1 步装工具。hindsight-admin随hindsight-api包一起安装装完可执行文件就直接进PATH不需要额外下载pip install hindsight-api这一步同时决定 CLI 连哪个库所以下一行的环境变量要一起配好。第 2 步配环境。CLI 和 API 服务读同一套配置核心就是数据库连接串HINDSIGHT_API_DATABASE_URL不设置时它默认指向pg0内嵌开发库生产环境务必显式设置export HINDSIGHT_API_DATABASE_URLpostgresql://user:passlocalhost:5432/hindsight如果 API 跑在 Docker 或 Kubernetes 里更省事的做法是直接进容器执行命令例如docker exec -it hindsight-api hindsight-admin backup /data/backup.zip容器内的配置天然就是对的。第 3 步执行备份。指定输出路径即可文件名没带.zip后缀时会自动补上多租户部署用--schema单独备份某个租户hindsight-admin backup /backups/hindsight-2026-09-15.zip hindsight-admin backup /backups/tenant-acme.zip --schema tenant_acme执行过程中会逐表打印进度[1/N] Backing up banks...全绿结束即完成。第 4 步验证结果。备份 zip 里包含清单文件和每张表的转储用unzip -l列出归档内容、确认表数量与大小符合预期再挑一条代表性的记忆查询recall跑一遍确认当前库本身健康——先证明源数据是好的备份才有意义。用定时任务和保留策略让备份变成自动行为一次性备份只是开始真正防丢的是它每天都自己跑。把备份挂到 crontab每天凌晨 2 点执行同时只保留最近 30 天的归档避免磁盘被备份文件塞满0 2 * * * hindsight-admin backup /var/backups/hindsight/hindsight-$(date \%F).zip find /var/backups/hindsight -name *.zip -mtime 30 -delete保留多久、备份多频繁可以按环境分级这里给一个常用基线环境频率保留生产每日全量 重要变更前后手动加一次30 天以上另留一份周归档开发每日7 天测试每周14 天Kubernetes 部署同理进 pod 执行即可kubectl exec deploy/hindsight-api -- hindsight-admin backup /data/backup.zip。多租户场景下把每个租户模式写成一条独立的 crontab 任务各自生成带租户名的归档。这样任一租户出问题时恢复操作只影响它自己的模式不会波及其他租户——这就是单银行与多银行架构在备份粒度上的直接收益 一键命令恢复智能体记忆灾难恢复手册恢复命令本身很短普通模式会先弹确认提示脚本化加--yes跳过hindsight-admin restore /backups/hindsight-2026-09-15.zip hindsight-admin restore /backups/tenant-acme.zip --schema tenant_acme --yes⚠️高危操作restore会先删除目标模式中的全部现有数据再导入归档。动手之前先对当前状态做一次新备份留作回滚点并确认归档日期是你想要的版本——没有确认备份比事故更旧还是更新就按回车等于二次事故。恢复完成后建议按这份清单验证数据完整性核对记忆银行数量与事故前记录一致抽查关键对话和事实比如项目约定类的条目是否可读跑 2~3 条代表性的 recall 查询确认检索结果正常注意逻辑恢复不会自动重建每个银行的局部向量索引恢复后执行一次hindsight-admin repair-bank --all可先--dry-run预览否则银行级检索会退化成慢速的全局索引回退观察智能体行为一段时间确认与事故前的记忆表现一致。进阶篇分层备份、RTO/RPO 与高可用演练备份文件放在哪、放几层按数据价值设计常见分法是第一层放本地磁盘恢复最快留给最近几天第二层同步到云对象存储如 AWS S3、GCS防机房级故障第三层做长期冷归档满足合规留痕。备份频率不用拍脑袋两个术语就够了RTORecovery Time Objective恢复时间目标指系统最多容忍停多久决定你多久备一次RPORecovery Point Objective恢复点目标指最多能丢多少数据决定两次备份之间隔多久。例如要求 RPO ≤ 1 小时就得上小时级备份或依赖数据库层的流复制兜底。生产环境通常再加一层高可用HA即 High Availability故障时业务基本不中断架构PostgreSQL 主从复制做实时兜底hindsight-admin backup的逻辑快照做版本级兜底两者互补而不是二选一——复制解决库挂了快照解决库里的数据被写坏了。最后把每月一次恢复演练排进日历在隔离环境恢复最新归档 → 走一遍上面的验证清单 → 记录实际耗时。没演练过的恢复流程第一次用到往往是在最狼狈的时候。落地前必须做到的 4 件事今天跑完首次备份并用unzip -l确认归档包含全部记忆表挂上定时任务每日备份 30 天保留归档再传一份到对象存储恢复先留后手任何restore之前先对现状做一次备份恢复后执行验证清单含repair-bank --all每季度演练一次把实际 RTO 记下来和承诺的业务中断窗口对比。命令细节与全部选项--schema、--yes等以 admin-cli 官方文档为准实现源码在 hindsight_api/admin/cli.py。【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsight创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Hindsight 智能体记忆备份完全指南：4 步自动备份 + 灾难恢复实操手册
Hindsight 智能体记忆备份完全指南4 步自动备份 灾难恢复实操手册【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsightHindsight 的智能体记忆存在 PostgreSQL 中一次磁盘故障就可能让数月积累的知识清零。本指南带你看清 Hindsight 记忆自动备份与灾难恢复的全部实操首次备份四步走、定时任务、多租户备份与恢复验证。故障场景数据库损坏后智能体记忆全部消失假设你的编码智能体已经用 Hindsight 运行了半年用户偏好、项目约定、踩过的坑、历史决策全部沉淀在记忆银行里。某天数据库文件损坏或者更常见的——某次误操作执行了DROP SCHEMA重启之后智能体失忆它不认识你的项目不知道哪些 API 已经被废弃所有历史对话的上下文也找不回来。重新积累这些知识可能需要几周而代价是你和用户的信任。Hindsight 官方在 admin-cli 文档中把备份和恢复做成了hindsight-admin命令的一部分整条链路就是backup生成 zip 归档 → 定时执行 → 出事时restore一键回灌。下面按这个链路拆开讲。保什么、存哪、用什么保核心概念速览一句话版本Hindsight 记忆备份 用hindsight-admin backup把 PostgreSQL 里与记忆相关的所有表导出成 zip 归档恢复时用restore原样写回。问题答案保什么记忆银行及其配置、文档与分块、实体及关系、记忆单元事实/经验/观察、实体共现与记忆链接、心智模型与指令、Webhooks 与文件存储以及异步操作、审计日志等内部运维表存在哪PostgreSQL 数据库。默认操作public模式多租户部署用--schema指向各租户模式用什么保hindsight-admin backup产出的 zip 文件。整个导出在REPEATABLE READ可重复读隔离级别事务里完成保证所有表是同一个时间点的一致快照两个实现细节值得知道CLI 不走 HTTP API而是直连数据库基于二进制COPY协议所以它只支持 PostgreSQL且要跑在和 API 服务同一台主机或容器里这样能自动继承相同的环境配置。命令实现见 hindsight_api/admin/cli.py备份表清单与真实 schema 的一致性由 test_admin_backup_restore.py 守护。 四步完成 Hindsight 首次记忆备份第 1 步装工具。hindsight-admin随hindsight-api包一起安装装完可执行文件就直接进PATH不需要额外下载pip install hindsight-api这一步同时决定 CLI 连哪个库所以下一行的环境变量要一起配好。第 2 步配环境。CLI 和 API 服务读同一套配置核心就是数据库连接串HINDSIGHT_API_DATABASE_URL不设置时它默认指向pg0内嵌开发库生产环境务必显式设置export HINDSIGHT_API_DATABASE_URLpostgresql://user:passlocalhost:5432/hindsight如果 API 跑在 Docker 或 Kubernetes 里更省事的做法是直接进容器执行命令例如docker exec -it hindsight-api hindsight-admin backup /data/backup.zip容器内的配置天然就是对的。第 3 步执行备份。指定输出路径即可文件名没带.zip后缀时会自动补上多租户部署用--schema单独备份某个租户hindsight-admin backup /backups/hindsight-2026-09-15.zip hindsight-admin backup /backups/tenant-acme.zip --schema tenant_acme执行过程中会逐表打印进度[1/N] Backing up banks...全绿结束即完成。第 4 步验证结果。备份 zip 里包含清单文件和每张表的转储用unzip -l列出归档内容、确认表数量与大小符合预期再挑一条代表性的记忆查询recall跑一遍确认当前库本身健康——先证明源数据是好的备份才有意义。用定时任务和保留策略让备份变成自动行为一次性备份只是开始真正防丢的是它每天都自己跑。把备份挂到 crontab每天凌晨 2 点执行同时只保留最近 30 天的归档避免磁盘被备份文件塞满0 2 * * * hindsight-admin backup /var/backups/hindsight/hindsight-$(date \%F).zip find /var/backups/hindsight -name *.zip -mtime 30 -delete保留多久、备份多频繁可以按环境分级这里给一个常用基线环境频率保留生产每日全量 重要变更前后手动加一次30 天以上另留一份周归档开发每日7 天测试每周14 天Kubernetes 部署同理进 pod 执行即可kubectl exec deploy/hindsight-api -- hindsight-admin backup /data/backup.zip。多租户场景下把每个租户模式写成一条独立的 crontab 任务各自生成带租户名的归档。这样任一租户出问题时恢复操作只影响它自己的模式不会波及其他租户——这就是单银行与多银行架构在备份粒度上的直接收益 一键命令恢复智能体记忆灾难恢复手册恢复命令本身很短普通模式会先弹确认提示脚本化加--yes跳过hindsight-admin restore /backups/hindsight-2026-09-15.zip hindsight-admin restore /backups/tenant-acme.zip --schema tenant_acme --yes⚠️高危操作restore会先删除目标模式中的全部现有数据再导入归档。动手之前先对当前状态做一次新备份留作回滚点并确认归档日期是你想要的版本——没有确认备份比事故更旧还是更新就按回车等于二次事故。恢复完成后建议按这份清单验证数据完整性核对记忆银行数量与事故前记录一致抽查关键对话和事实比如项目约定类的条目是否可读跑 2~3 条代表性的 recall 查询确认检索结果正常注意逻辑恢复不会自动重建每个银行的局部向量索引恢复后执行一次hindsight-admin repair-bank --all可先--dry-run预览否则银行级检索会退化成慢速的全局索引回退观察智能体行为一段时间确认与事故前的记忆表现一致。进阶篇分层备份、RTO/RPO 与高可用演练备份文件放在哪、放几层按数据价值设计常见分法是第一层放本地磁盘恢复最快留给最近几天第二层同步到云对象存储如 AWS S3、GCS防机房级故障第三层做长期冷归档满足合规留痕。备份频率不用拍脑袋两个术语就够了RTORecovery Time Objective恢复时间目标指系统最多容忍停多久决定你多久备一次RPORecovery Point Objective恢复点目标指最多能丢多少数据决定两次备份之间隔多久。例如要求 RPO ≤ 1 小时就得上小时级备份或依赖数据库层的流复制兜底。生产环境通常再加一层高可用HA即 High Availability故障时业务基本不中断架构PostgreSQL 主从复制做实时兜底hindsight-admin backup的逻辑快照做版本级兜底两者互补而不是二选一——复制解决库挂了快照解决库里的数据被写坏了。最后把每月一次恢复演练排进日历在隔离环境恢复最新归档 → 走一遍上面的验证清单 → 记录实际耗时。没演练过的恢复流程第一次用到往往是在最狼狈的时候。落地前必须做到的 4 件事今天跑完首次备份并用unzip -l确认归档包含全部记忆表挂上定时任务每日备份 30 天保留归档再传一份到对象存储恢复先留后手任何restore之前先对现状做一次备份恢复后执行验证清单含repair-bank --all每季度演练一次把实际 RTO 记下来和承诺的业务中断窗口对比。命令细节与全部选项--schema、--yes等以 admin-cli 官方文档为准实现源码在 hindsight_api/admin/cli.py。【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsight创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考