Screenpipe Commitments Pipe 实战指南：从散落上下文到一份可收敛的承诺收件箱-北京尧图网络

Screenpipe Commitments Pipe 实战指南从散落上下文到一份可收敛的承诺收件箱【免费下载链接】screenpipeYC (S26) | Open Computer History | Record your screen continuously locally and provide context to your agents (Claude, Codex, Openclaw, Hermes, Runner...)项目地址: https://gitcode.com/GitHub_Trending/sc/screenpipe导读本篇文章围绕 Screenpipe 内置的Commitments Pipe位于 crates/screenpipe-core/assets/pipes/commitments/pipe.md展开讲解如何让 AI 定时扫描你在屏幕与麦克风上留下的工作上下文消息、会议、邮件、文档、工单把其中隐含的我答应过的事、别人让我做的事、正在等待的事统一收敛成一份活体承诺收件箱living commitments inbox。读完本文你将掌握该 Pipe 的调度与触发配置、structured_output交互协议、对账Reconciliation契约、交互式列表字段的填法以及它如何在 Live View 中以列表、指标和时间线形式呈现。一、Commitments Pipe 是什么一份活体承诺收件箱在 Screenpipe 这类持续本地录屏转录的工作流中大量承诺散落在各个应用里Slack 里一句我会发给你、会议中一句周五前给你答复、邮件里被分配的任务、Linear 上指派给你的工单。靠人肉记忆很容易漏而 Commitments Pipe 的设计目标非常聚焦——从用户最近的工作上下文中维护一份活体承诺收件箱也就是原文档开篇那句话Maintain one living commitments inbox from the users recent work context.从仓库中可以看到这条 Pipe 并不是孤立存在的它背后有一套完整的Pipe 结构化输出目标 Live View 模板三件套组件路径作用Pipe 提示词crates/screenpipe-core/assets/pipes/commitments/pipe.md定义 AI 每轮运行的行为契约结构化输出扩展crates/screenpipe-core/assets/extensions/structured-output.ts提供get_targets/submit工具Live View Kit 模板crates/screenpipe-engine/schemas/kits/commitments.live-view-kit.v1.json定义收件箱的 UI 呈现方式其中 Live View Kit 模板对这条 Pipe 的定位写得更直白One living inbox for promises, requests, waiting, corrections, and follow-through.一个汇聚承诺、请求、等待、更正与跟进事项的活体收件箱。它与仓库里另一条 accounting-follow-through财务跟进队列属于同类设计模式都是异常检测 / 跟进队列而非自动化改写外部系统。二、前置条件先读 Screenpipe Skill再调用structured_output原文档开篇给出了一条非常具体的执行顺序约束Read the screenpipe skill first. Then callstructured_outputwithget_targetsbefore searching.这意味着每一轮 Pipe 运行都必须遵循固定的三阶段顺序先读 skillAI 需要先加载 Screenpipe 的本地 API 使用规范仓库内置 skill 见 crates/screenpipe-core/assets/skills/screenpipe-cli/SKILL.md明确如何调用搜索 API、时间范围、分页参数等。再拉取目标调用structured_output工具的get_targets动作拿到分配给该 Pipe 的结构化输出目标targets其中包含精确的 JSON Schema、上一次提交的 payload、用户反馈、逐条目状态。然后才搜索基于目标 schema 去 Screenpipe API 中检索证据。这一顺序在源码层有直接印证。structured_output工具在 crates/screenpipe-core/assets/extensions/structured-output.ts 中注册其工具描述明确写着 Call get_targets first工具参数parameters定义了两种动作get_targets列出分配给该 Pipe 的结构化输出目标submit向某个目标提交数据需携带target_id、target_revision、payload可选evidence。get_targets拉到的目标数据结构见 structured-output.ts包含id、title、instruction目标指令、revision版本号schema_name与完整schemaJSON Schemafeedback用户对历史产物的 up/down 评分与更正文本correctionlatest上一次提交的 payload 与 evidenceitem_actions逐条目的用户状态active/resolved/snoozed/dismissed以及snoozed_until和correction。值得注意的是扩展还在before_agent_start钩子中structured-output.ts把目标元数据以数据形式注入系统提示词并强调了两条关键规则目标自身的instruction与x-screenpipe-time-range是权威的会覆盖 Pipe 正文里的默认时间回溯或格式措辞交互式列表的条目状态以用户为准。这正是原文档中Treat the requested target time range as authoritative把目标要求的时间范围视为权威的技术来源。提交时扩展会POST /outputs/targets/{target_id}/submit携带target_revision、payload与evidenceevidence 支持event_id、frame_id、transcription_id、ts、device_id等溯源字段最多 50 条。API 鉴权头来自.screenpipe-permissions.json中的pipe_token或SCREENPIPE_LOCAL_API_KEY环境变量API 地址默认取SCREENPIPE_LOCAL_API_URL或http://localhost:3030见 structured-output.ts。三、搜索边界只查 API、有限次有界搜索、绝不碰其他应用原文档对搜索环节给出了硬性约束可概括为以下几条只搜索 APISearch the API onlyAI 只能通过 Screenpipe 本地 API 检索已索引的内容永不运行代码、永不探测其他应用的文件。最多 5 次有界搜索每次limit10覆盖 messages、meetings、email、documents、issue trackers 这些在 Screenpipe 中可见的数据类型。时间窗口策略优先取最近的一小段时间差Prefer a recent delta但同时保留足够重叠use enough overlap to reconcile open items——这是为了让上一次运行遗留的未决条目能与新证据对上账。零越权不发送消息、不创建外部任务、不关闭 issue、不改动其他应用。Live View 的 handoff 按钮是另一条独立的、需用户确认的流程见下。同类 Pipe 也沿用了最多 5 次搜索 × limit10的预算。仓库中的 missed-todos/pipe.md 写道Use limit10 per search, max 5 searches over the last 3 days可作为这一约定在 Screenpipe 生态中通用性的佐证。在仓库文档 PIPE_EXECUTION_SPEC.md 中也能看到整个 Pipe 执行机制会为每次运行注入上下文头时间范围、时区、OS、API URL提示词无需再写模板变量。四、Reconciliation Contract承诺对账契约对账是整个 Pipe 最核心的工程思想每一轮运行不是从零开始重扫而是把新证据与上一次的产物做合并、去重、状态迁移。原文档列出的契约逐条拆解如下4.1 只提取明确的承诺只提取满足以下条件之一的内容明确的承诺explicit promises请求requests指派给我的行动assigned actions等待中的依赖waiting dependencies截止日期deadlines取消cancellations以及有强证据的完成strong evidence of completion。反面约束是缺少后续证据永远不能视为完成证据Absence of later evidence is never proof of completion。如果完成只是推断出来的条目必须保持打开并标记为needs review。这套逻辑在 Live View 模板的open-commitments块 intent 中也有同样表述never infer completion from silence绝不从沉默推断完成。4.2 稳定 ID跨运行复用当后续证据涉及同一个真实世界承诺时必须复用稳定的条目id。ID 的构造依据是持久的来源身份规范化后的承诺文本durable source identity plus the normalized commitment而不是列表位置或措辞本身。这是为了让 AI 能跨多次运行识别这是同一条承诺。4.3 先读旧产物再决定是否新开在判定一个条目是新条目之前必须先读上一次的 payloadprior payload。合并重复项并附上最清晰的当前上下文。这条与structured-output.ts中latest.payload的设计一一对应。4.4 用户状态是权威用户对条目的状态操作dismiss、resolve、snooze、correct具有最高权威AI 必须应用这些更正已 dismissed 的条目不得作为 active 返回已 resolved 的条目不得作为 active 返回除非后续有明确证据表明它被重新打开处于 snooze 期snoozed_until在未来的条目不得作为 active 返回。在structured-output.ts的before_agent_start系统提示词注入中也重复了这一要求Interactive list item state is user authority: keep stable item ids for the same real-world item, apply corrections, do not reintroduce dismissed items...。4.5 最小化源码片段保留的 source 片段要尽量精简但必须包含足够的来源与时间信息让用户能理解为什么这条条目存在Include enough source and timing for the user to understand why the item exists。4.6 零写操作边界Pipe 自身永不发送消息、不创建外部任务、不关闭 issue、不改动其他应用。Live View 的 handoff 按钮承担交给外部 Agent 处理的独立流程且需要用户确认。从仓库代码可以看到handoff 是 Screenpipe 应用中一类通用的、受控的转交机制例如 components/chat/home-card-agent-actions.tsx 中就有独立的 agent handoff 目标与点击埋点commitments 的actions列表里也因此保留了handoff这个动作选项。五、交互式列表条目list.v1targets的填写规范对于可操作的list.v1目标原文档要求使用目标 schema 中的可选交互字段。结合 commitments.live-view-kit.v1.json 模板其open-commitments块正是list.v1类型intent 要求Use stable ids and the interactive item fields各字段含义与填写要求如下字段要求id对同一承诺跨运行保持稳定stable across runstitle简洁的动词优先下一步行动concise verb-first next actionsubtitle负责人、依赖或它仍处于打开状态的原因status取needs review/due/open/waiting之一dueAt仅当时间有来源支撑时填 RFC3339source-backedsource简短标签应用人 / 线程 / 会议resolveLabel固定为doneactionsresolve、snooze、correct、dismiss、handoff排序原则是主收件箱按**紧迫性urgency、明确性explicitness、新鲜度recency**综合排序。同时有两条数量与诚实度约束最多 12 个打开条目at most 12 open items保持收件箱冷静克制没有依据支持时提交空数组绝不编造任务Submit empty arrays when no item is supported instead of inventing work。这与structured-output.ts中提交校验逻辑一致——submit需要target_id、target_revision、payload齐全evidence 可空但 payload 的内容必须真实有据。同类 Pipe accounting-follow-through 也采用了相同的字段模式resolveLabel: matched、actions 同为五件套、队列上限 12 条说明交互式列表条目是 Screenpipe 结构化输出体系下的一套通用约定。六、完整目标集不只是列表还有指标、时间线与上下文说明原文档最后一段要求Fill every assigned target whose schema can be supported填充所有 schema 可支持的已分配目标并且指标Metrics必须基于同一套对账后的集合计算Metrics must be calculated from the same reconciled set变更时间线changes timeline只展示实质性变更新建、截止日期 / 负责人变更、重新打开、或有来源支撑的完成而不是每次扫描的记录上下文说明context note要直白地解释不确定性或缺失的来源explain uncertainty or missing sources plainly。以 commitments.live-view-kit.v1.json 为蓝本这条 Pipe 的 Live View 完整目标集包括块 ID类型标题意图intent 摘要open-commitmentslist.v1Needs attention维护一份对账后的显式开放承诺列表用稳定 ID 与交互字段绝不从沉默推断完成due-nowmetric.v1Due now统计有来源支撑、当前已到期 / 逾期的对账后承诺数不确定日期不计入waiting-onmetric.v1Waiting统计当前被他人阻塞或已委派给他人的开放承诺数与收件箱同源needs-reviewmetric.v1Needs review统计归属、截止日期或打开状态仍需用户确认的候选承诺数material-changestimeline.v1What changed只展示有来源支撑的实质性变更新建、截止 / 负责人变更、显式完成、取消、重新打开inbox-contextmarkdown.v1What Screenpipe could verify用最多三句话解释本次刷新的证据边界、不确定性及关键来源缺口模板还定义了时间范围策略默认timeRange: 7d支持用户选择24h/7d/30dperiodPolicy为selectable.v1。这与前面提到的目标指令与时间范围是权威遥相呼应——AI 每次运行都应严格按所选时间窗对账。七、运行机制如何调度、如何手动触发、如何配置Commitments Pipe 的 frontmatterpipe.md 头部 YAML说明了它的默认运行姿态--- schedule: every 30m enabled: false history: false trigger: events: - meeting_ended template: true title: Commitments description: Keeps promises and follow-ups current as new work context arrives featured: true ---逐项解读schedule: every 30m默认调度为每 30 分钟一轮。Schedule 语法在 Screenpipe 生态中还支持every 1h、every day at 9am、every monday at 9am、cron 表达式如*/30 * * * *、一次性at RFC3339以及manual见 crates/screenpipe-core/assets/skills/screenpipe-cli/SKILL.md。enabled: false默认关闭需要用户显式启用。这与生态中安装后不自动启用的安全姿态一致。history: false不把历史输出作为上下文注入与之相对history: true会把上一次产物带进本轮提示词。trigger.events: [meeting_ended]除定时调度外还支持事件触发——当一次会议结束meeting_ended时触发运行从而在会议刚结束时立即刷新承诺。这说明 Pipe 的触发维度是调度事件双轨的。template: true标记为模板类 Pipe可在应用内作为模板启用。featured: true在 Pipe 商店 / 模板列表中置顶展示。手动触发与验证方式参考 SKILL.md# 本地 API 一键运行返回 success 只代表已启动不代表通过 curl -sS -X POST -H Authorization: Bearer $SCREENPIPE_LOCAL_API_KEY \ http://localhost:3030/pipes/commitments/run # 查看运行日志 curl -sS -H Authorization: Bearer $SCREENPIPE_LOCAL_API_KEY \ http://localhost:3030/pipes/commitments/logs也可以直接用 CLIbun x screenpipelatest pipe run commitments手动跑一轮用于测试用pipe enable commitments/pipe disable commitments启停。关于 Pipe 执行可靠性进程管理、调度竞态、超时等的机制性细节可进一步阅读仓库内的 docs/PIPE_EXECUTION_SPEC.md。八、设计意图与最佳实践小结综合原文档与仓库实现可以提炼出 Commitments Pipe 背后的几条设计原则它们也值得你在使用任何 Screenpipe 结构化输出 Pipe 时参考证据边界先行只有来源支撑的事实才进入产物——不推断完成、不编造任务、指标必须有真实的同源分母。状态以用户为准dismiss / resolve / snooze / correct 是用户权威AI 必须应用更正且不得让已关闭条目复活。稳定 ID 先读后写跨运行对账靠持久来源身份构造稳定 ID写新条目之前先读旧 payload 做合并。克制输出收件箱上限 12 条按紧迫性 / 明确性 / 新鲜度排序无依据就提交空数组。零越权只读本地索引、只写结构化目标任何外发动作都交给需要用户确认的 Live View handoff 流程。结语Commitments Pipe 是 Screenpipe持续记录 → 上下文索引 → 结构化输出流水线上极具代表性的一环它把散落在聊天、会议、邮件、工单里的隐性承诺变成一份有稳定 ID、可交互resolve / snooze / correct / dismiss / handoff、可量化的活体收件箱。理解了它的对账契约、交互字段与 Live View 目标集你既可以直接启用这条 Pipe 管理自己的跟进事项也可以以此为模板在 crates/screenpipe-core/assets/pipes 目录下读懂其他同类 Pipe如 accounting-follow-through、missed-todos的通用设计语言甚至仿照它编写属于自己的跟进队列类 Pipe。【免费下载链接】screenpipeYC (S26) | Open Computer History | Record your screen continuously locally and provide context to your agents (Claude, Codex, Openclaw, Hermes, Runner...)项目地址: https://gitcode.com/GitHub_Trending/sc/screenpipe创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

Screenpipe Commitments Pipe 实战指南：从散落上下文到一份可收敛的承诺收件箱

相关推荐

Rust 面向 NVIDIA GPU 的 nvptx64-nvidia-cuda 目标平台：工具链配置、PTX 约束与源码级原理

快速搞定多线程数据共享：moodycamel::ConcurrentQueue 无锁并发队列完整指南

Mastra Agent 接入 MCP 实战回顾：用四个 MCP 服务器与增强记忆构建全能个人助理

更多资讯

GaN驱动器集成电流隔离技术深度解析

Cua Driver 加密 Computer History 实战指南：安装、启用、审计与加密删除

WTK6900FC硬件级鼾声检测原理与工程落地指南

在 ESP32-P4 上运行 Slint：use cases 示例的 ESP-IDF 构建与部署实战

如何用 Mastra 的 Agent.stream() 流式输出代理响应并消费 textStream

Screenpipe SDK 的 Electron 集成：构建一个可运行的最小屏幕录制桌面应用

今日更新

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？