不想再靠回忆补上下文：Screenpipe 怎样把本机屏幕记录变成可检索、可限权的 Agent 记忆
AI 编程助手最容易丢失的，往往不是仓库里的代码，而是仓库之外的工作上下文：浏览器里刚读过的接口文档、会议中确认的取舍、终端里出现过但没有复制到 issue 的报错，以及某个任务为何被搁置。把这些内容重新讲给 Agent 听，不仅耗时，也容易遗漏关键约束。
Screenpipe 的思路是把个人电脑上的屏幕活动和音频处理成一份本地、可搜索的工作记忆：它优先读取操作系统提供的 accessibility tree（可访问性树）提取结构化文本；不可用时才回退到 OCR；音频可以用本地 Whisper 或云端 Deepgram 转写。索引、截图和音频默认落在本机，随后可由本地 REST API、MCP 或名为 Pipes 的自动化任务消费。
这不是“把屏幕录像喂给模型”。更准确地说，它是在桌面端建立一个事件驱动的数据采集与检索层。对于经常在 IDE、浏览器、终端、会议软件之间切换的开发者，这种分层比每次新会话都粘贴一大段背景更可控；但它也会带来极高的数据敏感度，必须先设计采集边界，再接入 Agent。
为什么不是持续录像
持续录屏的问题不只是磁盘占用。相同画面会产生大量重复帧，后续 OCR、索引与检索也会把噪声带进上下文。Screenpipe 的 README 描述了一条事件驱动路径：监听应用切换、点击、输入停顿和滚动等事件，在出现有意义变化时同时保存截图和 accessibility tree；远程桌面、游戏或部分 Linux 应用拿不到可访问性数据时，再使用 OCR。
这带来两个工程收益。第一，UI 中的按钮、标签、输入框等结构化文本通常比 OCR 更适合搜索，也减少了图片文字识别的误差。第二，采集频率与真实工作节奏关联，而不是固定按秒写入。项目给出的典型资源指标是 5–10% CPU、0.5–3 GB 内存、约 20 GB/月存储；README 另一处提到事件驱动截图约为 300 MB/8 小时，而连续录制约为 2 GB。它们应当视为项目方的估算，实际值会随显示器数量、分辨率、音频和应用类型变化。
存储侧使用本地 SQLite，并启用 FTS5 全文搜索；截图作为 JPEG 文件保存。这个组合很适合先把“何时、在哪个应用、出现过什么文本”查出来，再让 Agent 根据少量命中的时间片段回答问题，而不是把一天的原始记录塞进模型上下文窗口。
从本地搜索到 Agent 上下文
官方 README 给出的 CLI 起点是先启动记录，再执行初始化：
npx screenpipe record npx screenpipe setup
如果希望 Claude Code 通过 MCP 查询本机记录，README 给出的注册命令如下：
claude mcp add screenpipe -- npx -y screenpipe-mcp@latest
接入后，适合让 Agent 做的是范围明确的回溯，例如“过去五分钟我看到了什么”“今天讨论过哪些发布阻塞项”，而不是要求它无差别读取全天屏幕历史。Screenpipe 本地 API 默认监听在 localhost:3030。例如，先用关键词取得最近的会议线索：
curl 'http://localhost:3030/search?q=meeting+notes&content_type=all&limit=10'
也可只检索音频转写：
curl 'http://localhost:3030/search?q=budget+discussion&content_type=audio&limit=10'
在自动化程序里，项目的 JavaScript SDK 示例使用 @screenpipe/js 的 pipe.queryScreenpipe。关键不是调用本身，而是应当把 q、时间范围、结果上限固定在任务所需的最小集合：例如日报只查最近 24 小时和指定项目关键词；排错助手只查当前 IDE 或终端窗口对应的时间段。检索范围越窄，误带入私人内容和无关上下文的风险越小。
Pipes：把“记录”转换成可审计的自动化
Screenpipe 将自动化任务称为 Pipes。一个 Pipe 是位于 ~/.screenpipe/pipes/ 的 Markdown 文件，可包含提示词和调度信息；项目内置的例子包括会议摘要、日终回顾、站会更新、时间分布和 AI 提示词日志。它可以让 Agent 查询 Screenpipe API、调用外部 API、写文件或采取动作。
但 Pipes 不应被理解成“有提示词就安全”。真正值得关注的是它的 YAML 前置元数据能声明数据权限：允许或拒绝应用和窗口、限制 ocr、audio、input、accessibility 等内容类型、限制工作日和时段，并控制原始 SQL 或帧数据端点。README 还说明这些限制在技能暴露、Agent 拦截和服务端中间件三层执行，而非单靠提示词约束。
一个保守的工作日摘要任务可以采用类似下面的边界。字段名称来自项目文档，具体调度语法应以本机版本的 Pipe 文档为准：
--- deny-apps: "1Password,Slack" deny-windows: "*私人*" allow-content-types: "accessibility,ocr" time-range: "09:00-18:00" days: "Mon,Tue,Wed,Thu,Fri" allow-raw-sql: false allow-frames: false --- 总结今天在项目窗口中完成的工作、未解决问题和下一步；不要输出敏感内容。
这段配置的价值在于，即使摘要 Agent 的提示词被注入，也不应该因此获得被拒绝的应用、窗口、原始截图或 SQL 接口。对于开发团队，先在个人机器验证“允许什么”比先追求自动生成日报更重要。
隐私边界：本地默认不等于零外发
Screenpipe 的默认本地存储是重要优点，但“本地”不是“不会联网”的同义词。README 明确说明：产品分析默认通过 PostHog 启用，Sentry 可接收崩溃与错误诊断；若主动选择云端转写、托管 AI 或云同步，对应音频、提示词、选定上下文或同步数据会由所选服务处理。
因此部署前至少做四件事：
- 在设置中检查并按需关闭 Analytics；若目标是本地处理，选择本地转写与本地模型，并关闭云同步。
- 先用应用与窗口的 deny 规则排除密码管理器、私人通信、财务和生产凭据页面，而不是等采集后再清理。
- 默认禁止 Agent 使用原始帧和 raw SQL，只暴露经搜索过滤的文本结果；确有调试需求时再临时收窄授权。
- 把数据保留期、磁盘预算和备份策略写进团队约定。持续采集的数据量会增长，SQLite 索引和截图目录也应被当作敏感工作资料管理。
另外，项目当前并非 OSI 开源许可。其 README 将其称为 source-available，并写明个人非商业使用可审计、修改和运行源码，商业使用需要许可证；不要把它误称为完全开源软件。README 也提示主分支变动快，生产环境应查看 Release 并使用相应提交，而不是直接假设 main 稳定。
失败模式：不要把搜索结果直接当作事实
桌面活动是“发生过”的证据，不天然等于“仍然正确”的知识。比如浏览器标签页可能停留在旧版文档，终端输出可能来自已失败的实验，会议转写也可能有专有名词误识别。因此，Screenpipe 适合作为上下文发现器，而不应成为事实系统的唯一来源。
一个稳妥的 Agent 流程可以分成三步：先从本地检索中找出候选时间片段、文档地址和命令；再回到仓库、官方文档或当前环境做验证；最后才把经过验证的结论写入 issue、提交说明或日报。这样既能利用个人工作记忆减少“我在哪里看到过它”的检索时间，也不会把历史屏幕内容升级为未经核验的配置事实。
还要注意授权的传递边界。MCP 客户端、Pipe 和本地 API 都可能成为读取入口，不能因为 Screenpipe 只监听 localhost 就默认所有本机进程可信。应把能访问该 API 的自动化、浏览器扩展和 Agent 配置一并纳入审计；当任务只需要摘要时，优先输出脱敏结论与链接，而不是完整转写、截图或键盘输入记录。
何时值得使用，何时应避开
它适合需要跨应用、跨会话回溯上下文的个人开发者：例如把会议决定和浏览器文档线索找回、为 coding assistant 提供近期工作背景、从本地活动生成受限的日终摘要。它也适合先在单机范围内验证“自动化能否减少手工整理”。
反过来，如果电脑长期处理高敏感客户资料、团队无法明确数据边界、或没有能力审查本地保留与遥测配置，就不该为了方便而直接开启全天采集。Screenpipe 的正确打开方式不是“记录一切”，而是以最小采集面建立可搜索的个人工作记忆，再用 MCP 和权限化 Pipes 把其中一小部分、与当前任务相关的证据交给 Agent。
相关链接