Hindsight 由 Vectorize.io 团队开源,目前在 GitHub 上已获得超过 10,500 个 Star,采用 MIT 协议。它的核心理念只有一句话:让 Agent 学习,而不仅仅是记住。Hindsight 的设计灵感来自人类记忆系统。它将 Agent 的记忆分为三个层次:
- World(世界知识)——关于世界的客观事实。就像你知道"火是热的",这类记忆是静态的、可共享的。在 Agent 场景下,它存储项目的技术栈信息、团队的开发规范等事实性知识。
- Experiences(经历)——Agent 自身的交互经历。类比于"我被烫过",这类记忆是个人化的、带时间戳的。它记录 Agent 在特定场景下的行为和结果,比如"用户偏好用 TypeScript 而非 JavaScript 编写工具函数"。
- Mental Models(心智模型)——通过反思形成的深层认知。这相当于"我知道不该碰热的东西"。它不是原始记忆的简单堆叠,而是跨越多次经历的抽象和合成。
Hindsight 提供三种部署模式,适配不同的使用场景和技术要求。
- Cloud 模式:连接 Hindsight Cloud API。这是最简单的方案,只需一个 API Key 即可使用。适合快速验证和个人项目。数据存储在 Hindsight 的云端,无需本地部署任何额外服务。
- Local Embedded 模式:本地嵌入式部署。这是性价比最高的方案。Hermes 会自动启动一个本地 Hindsight 守护进程,内置 PostgreSQL 数据库,零额外配置。你只需要一个 LLM API Key(用于实体提取和反思),不需要安装 Docker 或配置数据库。
- Local External 模式:Docker 或自托管部署。适用于企业级场景。你可以独立部署和管理 Hindsight 实例,通过 HTTP 连接。这提供了完全的数据控制权,适合对数据隐私有严格要求的场景。
本文仅介绍Local Embedded 模式下的部署方案。
Local Embedded 模式
如果你不想把数据发送到云端,Local Embedded 模式是最佳选择。
bash
# 安装时包含 Hindsight 本地依赖
pip install hermes-agent[hindsight]
# 启动配置向导
hermes memory setup
# 选择 "Hindsight" → "Local Embedded"
# 配置 LLM Provider(用于实体提取)Hermes 会自动在本地启动 Hindsight 守护进程(内置 PostgreSQL),无需手动安装任何数据库。
yaml
# 配置文件通常位于 ~/.hermes/memory_providers/hindsight.yaml
provider: hindsight
mode: local_embedded
# LLM Provider 配置(用于实体提取和反思)
llm:
provider: openai # 支持 openai / anthropic / ollama 等
model: gpt-4o-mini # 推荐:性价比高,速度快
api_key: ${OPENAI_API_KEY}
# 记忆检索配置
recall:
budget: mid # low / mid / high
prefetch_method: recall # recall(原始事实)或 reflect(LLM 合成)
max_tokens: 4096
# 记忆写入配置
retain:
every_n_turns: 1 # 每隔 N 轮对话自动 retain 一次
# 记忆模式
memory_mode: hybrid # hybrid / context / tools查看守护进程状态和日志:
bash
# 检查守护进程状态
hermes memory status
# 查看实时日志
hermes memory logs --follow
# 打开 Hindsight Web UI 查看记忆状态(如果可用)
hermes memory ui最佳实践与调优建议
配置完成后,以下调优技巧能帮你获得更好的效果。
memory_mode 选择策略:
yaml
# 三种记忆模式的配置代码
# hybrid(默认推荐):自动注入 + 工具可用
# Agent 既能在上下文中看到预取的记忆,
# 也能主动调用 hindsight_recall/reflector 工具
memory_mode: hybrid
# context:仅自动注入,不暴露工具
# 适合简单场景,减少 token 消耗
# Agent 只能看到 prefetch 注入的记忆
memory_mode: context
# tools:仅工具,无自动注入
# 适合需要精细控制记忆访问的场景
# Agent 必须主动调用工具才能获取记忆
memory_mode: tools
recall_prefetch_method 的场景选择:
recall:返回原始事实和经历,适合需要精确信息的场景
reflect:返回 LLM 合成的洞察,适合需要综合判断的场景
一般建议使用 recall,仅在需要高层总结时切换到 reflect。
bank_id_template 多场景配置:
bank_id_template 是实现记忆隔离的关键配置。它支持 profile、workspace、platform、user、session 五个模板变量:
# 场景 1:个人使用,所有记忆共享
bank_id_template: "my-agent"
# 场景 2:多用户隔离(客服场景)
bank_id_template: "user-{user}"
# user-alice 和 user-bob 的记忆完全隔离
# 场景 3:多工作区隔离(项目管理)
bank_id_template: "{workspace}"
# workspace-project-a 和 workspace-project-b 独立记忆
# 场景 4:按平台 + 用户隔离
bank_id_template: "{platform}-{user}"
# TG-alice 和 discord-alice 可以有不同记忆
# 场景 5:会话级隔离(临时记忆)
bank_id_template: "{platform}-{user}-{session}"
# 每个会话独立记忆,适合一次性任务场景
retain_every_n_turns 的权衡:
# 每轮都 retain(默认):记忆最完整,但 API 调用更频繁
retain_every_n_turns: 1
# 每 3 轮 retain:减少 API 开销,可能遗漏部分信息
retain_every_n_turns: 3
# 每 5 轮 retain:适合高频但低信息密度的对话
retain_every_n_turns: 5对于开发场景,建议保持 1(每轮 retain)。对于闲聊场景,3 或 5 就够了。
评论
0评论加载中…