你有没有过这种经历几个月前在网上看过一篇特别好的长文当时随手关了现在想找翻遍浏览器历史也只看到一行 URL标题没记住内容更是早就消失。我就是在反复吃这种“就差一步”的亏之后才认真折腾起hindsight这个开源项目。hindsight 名字直译是“后见之明”它做的事也很直白把你浏览过的页面内容原样存在自己的电脑里支持全文搜索相当于给浏览器历史装上了记忆。它由 Google 开源核心是“本地服务器 浏览器扩展”的组合数据不出本机。这篇文章面向三类人觉得浏览器自带历史完全不够用的普通用户、喜欢自托管数据的技术党以及正在玩 Dify、想把本地数据喂给大模型的人。hindsight 最打动我的地方不是技术有多炫而是它把“我的数据到底归谁”这个老问题给出了一个很干净的答案归我自己。1. 从“浏览器历史”到“个人记忆库”hindsight 解决了什么问题1.1 浏览器自带历史为什么总让人抓狂你回想一下浏览器历史记录里存了什么一个 URL、一个标题、一个访问时间。就这些。当你只记得“我好像看过一篇讲分布式存储的文章”时Chrome 的地址栏搜索给不了任何帮助因为你连标题都记不全。更要命的是网页是活的东西。你今天看到的文章可能三个月后作者就删了、改了、或者整站下线了。就算你记得 URL点回去也是一片空白。哪怕是各种“稍后读”工具也要求你主动收藏、主动整理大部分时候我根本没有那个闲心——等我意识到这篇文重要已经是几个月后了。云端同步是另一个隐忧。默认情况下浏览器历史会跟着账号走这行 URL 被传到了服务商的服务器上。对很多人来说这无所谓但对“数据尽量留在本地”的人来讲这种被动暴露并不舒服。hindsight 的思路完全反过来它不把历史当数据而把页面正文当资产并且这套资产直接落盘在你自己机器上。1.2 hindsight 的架构设计与“后见之明”这名字hindsight 由两部分组成hindsight-server一个本地运行的 Web 服务负责接收数据、存储、提供管理界面和搜索接口。hindsight-chrome一个浏览器扩展在你访问网页时“顺手”把页面正文抓下来发给本地服务。两部分都跑在你自己的机器上服务器默认只监听本机回环地址也就是127.0.0.1。这就意味着就算你连着公共 Wi-Fi浏览器历史的正文内容也不会经过别人的服务器。至于名字“hindsight”说的是“事后回头看”。我们浏览网页的当下以为记住了其实没有。事后想回头却只有一条光秃秃的链接。这个工具就是给你一双后眼让你能在需要时翻回某个时间点把当时的页面内容原样捞出来。它能找到的不是“我访问过什么”而是“我当时看到了什么”。1.3 和“稍后读”工具、浏览器同步的直观对比维度浏览器自带历史Pocket 一类的稍后读hindsight保存内容仅 URL/标题/时间手动保存的文章快照自动抓取访问过的页面正文主动操作不需要需要不需要搜索范围标题/URL已保存文本全文搜索数据位置云端同步云端本地存储离线可用部分部分完全离线一句话总结hindsight 补的正是浏览器历史最缺的那块拼图——内容本身。2. 本地部署实战从头把 hindsight 跑起来2.1 我推荐的部署方式先跑二进制再考虑 Docker官方 release 页面提供了各平台的预编译二进制解压就能跑。我的习惯是先把这版跑通再研究怎么容器化。直接下载包之后解压结构大致是hindsight-server可执行文件加一个前端静态资源目录。启动方式很简单在终端里执行# Linux / macOS ./hindsight-server # Windows hindsight-server.exe第一次启动会在用户目录下创建数据目录比如~/.hindsight里面放数据库、配置和日志。启动日志会提示服务监听在哪个端口默认是5170。看到类似listening on 127.0.0.1:5170的输出后浏览器打开http://127.0.0.1:5170就能看到 Web 管理界面这时候范围内还没有任何数据所以列表是空的。如果你偏好 Docker社区也有现成镜像核心参数大致是这样的mkdir -p ~/.hindsight docker run -d --name hindsight \ -p 5170:5170 \ -v ~/.hindsight:/root/.hindsight \ your-registry/hindsight-server:latest容器方式的注意点是数据卷权限——容器内写文件用的是 root 还是普通用户取决于镜像怎么写同步目录后如果宿主机上看不到文件先看看是不是权限问题。2.2 安装浏览器扩展开发者模式加载hindsight 的浏览器扩展不一定在所有商店上架至少我装的这个环境里是直接拉源码通过开发者模式加载的。具体步骤下载 hindsight-chrome 源码到本地解压。打开chrome://extensions/。打开右上角“开发者模式”开关。点击“加载已解压的扩展程序”选中刚解压的目录。扩展图标出现后点击它把服务器地址填成http://127.0.0.1:5170。这里有个容易踩的坑服务器地址一定要写127.0.0.1而不是localhost。某些系统上localhost被解析成了::1IPv6而 hindsight-server 默认只监听了 IPv4 的127.0.0.1两者对不上扩展会一直报“无法连接服务器”。我第一次就是被这个细节卡了半天。2.3 首次握手验证装好扩展后随便打开一个稍长一点的网页——比如一篇新闻文章或者技术博客停留十几秒。然后回到127.0.0.1:5170的管理界面刷新一下应该能看到刚才那条记录里面包含标题、URL、访问时间和正文预览。如果你的浏览器本来就有很多历史记录不需要担心hindsight 不回溯旧历史它只记录你装好之后访问的内容。从这一刻开始它才开始积累你的本地浏览档案。3. 真正用起来之后采集逻辑、搜索体验与数据形态3.1 它到底采集了什么很多人的第一反应是“这不就是个监控工具吗”实际理解有偏差。hindsight 的扩展工作在你的浏览器里它采集的是当前标签页加载完成的页面而且是你在正常浏览操作中触发访问的页面。它不做流量劫持也不记录你在地址栏输入但没打开的内容。采集的核心字段大致有四类页面标题完整 URL访问时间戳页面正文内容正文不是纯 HTML而是经过提取后的可读文本。这样管理界面里展示、搜索、备份都方便。需要注意的是有些页面抓不到或者抓不全需要登录的会员后台、纯 JS 渲染且内容异步加载的应用、以及一些做了很强反爬限制的站点存下来的可能只有一个标题和框架。还有一类页面建议直接忽略网银、支付、私密邮箱。hindsight 的配置里可以设置忽略规则按域名或者 URL 前缀匹配。我强烈建议每个人装完第一件事就是把这些敏感站点加进去而不是等数据堆起来再处理原因后面会详细说。3.2 全文搜索是它的灵魂hindsight 最有价值的功能是全文本地搜索。装好它之后我真正体验到了“遗忘也能被检索”的快感。比如上周我想找一篇关于“向量数据库”的文章只记得大概三个月前看过标题完全想不起来。在 search 框输入“向量数据库 检索”几毫秒就能列出所有正文里包含这几个词的历史页面再按时间排序精准定位。不过搜索体验在中文上有个小坑。底层全文索引用的是 SQLite 的 FTS默认分词对英文很友好对中文就不是那么聪明。如果你搜“知识的整理”没搜到试着输入原文里很可能出现的连续关键词比如“知识管理”“整理方法”。实测下来用完整短语比拆开几个词再拼一起命中率高得多。这种搜索能力和浏览器地址栏的“历史搜索”完全不是一个层级。地址栏搜的是 URL 和标题机会成本很高hindsight 搜的是正文相当于给所有看过的内容都建立了索引。3.3 数据到底长什么样怎么备份迁移数据默认放在~/.hindsight下主体是一个 SQLite 数据库周围是配置和日志文件。数据库里存着内容记录和索引。我的习惯是每天睡前同步一次整个目录到 NAS或者干脆让它跟着电脑备份工具走。恢复也简单把~/.hindsight整个目录拷回新机器重新启动 server 就完事无需额外导入导出。数据格式是本地二进制不依赖云服务迁移成本极低。唯一要注意的是如果数据库文件正在被 server 占用复制前最好先停掉服务或者用热备方式处理避免拷到一半的文件损坏。4. 把 hindsight 喂给 Dify让 AI 真正“读过”你的浏览史4.1 为什么“hindsight dify”这个组合突然火最近在 Dify 社区经常看到有人同时聊这两个词一开始我以为是巧合琢磨了一下发现逻辑很顺hindsight 负责“沉淀数据”Dify 负责“编排应用”。一边源源不断把浏览器历史变成本地数据库一边用大模型对这批数据做问答、摘要、抽取。两者拼在一起就是一个纯本地、可控的“个人记忆 AI”。Dify 是开源 LLM 应用开发平台支持知识库、Agent、工作流。它本身不产生数据需要你喂给它。问题在于绝大多数人的知识库内容都是手动上传的文档今天传几篇 PDF明天贴几篇网文维护成本高。hindsight 恰好补上了这个缺口你的浏览历史会自动变成知识素材而且一直在更新。4.2 方案一定期导库灌成 Dify 知识库这个方案最简单适合不追求实时性的人。思路是写个脚本周期性地把 hindsight 数据库里新增的历史记录导出成 Markdown 或 JSON 文件然后在 Dify 里建一个“浏览历史”知识库把这些文件上传让 Dify 做分段和向量化。我的导出脚本核心逻辑是这样的import sqlite3 import json from pathlib import Path db_path Path.home() / .hindsight / hindsight.db conn sqlite3.connect(db_path) rows conn.execute( SELECT title, url, visited_at, content FROM pages WHERE visited_at ? ORDER BY visited_at DESC , (last_export_time,)).fetchall() for title, url, visited_at, content in rows: if not content: continue # 拼成 markdown 文档按日期归档 doc f# {title}\n\n- 来源{url}\n- 时间{visited_at}\n\n{content[:3000]}\n out Path(exports) / f{visited_at}_{hash(title) 0xffffffff}.md out.write_text(doc, encodingutf-8)注意不同版本的 hindsight 数据库表名和字段名可能有差异我第一次跑脚本就踩了表名不对的坑。建议先执行一句sqlite3 ~/.hindsight/hindsight.db .tables看看实际表结构再调整脚本。导出文件在 Dify 里导入时分段模式选“自定义”尽量按条目切而不是按固定字数切。不然一篇历史记录可能会被拦腰截断影响后续检索召回。这个方法跑通之后你的知识库就是“自动生长的”每天新增浏览内容都会被吸收进去。4.3 方案二把 hindsight 变成 Dify 自定义工具如果你想要的是“实时问答”知识库上传路径就不够快了——新访问的内容可能要等下一次导出、上传、分段、向量化全部完成才能被问到。更痛快的做法是把 hindsight 数据库封装成一个搜索接口注册到 Dify 里面作为自定义工具让 Agent 在会话中按需调用。我先用 Flask 写了一个极简查询服务from flask import Flask, request, jsonify import sqlite3 from pathlib import Path app Flask(__name__) DB_PATH Path.home() / .hindsight / hindsight.db app.get(/search) def search(): q request.args.get(q, ).strip() if not q: return jsonify({error: missing query}), 400 conn sqlite3.connect(DB_PATH) rows conn.execute( SELECT title, url, visited_at, content FROM pages WHERE content LIKE ? ORDER BY visited_at DESC LIMIT 8, (f%{q}%,) ).fetchall() conn.close() results [ { title: r[0], url: r[1], visited_at: r[2], snippet: r[3][:300] if r[3] else , } for r in rows ] return jsonify(results) if __name__ __main__: app.run(host127.0.0.1, port8765)服务起在127.0.0.1:8765后在 Dify 里添加自定义工具填 OpenAPI schema。schema 大致长这样openapi: 3.0.0 info: title: Hindsight Search API version: 1.0.0 paths: /search: get: operationId: search_history summary: 搜索本地浏览历史内容 parameters: - name: q in: query required: true description: 搜索关键词 schema: type: string responses: 200: description: 返回匹配的历史记录列表然后在 Agent 应用里勾上这个工具给它一句提示词“当用户询问是否看过某个主题的文章时调用 search_history 工具查询本地浏览历史再基于查询结果整理回答。”实际效果我很满意。问一句“我上个月是不是看过一篇讲 RAG 评估的文章”Agent 会先调接口搜出相关记录再根据 snippet 做总结。这个方案的最大优势是零延迟新鲜度——刚看完的页面一分钟之后就能被 AI 引用。4.4 方案三工作流驱动让 AI 自动消化当天浏览记录更进一步可以在 Dify 里建一个定时工作流如果接入了 cron 触发器每天定时从 hindsight 拉取前 24 小时的新增历史让大模型生成一份“今日知识摘要”推送到企业微信、飞书或者邮件。本质上这是把“被动搜索”升级成“主动提醒”。我的做法是一个 Python 脚本每天凌晨把SELECT title, url, content FROM pages WHERE visited_at now - interval 1 day导成 JSON丢进 Dify 工作流的输入节点工作流里用 LLM 节点做主题聚类、提取 5 个最有价值的链接最后输出摘要。长期坚持下来你会发现自己每周自动积累了一份个人知识周报完全不用手工整理。5. 实测中的坑与我的处理方式5.1 数据库增长与检索性能hindsight 攒的是纯文本大部分人正常浏览一年下来数据库也就是几百 MB 量级还不至于让现代电脑卡顿。但随着条目变多全文检索速度会下降尤其是没有做时间过滤的全库查询。我的缓解办法是两个一是控制抓取范围在配置里把一些纯粹资讯流、广告重灾区网站加入忽略列表降低无用内容入库二是写个定时清理脚本把超过 180 天且从未被手动标记收藏的旧记录归档到一个备份库中主库只保留最近半年数据。归档前先确认历史里没有你想长期保存的东西否则删了不好找回。5.2 隐私边界它不是监控软件但你要管好数据出口hindsight 的设计前提是“记录你自己主动访问的页面”不是“监听别人上网行为”。它没有隐身式抓包能力也不适合拿去监控别人电脑。想拿它做这类用途既违背工具初衷也大概率达不到效果。真正要小心的是当你把 hindsight 的数据接给 Dify 之后隐私边界就发生了变化。Dify 里的 LLM 应用如果配置的是在线模型 API你本地浏览记录里的敏感内容会被发送到模型服务商的服务器。虽然很多是明文传输隐私条款也不会为你开例外。所以我在集成时做了两个防护在 hindsight 的忽略规则里明确过滤网银、医疗、私人社交、支付页面等域名。这类页面流入历史数据库越少被 AI 读到或外发的概率就越低。在 Dify 工具配置里限定返回 snippet 的长度和字段。搜索接口只返回标题和片段不让 Agent 一次拿到整篇正文全文需要长文时再让用户主动去管理界面打开原页。这套“分割存储、按需取用”的边界能最大限度降低把隐私喂给 AI 的风险。个人数据这件事默认假设“可能被泄露”然后反向设计使用流程是最稳妥的。5.3 我记下来的几个具体问题这里把我在部署和使用过程中真真切切踩过的坑列一下方便你避开端口冲突5170 不是特殊端口容易被别的服务占掉。启动时如果看到 bind 失败改配置里的监听端口即可但扩展里的 server 地址也要同步改忘了就出现“连接失败”。扩展掉线Chromium 内核浏览器偶尔在升级后禁用开发模式下加载的扩展。解决方法是重新打开开发者模式再“加载已解压的扩展程序”一次。无痕模式默认不采集如果经常开无痕窗口浏览那些访问不会进 hindsight。设计上这不是 bug是隐私优先的选择。页面动态加载导致抓不全一些前端框架渲染的页面扩展抓到的正文可能只有首屏。遇到这种情况可以在页面停留久一点或者尝试无痕以外的普通模式抓取效果会好一些。Docker 和宿主机目录不同步如果你用容器方式切记确认挂载目录权限。容器内写入的文件被默认用户才能读写宿主机普通用户可能看不到反过来容器也读不了宿主机刚生成的文件。解决方法是给容器指定用户或调整目录权限位。5.4 我目前的工作流长什么样最后分享一下我现在的状态其实很朴素日常浏览器照常用hindsight 在后台默默记录。每隔几天我会到管理界面随便搜几个关键词复习最近看过的内容顺手把值得留下的记录导出到个人文档库。Dify 那边跑着一个 Agent 应用主要回答“我是不是看过XX”“那篇关于XX的文章关键观点是什么”这类问题数据源就是本地历史和导出文件。整套体系已经稳定跑了半年多服务占用内存不到 100 MB几乎没有存在感。玩了大半年我最喜欢的一个场景是早上通勤路上对着接好 Dify 的本地历史问一句“我这周看过哪些关于个人知识管理的文章”AI 能列出清单并附摘要。这让我觉得 hindsight 这个名字起得真好——它让我在对的时间找回了差点被遗忘的信息。如果你也打算搭一套建议从二进制版把采集跑通忍住直接上高级集成的冲动等基本的搜索、备份、忽略规则都顺手了再去折腾 Dify 工具。毕竟工具的价值是用出来的不是装出来的。
