ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

5分钟锁住AI智能体记忆:Hindsight备份与恢复实战

5分钟锁住AI智能体记忆:Hindsight备份与恢复实战 5分钟锁住AI智能体记忆Hindsight备份与恢复实战【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsight如果你在用 Hindsight 为 AI 智能体积累长期记忆大概率担心过一件事数据库故障、误操作发生时这些记忆数据怎么办这篇文章直接围绕内置的 hindsight-admin 命令行工具带你完成第一次记忆备份、走通恢复流程并学会把整个记忆银行迁到新实例。三步完成第一次 Hindsight 记忆备份hindsight-admin 随 hindsight-api 包一起提供pip install hindsight-api装完即可用。它不走 HTTP 接口而是直连 PostgreSQL 读同一份配置所以备份是数据库层的一致性快照。注意它只支持 PostgreSQL 部署。用HINDSIGHT_API_DATABASE_URL指向要保护的那个库不设则默认连本地嵌入的 pg0 开发库执行备份几分钟内得到一个 zip 全量快照需要时一条命令恢复。hindsight-admin backup /backups/hindsight-0115.zip hindsight-admin restore /backups/hindsight-0115.zip --yes这个 zip 的内容很完整记忆银行及配置、文档与分块、实体及关系、记忆单元事实、经验、观察、心智模型、指令、webhook连异步队列、审计日志这类运维表都包含在内。整个备份在REPEATABLE READ隔离级别的事务里完成保证所有表停留在同一时刻不会出现文档是新版的、实体是旧版的这种撕裂。按三种常见角色选对备份方式个人开发者本机实例一键全量单实例开发场景下什么都不用配直接对默认publicschema 备份。zip 文件就是全部记忆丢进备份目录或同步到云盘恢复时对着同一个库执行 restore 即可。运维工程师在容器里执行备份API 跑在 Docker 里时不用单独准备环境直接 exec 进 API 容器执行容器已带正确配置和网络可达docker exec -it hindsight-api hindsight-admin backup /data/backup.zipKubernetes 同理kubectl exec deploy/hindsight-api -- hindsight-admin backup /data/backup.zip。好处是备份命令永远和线上配置保持同一状态不会出现备份脚本连错库的低级错误。平台团队多记忆银行独立备份一个实例承载多个租户时用--schema把备份粒度拆到 schema 级hindsight-admin backup /backups/tenant-acme.zip --schema tenant_acme恢复时也按同样粒度还原某个租户的数据出了问题不会牵连整个实例。进阶配置值得留意的四个设置设置用在哪效果HINDSIGHT_API_DATABASE_URL所有 admin 命令前决定 CLI 实际操作的数据库默认是嵌入开发库--schemabackup / restore / decommission把操作限定在指定租户 schema--yesrestore / decommission跳过交互确认适合 cron 脚本repair-bank --all恢复或跨版本升级之后重建每个银行的部分向量索引防止检索静默退化最后一条容易被漏掉正常建库时索引会自动维护但逻辑恢复出来的银行不走创建路径必须手动跑一次hindsight-admin repair-bank --all。它用并发方式建索引不阻塞在线读写幂等可重复执行。常见坑与排查现象恢复后检索变慢、结果变少。原因恢复路径没自动补建银行级部分向量索引银行悄悄退回全局索引后置过滤。处理跑一次repair-bank --all。现象恢复后pending_consolidation只增不减任务卡在 processing。原因Docker 重启后容器名变化worker ID 跟着变旧任务成了没人认领的孤儿。处理先用hindsight-admin worker-status找出卡住的 worker再decommission-worker id释放分不清死没死就用decommission-workers整体释放。长期方案是把HINDSIGHT_API_WORKER_ID固定成稳定值。现象import-bank报目标银行已存在。原因导入是整库还原而非合并同名银行存在时直接拒绝。处理先删旧银行或用--target-bank换个新 ID 导入。现象恢复演练把生产数据清掉了。原因restore 会先清空目标 schema 的全部数据再导入这是设计行为。处理演练前先打一份新备份且演练在专用 schema 或测试实例上进行别在生产库上试。实战场景把整个记忆银行搬到新嵌入模型假设你想把 384 维的嵌入模型换成 1024 维的而库里已经攒了几十万条事实。原地改不了——向量维度与 schema 绑定旧向量无法拉伸。推荐路径是蓝绿迁移起一个新实例配上新嵌入模型维护窗口内先打一份安全备份然后在源实例执行hindsight-admin export-bank --bank my-bank --output my-bank.zip只读可在线跑在目标实例执行hindsight-admin import-bank --archive my-bank.zip。导出永远不含嵌入向量目标实例用自己的模型重新嵌入并重建索引事实、文档、心智模型和配置则原样还原全程不需要 LLM 重新抽取。导入后跑几条有代表性的检索查询核对质量确认无误再切流量老实例留作随时可回滚的退路。备份一条命令、恢复一条命令、跨实例迁移一对 export/importHindsight 的记忆备份链路到这里就闭环了。完整参数清单和迁移 runbook 见 admin-cli.md备份恢复逻辑的测试用例在 test_admin_backup_restore.py。【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsight创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表