Poteto Mode 会话接力实战指南用 Session Pickup Playbook 无缝接管前序 Agent 的中断工作【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins本指南以 pstack 插件中 poteto-mode 技能的 session-pickup playbook 为骨架深入解析 AI Agent 如何在多轮会话、上下文压缩或跨 Agent 交接时只读接管前序工作、精准定位断点并继续推进的完整方法论。读完本文你将掌握定位先前轨迹trail、重建操作状态、区分已完成与待办、路由到正确 playbook、以及在真实工件上验证继承结论的五个实战步骤并理解它与 pause-safely playbook 的互补关系。为什么需要 Session PickupAgent 会话的断点续传问题在 poteto-mode 的工作方式中一个任务的执行经常跨越多个会话上下文窗口接近上限、Cursor 重启、用户暂时离开后回来、或任务被交给另一个子代理继续。此时新会话的 Agent 面对的核心问题不是怎么从头做而是上一个 Agent 到底停在哪里、已经做完了什么、还剩什么。pstack 的 poteto-mode SKILL.md 将 Session pickup 正式定义为一类独立 playbookSession pickup.Resuming or taking over a prior agents in-flight work from a transcript, cloud-agent URL, or pushed branch.playbooks/session-pickup.md.它与Pause safelyplaybooks/pause-safely.md是一对互补操作Pause safely 负责留下一个冷启动 Agent 可以恢复的检查点Session pickup 则负责读取这个检查点并继续。前者发生在暂停时后者发生在恢复时。该 playbook 开篇即点明其所有权与核心态度You own the resume point. Read the prior trail, dont redo it.你拥有断点。阅读先前轨迹不要重做。这决定了整个 playbook 的基调先前轨迹是权威输入恢复者的职责是理解并继承它而不是怀疑并重推它。第一步定位并读取先前轨迹trail恢复会话的第一步是从三种可能的来源中找到前序 Agent 留下的轨迹本地 transcript位于当前活动工作区的agent-transcripts/目录下具体路径由系统提示词system prompt指明。这里有一条硬性约束禁止在~/.cursor/projects/*/下做 glob 搜索——那会跨越工作区边界读取到无关项目的私聊记录。Cloud-agent URL云端 Agent 运行的记录链接。推送的分支pushed branch如果前序工作已提交并推送分支本身就是轨迹载体。找到轨迹后读取策略讲究优先级与成本控制先读元数据概览metadata overview和最后几条消息快速建立全局认知再向前回扫关键决策点decision points理解为什么这么做而不只是做了什么长 transcript 必须交给子代理解析只把压缩后的时间线reduced timeline留在主线程。这最后一条直接对应 principle-guard-the-context-window 技能 的核心模式上下文窗口在会话内是有限且不可再生的每个 token 都应有其价值冗长输出、截图、大文档应该路由到子代理主上下文只保留摘要而非原始数据。如果恢复者把整个 transcript 塞进主线程那么它还没开始干活就把上下文耗尽等于用一个新的资源危机去解决旧的资源危机。第二步重建操作状态reconstruct operational state读完轨迹后需要把前序 Agent 的世界状态在自己脑中重建出来。playbook 要求恢复者明确掌握四类事实状态维度手段说明分支与工作树branch and worktree检查当前 git 状态确认在哪个分支、工作树是否干净已经落地的内容what already landedgit log、git diff对照 base哪些提交已进入历史相对基准分支改了什么未完成的待办open todos读取前序记录还有哪些 todo 项处于打开状态已做的决策decisions made回扫轨迹中的决策点为什么选择方案 A 而非 B这里 playbook 给出了一条反复强调的心理纪律The prior trail is authoritative input. Resist the bias to re-derive it.先前轨迹是权威输入。抵制重新推导它的倾向。这是对人类工程师习惯不亲眼验证就不放心的刻意反制。在一个多会话接力体系里前序 Agent 留下的记录就是事实来源恢复者若执意用自己的方式重新推导一遍不仅浪费时间还可能因为信息不完整而推导出与事实不同的结论。第三步区分已完成与待办diff done vs pending重建状态之后需要做一个精确的差额分析Compare what shipped against what was planned, name the resume point, do not re-run the prior repro or redo completed work.将已经交付的与原本计划的进行对比明确指出断点resume point并且——关键约束——不要重新运行前序的复现步骤不要重做已完成的工作。playbook 特别警告了一种危险心态A let me verify from scratch pass means youre treating the trail as untrustworthy when its authoritative.让我从头验证一遍意味着你把权威的轨迹当成了不可信的东西。这里的细微之处在于第三步的不重做与第五步的验证并不矛盾。第三步反对的是重复执行前序工作本身重跑 repro、重写代码、重做调查第五步要求的是在真实工件上验证继承下来的结论见下文。前者的对象是工作后者的对象是断言。第四步路由剩余工作到匹配的 playbook并给出判定Session pickup 是一个交接型 playbook——它的终点就是下一个 playbook 的起点Route the remaining work to the matching playbook and pick the verdict... The pickup playbook ends here. The routed playbook owns the rest.将剩余工作路由到匹配的 playbook并做出判定……pickup playbook 到此结束。被路由的 playbook 拥有剩余的一切。路由的目标是 poteto-mode 的 playbook 体系。根据 SKILL.md 的 playbook 索引常见路由目标包括Investigationplaybooks/investigation.md只读问题X 是怎么工作的为什么 Y 这样设计Bug fixplaybooks/bug-fix.md复现、定位根因、以运行时证据修复已报告的缺陷Featureplaybooks/feature.md基于命名数据形状实现新行为Babysitplaybooks/babysit.md驱动 PR 或 PR 栈走向可合并状态Shippingplaybooks/shipping.md独立验证绿色栈后从根部逐 PR 落地Autonomous runplaybooks/autonomous-run.md以可检查的谓词定义完成条件并持续推进。在路由的同时恢复者要给出四种可能的**判定verdict**之一continue the execution继续执行工作尚未完成按原计划推进ship a finished recommendation交付已完成的建议工作已产出可交付的结论进入汇报/落地流程ratify or override a prior conclusion批准或推翻前序结论前序 Agent 下过结论恢复者基于证据选择认可或否决postmortem a failed run复盘失败的运行前序尝试失败进入复盘而非无意义重试。注意 SKILL.md 中规定的 playbook 执行纪律匹配到 playbook 后应打开一个 todo list其首批条目就是该 playbook 的步骤原文不做的步骤也要保留在列表中并附一行skip: reason。也就是说接力之后的每一步都应是显式、可审计的而不是模糊的继续干活。第五步在真实工件上验证继承的结论路由完成、新 playbook 接管后恢复者还必须对继承下来的断言做一次验证Verify the inherited claims against the original goal on the real artifact. A passing prior self-report is not the proof.在真实工件上、对照原始目标验证继承的断言。前序 Agent 声称通过了并不是证据。这一条直接来自 principle-prove-it-works 技能完成任何任务后在宣布完成之前必须直接检查真实的东西——运行功能、读取实际值、检查 diff——而不是通过代理proxy、自我报告或它编译过了来推断。该技能强调检查真实工件而非派生态file mtime、输出新鲜度、Agent 自述、缓存截图委派验证时信任工件而非自述检查实际的输出工件git diff、文件内容、运行时行为而不是委派者的总结最强的证据是可确定性重跑的脚本而非一次性目测。在接力场景中这条原则尤其重要前序 Agent 的测试通过可能基于旧代码、错误表面或过期缓存。恢复者必须在当前真实工件上重新确认——但正如第三步所说这不等于重做工作而是对关键断言的轻量复核。回复模板接力结果的四要素playbook 规定了恢复者在回复中必须交代的四项内容Reply:where the prior agent stopped, what you inherited vs redid (ideally nothing redone), the resume point, and the outcome.前序 Agent 停在哪里where the prior agent stopped断点的位置你继承了什么 vs 重做了什么what you inherited vs redid理想情况下什么都没重做——这是接力效率的度量指标断点the resume point下一步从哪开始结果the outcome当前工作的最终状态。这四条构成了接力交接单任何一位后来者读到这条回复都能瞬间明白前序轨迹的价值是否被保留、是否被重复劳动污染。与 Pause Safely 的配套让接力成为可能Session pickup 能高效工作的前提是前序会话在暂停时遵守了 pause-safely playbook 的规范。对照阅读两者可以看清整个生命周期Pause Safely暂停侧Session Pickup恢复侧在安全边界停止不中断在已知损坏状态的编辑定位前序停止的位置用清晰的wip:提交固化未提交的编辑用git log/git diff重建已落地内容在上下文之外写下恢复笔记intent、进度、验证过的内容、当前状态、下一步、关键文件、陷阱先读元数据与最后消息再回扫决策点上下文压缩触发时写入/tmp/slug-resume.md从 transcript 中提取决策点时间线正是暂停侧留下干净检查点才让恢复侧只读轨迹而不重做成为可能。两者共同构成了 poteto-mode 中长时间任务可以安全跨会话、跨 Agent 执行的机制基础。从 poteto-agent 子代理定义 可以看出这一体系还支持is_background: true的后台代理以接力方式持续工作而 SKILL.md 则要求每次Task调用默认run_in_background: true进一步放大了多会话接力在长任务如 autonomous run、orchestrate中的价值。实战要点与常见误区小结五个步骤速查定位轨迹本地agent-transcripts/系统提示词指定的路径、cloud-agent URL 或推送的分支先读元数据与最后消息再回扫决策点长记录交子代理压缩主线程只留时间线摘要重建状态分支/工作树、已落地内容git log/git diff、待办、决策以轨迹为权威差额分析对比已交付与已计划明确断点不重跑 repro、不重做已完成工作路由与判定按任务类型路由到 Investigation / Bug fix / Feature / Babysit / Shipping 等 playbook并选择 continue / ship / ratify-or-override / postmortem 四种判定验证断言在真实工件上对照原始目标验证继承的结论前序自述不算证据。四个必须避免的误区❌ 在~/.cursor/projects/*/下 glob 搜记录——跨越工作区边界读取无关项目的私聊❌ 从头验证一遍式重做——把权威轨迹当作不可信输入❌ 把整份长 transcript 塞进主上下文——违背 guard-the-context-window还没开始就耗尽窗口❌ 拿前序 Agent 的通过了当最终证据——prove-it-works 要求检查真实工件本身。一个效率度量回复中 what you inherited vs redid 的理想答案是全部继承、零重做。如果你发现自己重做了前序 Agent 的绝大部分工作那不是你勤快而是交接体系或者你的读取出了问题。延伸阅读poteto-mode 总纲 SKILL.mdplaybook 路由索引、原则清单与回复写作规范pause-safely playbookSession pickup 的互补操作负责留下可恢复的检查点principle-guard-the-context-window长记录压缩、子代理路由的底层原理principle-prove-it-works真实工件验证的底层原理poteto-agent 子代理定义接力执行者的角色契约与默认配置。【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Poteto Mode 会话接力实战指南用 Session Pickup Playbook 无缝接管前序 Agent 的中断工作【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins本指南以 pstack 插件中 poteto-mode 技能的 session-pickup playbook 为骨架深入解析 AI Agent 如何在多轮会话、上下文压缩或跨 Agent 交接时只读接管前序工作、精准定位断点并继续推进的完整方法论。读完本文你将掌握定位先前轨迹trail、重建操作状态、区分已完成与待办、路由到正确 playbook、以及在真实工件上验证继承结论的五个实战步骤并理解它与 pause-safely playbook 的互补关系。为什么需要 Session PickupAgent 会话的断点续传问题在 poteto-mode 的工作方式中一个任务的执行经常跨越多个会话上下文窗口接近上限、Cursor 重启、用户暂时离开后回来、或任务被交给另一个子代理继续。此时新会话的 Agent 面对的核心问题不是怎么从头做而是上一个 Agent 到底停在哪里、已经做完了什么、还剩什么。pstack 的 poteto-mode SKILL.md 将 Session pickup 正式定义为一类独立 playbookSession pickup.Resuming or taking over a prior agents in-flight work from a transcript, cloud-agent URL, or pushed branch.playbooks/session-pickup.md.它与Pause safelyplaybooks/pause-safely.md是一对互补操作Pause safely 负责留下一个冷启动 Agent 可以恢复的检查点Session pickup 则负责读取这个检查点并继续。前者发生在暂停时后者发生在恢复时。该 playbook 开篇即点明其所有权与核心态度You own the resume point. Read the prior trail, dont redo it.你拥有断点。阅读先前轨迹不要重做。这决定了整个 playbook 的基调先前轨迹是权威输入恢复者的职责是理解并继承它而不是怀疑并重推它。第一步定位并读取先前轨迹trail恢复会话的第一步是从三种可能的来源中找到前序 Agent 留下的轨迹本地 transcript位于当前活动工作区的agent-transcripts/目录下具体路径由系统提示词system prompt指明。这里有一条硬性约束禁止在~/.cursor/projects/*/下做 glob 搜索——那会跨越工作区边界读取到无关项目的私聊记录。Cloud-agent URL云端 Agent 运行的记录链接。推送的分支pushed branch如果前序工作已提交并推送分支本身就是轨迹载体。找到轨迹后读取策略讲究优先级与成本控制先读元数据概览metadata overview和最后几条消息快速建立全局认知再向前回扫关键决策点decision points理解为什么这么做而不只是做了什么长 transcript 必须交给子代理解析只把压缩后的时间线reduced timeline留在主线程。这最后一条直接对应 principle-guard-the-context-window 技能 的核心模式上下文窗口在会话内是有限且不可再生的每个 token 都应有其价值冗长输出、截图、大文档应该路由到子代理主上下文只保留摘要而非原始数据。如果恢复者把整个 transcript 塞进主线程那么它还没开始干活就把上下文耗尽等于用一个新的资源危机去解决旧的资源危机。第二步重建操作状态reconstruct operational state读完轨迹后需要把前序 Agent 的世界状态在自己脑中重建出来。playbook 要求恢复者明确掌握四类事实状态维度手段说明分支与工作树branch and worktree检查当前 git 状态确认在哪个分支、工作树是否干净已经落地的内容what already landedgit log、git diff对照 base哪些提交已进入历史相对基准分支改了什么未完成的待办open todos读取前序记录还有哪些 todo 项处于打开状态已做的决策decisions made回扫轨迹中的决策点为什么选择方案 A 而非 B这里 playbook 给出了一条反复强调的心理纪律The prior trail is authoritative input. Resist the bias to re-derive it.先前轨迹是权威输入。抵制重新推导它的倾向。这是对人类工程师习惯不亲眼验证就不放心的刻意反制。在一个多会话接力体系里前序 Agent 留下的记录就是事实来源恢复者若执意用自己的方式重新推导一遍不仅浪费时间还可能因为信息不完整而推导出与事实不同的结论。第三步区分已完成与待办diff done vs pending重建状态之后需要做一个精确的差额分析Compare what shipped against what was planned, name the resume point, do not re-run the prior repro or redo completed work.将已经交付的与原本计划的进行对比明确指出断点resume point并且——关键约束——不要重新运行前序的复现步骤不要重做已完成的工作。playbook 特别警告了一种危险心态A let me verify from scratch pass means youre treating the trail as untrustworthy when its authoritative.让我从头验证一遍意味着你把权威的轨迹当成了不可信的东西。这里的细微之处在于第三步的不重做与第五步的验证并不矛盾。第三步反对的是重复执行前序工作本身重跑 repro、重写代码、重做调查第五步要求的是在真实工件上验证继承下来的结论见下文。前者的对象是工作后者的对象是断言。第四步路由剩余工作到匹配的 playbook并给出判定Session pickup 是一个交接型 playbook——它的终点就是下一个 playbook 的起点Route the remaining work to the matching playbook and pick the verdict... The pickup playbook ends here. The routed playbook owns the rest.将剩余工作路由到匹配的 playbook并做出判定……pickup playbook 到此结束。被路由的 playbook 拥有剩余的一切。路由的目标是 poteto-mode 的 playbook 体系。根据 SKILL.md 的 playbook 索引常见路由目标包括Investigationplaybooks/investigation.md只读问题X 是怎么工作的为什么 Y 这样设计Bug fixplaybooks/bug-fix.md复现、定位根因、以运行时证据修复已报告的缺陷Featureplaybooks/feature.md基于命名数据形状实现新行为Babysitplaybooks/babysit.md驱动 PR 或 PR 栈走向可合并状态Shippingplaybooks/shipping.md独立验证绿色栈后从根部逐 PR 落地Autonomous runplaybooks/autonomous-run.md以可检查的谓词定义完成条件并持续推进。在路由的同时恢复者要给出四种可能的**判定verdict**之一continue the execution继续执行工作尚未完成按原计划推进ship a finished recommendation交付已完成的建议工作已产出可交付的结论进入汇报/落地流程ratify or override a prior conclusion批准或推翻前序结论前序 Agent 下过结论恢复者基于证据选择认可或否决postmortem a failed run复盘失败的运行前序尝试失败进入复盘而非无意义重试。注意 SKILL.md 中规定的 playbook 执行纪律匹配到 playbook 后应打开一个 todo list其首批条目就是该 playbook 的步骤原文不做的步骤也要保留在列表中并附一行skip: reason。也就是说接力之后的每一步都应是显式、可审计的而不是模糊的继续干活。第五步在真实工件上验证继承的结论路由完成、新 playbook 接管后恢复者还必须对继承下来的断言做一次验证Verify the inherited claims against the original goal on the real artifact. A passing prior self-report is not the proof.在真实工件上、对照原始目标验证继承的断言。前序 Agent 声称通过了并不是证据。这一条直接来自 principle-prove-it-works 技能完成任何任务后在宣布完成之前必须直接检查真实的东西——运行功能、读取实际值、检查 diff——而不是通过代理proxy、自我报告或它编译过了来推断。该技能强调检查真实工件而非派生态file mtime、输出新鲜度、Agent 自述、缓存截图委派验证时信任工件而非自述检查实际的输出工件git diff、文件内容、运行时行为而不是委派者的总结最强的证据是可确定性重跑的脚本而非一次性目测。在接力场景中这条原则尤其重要前序 Agent 的测试通过可能基于旧代码、错误表面或过期缓存。恢复者必须在当前真实工件上重新确认——但正如第三步所说这不等于重做工作而是对关键断言的轻量复核。回复模板接力结果的四要素playbook 规定了恢复者在回复中必须交代的四项内容Reply:where the prior agent stopped, what you inherited vs redid (ideally nothing redone), the resume point, and the outcome.前序 Agent 停在哪里where the prior agent stopped断点的位置你继承了什么 vs 重做了什么what you inherited vs redid理想情况下什么都没重做——这是接力效率的度量指标断点the resume point下一步从哪开始结果the outcome当前工作的最终状态。这四条构成了接力交接单任何一位后来者读到这条回复都能瞬间明白前序轨迹的价值是否被保留、是否被重复劳动污染。与 Pause Safely 的配套让接力成为可能Session pickup 能高效工作的前提是前序会话在暂停时遵守了 pause-safely playbook 的规范。对照阅读两者可以看清整个生命周期Pause Safely暂停侧Session Pickup恢复侧在安全边界停止不中断在已知损坏状态的编辑定位前序停止的位置用清晰的wip:提交固化未提交的编辑用git log/git diff重建已落地内容在上下文之外写下恢复笔记intent、进度、验证过的内容、当前状态、下一步、关键文件、陷阱先读元数据与最后消息再回扫决策点上下文压缩触发时写入/tmp/slug-resume.md从 transcript 中提取决策点时间线正是暂停侧留下干净检查点才让恢复侧只读轨迹而不重做成为可能。两者共同构成了 poteto-mode 中长时间任务可以安全跨会话、跨 Agent 执行的机制基础。从 poteto-agent 子代理定义 可以看出这一体系还支持is_background: true的后台代理以接力方式持续工作而 SKILL.md 则要求每次Task调用默认run_in_background: true进一步放大了多会话接力在长任务如 autonomous run、orchestrate中的价值。实战要点与常见误区小结五个步骤速查定位轨迹本地agent-transcripts/系统提示词指定的路径、cloud-agent URL 或推送的分支先读元数据与最后消息再回扫决策点长记录交子代理压缩主线程只留时间线摘要重建状态分支/工作树、已落地内容git log/git diff、待办、决策以轨迹为权威差额分析对比已交付与已计划明确断点不重跑 repro、不重做已完成工作路由与判定按任务类型路由到 Investigation / Bug fix / Feature / Babysit / Shipping 等 playbook并选择 continue / ship / ratify-or-override / postmortem 四种判定验证断言在真实工件上对照原始目标验证继承的结论前序自述不算证据。四个必须避免的误区❌ 在~/.cursor/projects/*/下 glob 搜记录——跨越工作区边界读取无关项目的私聊❌ 从头验证一遍式重做——把权威轨迹当作不可信输入❌ 把整份长 transcript 塞进主上下文——违背 guard-the-context-window还没开始就耗尽窗口❌ 拿前序 Agent 的通过了当最终证据——prove-it-works 要求检查真实工件本身。一个效率度量回复中 what you inherited vs redid 的理想答案是全部继承、零重做。如果你发现自己重做了前序 Agent 的绝大部分工作那不是你勤快而是交接体系或者你的读取出了问题。延伸阅读poteto-mode 总纲 SKILL.mdplaybook 路由索引、原则清单与回复写作规范pause-safely playbookSession pickup 的互补操作负责留下可恢复的检查点principle-guard-the-context-window长记录压缩、子代理路由的底层原理principle-prove-it-works真实工件验证的底层原理poteto-agent 子代理定义接力执行者的角色契约与默认配置。【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
 在 HIP 内核中稳定可用的编译器变更)
