Hindsight 0.9.1 版本解析更快的 Recall、xAI OAuth 接入与可移植 Bank 迁移【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsightHindsight 0.9.1 是继 0.9.0 之后的又一个重要迭代聚焦于“让 0.9.0 的能力更稳、接入面更宽”Recall 热路径显著提速、新增 xAI OAuth 订阅接入、Bank 迁移可携带 Knowledge Pages、Reflect 具备真实时间感知并完成了一轮覆盖数据完整性与后台任务稳定性的可靠性修复。读完本文你将掌握 0.9.1 各核心变更的配置方式、环境变量与底层实现依据并了解为何官方建议自托管部署尽快升级。本文以官方发布说明 hindsight-docs/blog/2026-08-14-version-0-9-1.md 为主体并结合仓库内hindsight-api-slim/hindsight_api的源码与测试进行纵深佐证。文中引用的配置项、环境变量、默认值均以当前仓库实际内容为准。一、总览0.9.1 的五大主线0.9.1 在 0.9.0 的基础上主要完成五件事主线核心内容受益场景More Model Control更强的模型控制xAI OAuth 订阅接入、LiteLLM 强制工具结构化输出、负载均衡后端恢复提示词缓存、Ollama thinking 可配置接入更多模型后端降低推理成本Portable Transfers可移植迁移异步文档导出、Bank 迁移携带 Knowledge Pages、全部配置字段可导出导入、按 Bank 设定存储能力实例间迁移数据更完整A Sharper Reflect更锐利的反思当前时间感知、子召回解析实体名、综合阶段不再丢弃证据反思质量提升Faster Recall更快的召回时间抽取约快 9 倍、集合级打分、去重实体查询Agent 每轮都命中的热路径Operate with Confidence安心运维无数据库依赖的存活探针、严格的按 Bank 作用域、大批可靠性修复生产环境稳定性官方明确指出自托管部署应升级Self-managed deployments should upgrade——多项修复保护数据完整性并防止后台任务停滞。二、更强的模型控制More Model Control2.1 新增 xAI OAuth 提供商0.9.1 新增了xai-oauth这一 LLM 提供商让你可以用 SuperGrok 订阅免 API Key、固定费率驱动 Hindsight 的 LLM 通道通过 OAuth 而非原始 API Key 认证。开启方式export HINDSIGHT_API_LLM_PROVIDERxai-oauth从源码看该能力由三部分构成xai_oauth_auth.pyOAuth 凭据管理器负责通过RFC 8628 设备码流程device-code flow从 xAI 的 OIDC issuerhttps://auth.x.ai获取用户授权的授权码并用grant_typerefresh_token持续续期xai_oauth_llm.py订阅通道的请求侧实现oauth_store_lock.py凭据存储的跨进程锁。登录方式登录是显式的交互式入口请求路径上永远不会触发登录流程。在拥有令牌存储的主机上执行python -m hindsight_api.engine.providers.xai_oauth_auth login登录流程会打印验证 URL 与用户码等待你在浏览器中授权后将凭据写入令牌存储文件默认~/.hindsight/xai_oauth.json随后轮询令牌端点直至授权落地。相关环境变量均声明于 config.py环境变量默认值说明HINDSIGHT_API_XAI_OAUTH_TOKEN_PATH~/.hindsight/xai_oauth.json令牌存储路径读写均跟随该路径HINDSIGHT_API_XAI_OAUTH_CLIENT_ID公开客户端 ID来自 xAI 官方 Grok CLI 源码非机密OAuth 客户端标识HINDSIGHT_API_XAI_OAUTH_SCOPEopenid profile email offline_access grok-cli:access api:access授权范围HINDSIGHT_API_XAI_OAUTH_REFRESH_SKEW_SECONDS60.0在expires_at之前多少秒触发刷新HINDSIGHT_API_XAI_OAUTH_REFRESH_TIMEOUT_SECONDS20.0每个 HTTP 调用的超时HINDSIGHT_API_XAI_OAUTH_BASE_URLhttps://api.x.ai/v1API 基础地址HINDSIGHT_API_XAI_OAUTH_DEBUG_HEADERSfalse是否输出调试请求头几个值得注意的源码级安全设计来自 xai_oauth_auth.py令牌永不进日志令牌值、刷新令牌、用户码、Authorization 头在任何日志级别都不会被打印日志只携带字节数、过期时间戳、scope 名与状态码端点域名锁定OIDC discovery 返回的token_endpoint与device_authorization_endpoint必须为 HTTPS 且位于x.ai或*.x.ai子域防止端点替换导致凭据泄漏写入原子性凭据先写入同目录临时文件并fsync再os.replace原子替换0600权限读者永远不会观察到半写入状态多实例共享一个凭据xAI 每次刷新都会轮换 refresh token因此刷新状态存放在存储中而非内存多个 provider 实例每个配置的 lane 一个共享同一凭据通过fcntl.flock咨询锁串行化刷新防旋转间隔凭据获得后 30 秒内不重复刷新DEFAULT_MIN_REFRESH_GAP_SECONDS 30.0刷新失败按 400/401 判定为终端状态并隔离凭据要求重新登录。2.2 LiteLLM 强制工具结构化输出部分经 LiteLLM 路由的后端例如某些区域的 Bedrock会拒绝response_format这条结构化输出路径。0.9.1 允许你为这类后端强制改用“工具调用”方式获得结构化结果export HINDSIGHT_API_LLM_STRUCTURED_OUTPUT_FORCED_TOOLtrue对应实现位于 litellm_llm.py该开关默认关闭见 config.py。开启后当调用携带 Pydantic 响应模型且后端不支持response_format时请求改为通过工具参数携带 JSON Schema_forced_tool_arguments从而在 response-format schema 不可用的后端上也能完成结构化抽取。相关测试见 test_litellm_forced_tool_structured_output.py。2.3 负载均衡后端恢复提示词缓存服务端提示词缓存prompt caching现在可以在负载均衡的 OpenAI 兼容后端上再次生效对重复前缀请求显著降低延迟与成本。此前负载均衡会破坏缓存命中0.9.1 修复了这一路径。2.4 可配置的 Ollama thinkingOllama 的原生think行为现在通过extra_body控制你可以按模型与部署方式决定开启或关闭推理# 示例向 Ollama 请求体注入 think 控制参数 export HINDSIGHT_API_LLM_OLLAMA_NUM_CTX4096HINDSIGHT_API_LLM_OLLAMA_NUM_CTX为上下文窗口相关配置think本体通过extra_body透传相关测试见 test_ollama_native_think.py。2.5 更广的提供商兼容性推理强度显式下发只要你在配置中设置了 reasoning effort它就会被显式发送给模型模型不再静默回退到自身默认值。相关环境变量包括HINDSIGHT_API_LLM_REASONING_EFFORT、HINDSIGHT_API_RETAIN_LLM_REASONING_EFFORT、HINDSIGHT_API_REFLECT_LLM_REASONING_EFFORT、HINDSIGHT_API_CONSOLIDATION_LLM_REASONING_EFFORT见 config.py使 retain、reflect、consolidation 各阶段可以分别设定推理强度extra_body透传修复Llama.cpp / OpenAI 兼容后端与 Codex 后端的extra_body透传已修复供应商特定选项能真正到达模型相关测试见 test_llm_extra_body.py 与 test_codex_extra_body.py内联think文本保真你作为内容发送的think文本将原样保留而不再被当作模型自身的推理内容剥离相关测试见 test_strip_reasoning_tags.py。三、可移植迁移Portable Transfers在实例之间迁移 Bank 这一场景在 0.9.1 中变得更完整。3.1 异步文档导出大文档导出不再作为单个阻塞请求运行此前可能长期占用 API而是改为异步操作你先发起导出任务在后台执行就绪后再下载。实现上transfer/export.py 中的export_documents等导出函数面向异步后端执行并会先排空源端在途的异步操作代码注释中async_operations即 in-flight ops迁移前需要 drain避免导出快照与在途写入不一致。3.2 迁移携带 Knowledge Pages整库whole-bank迁移现在包含 Knowledge Pages 树并且在导入时会重新生成心智模型mental-model的搜索状态——迁移过来的 Bank 带着完整的“wiki”并且立即可搜索而不只是原始记忆数据。相关证据迁移导入端 transfer/importer.py 直接引用 Knowledge Pages 相关逻辑迁移导出端 transfer/export.py 中存在_load_knowledge_pages按 bank 加载页面树与TransferKnowledgePage类型数据库层面有专门的迁移文件 a9b8c7d6e5f4_add_knowledge_pages.py 定义页面表结构API 与 MCP 工具层也暴露了页面读写能力见 api/http.py 与 mcp_tools.py。3.3 全部 Bank 配置字段可往返Bank 模板的导出/导入现在可以完整往返每一个配置字段——恢复出来的 Bank 与原始 Bank 配置完全一致不再有“恢复后要手工补配置”的遗漏。结合 0.9.1 对配置值做类型校验见第五节错误配置也无法在恢复时悄悄潜入。3.4 按 Bank 设定存储能力每个 Bank 背后的存储能力storage capabilities现在可以按 Bank 单独设置在同一引擎之下不同 Bank 可以启用不同的存储特性实现更细粒度的存储策略控制。四、更锐利的 ReflectA Sharper ReflectReflect 阶段在 0.9.1 中得到三项关键改进它知道现在几点Reflect 现在会收到当前日期与时间last week、recently 这类相对时间会对照真实时钟解析而不是停留在含糊语义上。这与 Recall 侧的时间抽取实现同源——temporal_extraction.py 的extract_temporal_constraint接受reference_date参数默认取当前时刻返回(start_date, end_date)时间窗口并同时存在同步与异步extract_temporal_constraint_async两个入口子召回解析实体名Reflect 内部执行的子召回sub-recalls现在会解析实体名称推理引用的将是真实、规范的实体名而不是不透明的 ID综合阶段不丢证据当 Reflect 被迫进入 synthesis综合模式时不再丢弃已检索到的证据——它会拆分工作确保每条检索到的事实都能进入最终答案。相关实现见 reflect/ 目录测试覆盖见 test_reflect_split_synthesis.py 与 test_reflect_grounding_behaviour.py。五、更快的 RecallFaster RecallRecall 是 Hindsight 的热路径——Agent 每一轮对话都会命中它因此它的延迟被全链路感知。0.9.1 让 Recall 明显更快且不改变返回结果5.1 时间抽取约快 9 倍解析查询隐含的时间窗口last week、in 2023过去是每次 recall 的成本大头现在只占很小一部分。从 temporal_extraction.py 的代码注释可以看到相关演进痕迹该模块使用专用线程池ThreadPoolExecutor并行执行抽取并绕开 dateparser 的模块级单例后者会缓存状态且串行化每次调用——通过 16 并发抽取的测量来验证吞吐这正是 0.9.1 性能优化的落地实现之一。周边支撑还包括 temporal_periods.py 与 chinese_temporal_periods.py中英文时间周期解析以及专门的数据库时间索引迁移 b3c4d5e6f7g8_add_temporal_date_indexes.py。5.2 集合级打分Set-wise scoring观测扩展observation expansion现在一次性对整个候选集打分而不再逐行打分在大规模 recall 上削减了大量冗余计算。5.3 去除冗余实体查询当结果已经携带实体 ID 时recall 直接复用而不再重新拉取——每次查询的数据库往返更少。相关的 recall 质量与回归测试非常丰富可重点参考 test_recall_temporal_window.py、test_recall_time_range.py 与 test_recall_scoring_time.py。六、安心运维Operate with Confidence6.1 无数据库依赖的存活探针慢数据库不再触发 liveness 检查失败、进而重启本来健康的 Pod。Liveness 独立作答数据库事故就只是数据库事故而不会演变成“重启风暴”。源码依据非常清晰。liveness.py 的模块文档明确写道Liveness 只回答一个问题这个进程是否卡死到只能靠重启恢复它绝不能触碰数据库。跑SELECT 1的 liveness 探针会把数据库降级变成一次事故每个 Pod 同时探针失败、被中途杀死已认领的异步操作被以递增的retry_count重新入队把真实工作推向永久失败悬崖然后重新连接、对已经饱和的数据库再次加热连接池。设计要点探针永远不碰数据库API 侧返回status: alive、version、uptime_seconds三个字段Worker 侧额外携带worker_id、is_shutdown、seconds_since_last_poll依赖检查归入就绪探针readiness/health、/health/ready就绪失败会把 Pod 从 Service 摘除而不是杀死它降级就保持为降级单事件循环假设Hindsight 的请求处理器与任务工作运行在同一个事件循环上只要循环被同步调用阻塞连最简单的请求都无法在探针超时内应答见 loop_watchdog.py。因此能应答 liveness 本身就证明了一件事事件循环仍在调度协程——这正是重启唯一能修复的条件Worker 探针保持 200 不回退seconds_since_last_poll仅用于告警上报即使轮询已陈旧端点依然返回 200饱和的数据库永远不会触发重启。6.2 严格的按 Bank 作用域文档更新与删除操作现在按 Bank 限定作用域封堵了一条操作可能触碰其他 Bank 记忆单元memory units的路径。6.3 大规模可靠性修复0.9.1 还携带一轮大规模可靠性与性能修复逐条与仓库对应修复内容仓库佐证同一文档的并发 append 不再丢失轮次turns见 test_append_coalesces.py、test_append_body_invariants.pyretain 在跨独立存储写入时不再长时间持有数据库连接见 test_retain_store_owned_no_connection.pyretain 与 bank 删除中的多个死锁被消除见 test_bank_lifecycle_deadlock_retry.py、test_retain_entity_prune_race.py极端相对日期偏移不再让 recall 崩溃见 test_recall_time_range.py图维护更快更稳陈旧共现剪枝与 chunk 删除的链接匹配从数十秒降到毫秒级见 graph_maintenance.py实体剪枝改为队列驱动不再整库扫描见 test_graph_maintenance_queue_race.pyBank 配置值做类型校验坏值无法卡死后台任务见 test_bank_config_value_types.pyconsolidation、recall、Knowledge Pages 各自修正正确性问题见 test_consolidation_batch_atomicity.py 等七、升级建议与延伸阅读官方对 0.9.1 的升级态度非常明确自托管部署应尽快升级——多项修复直接保护数据完整性如并发 append 不丢轮次、按 Bank 作用域、配置类型校验并阻止后台任务停滞如死锁修复、队列驱动的实体剪枝。如需继续深入完整变更清单见仓库 changelog 相关页面全部环境变量的声明与默认值集中在 config.py0.9.1 各项能力均有对应测试可复现验证测试目录见 hindsight-api-slim/tests若需要搭建/升级运行环境可参考 docker/docker-compose 下的各部署编排示例与 helm/hindsight 的 Helm Chart其中包含了 liveness/readiness 探针的部署配置方式。总而言之0.9.1 是一次“既有性能冲刺、又有架构硬化”的版本Recall 的加速让 Agent 的每一轮对话更轻快xAI OAuth 打开了订阅制接入的新路径迁移能力的补全让 Bank 真正“可搬运”而无数据库依赖的 liveness 探针则让生产环境的故障边界更加清晰。【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsight创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考