尧图网页设计 
oh-my-pi 会话压缩中的增量摘要更新提示词compaction-update-summary 的设计与实现【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi导读oh-my-picrates 与 packages 组成的 Coding Agent 项目在会话上下文逼近窗口上限时会触发压缩compaction流程将长对话浓缩为结构化 handoff summary供后续 LLM 无缝接续任务。compaction-update-summary.md 正是该流程中负责增量更新已有摘要的核心提示词当会话中已存在上一轮压缩产出的 summary 时它指导模型以保留 更新的方式合并新旧信息而不是从头重写。读完本文你将掌握该提示词的完整指令语义、输出格式契约以及它在 oh-my-pi 压缩管线中的实际调用位置与多窗口工作机理。一、为什么需要增量更新式摘要从初始摘要到持续接续会话压缩的本质是用一段结构化摘要替换掉被裁剪的对话但压缩不是一次性的首次压缩时没有历史摘要管线使用 compaction-summary.md初始摘要提示词从零开始总结后续再次压缩时上一轮留下的 summary 必须被保留并增量更新否则接续模型会丢失此前所有决策与进展。这一分支在源码中有直接体现。compaction.ts 的summarizeConversationWindow中// Use update prompt if we have a previous summary, otherwise initial prompt let basePrompt previousSummary ? UPDATE_SUMMARIZATION_PROMPT : SUMMARIZATION_PROMPT;SUMMARIZATION_PROMPT由compactionSummaryPrompt渲染而来UPDATE_SUMMARIZATION_PROMPT则来自本文主角compactionUpdateSummaryPromptcompaction.ts。也就是说只要存在previousSummary就会自动切换为更新模式这正是 compaction-update-summary 提示词被触发的前提。二、提示词的核心指令契约MUST 规则逐条拆解compaction-update-summary 在开篇即明确任务定义从上方新消息中更新previous-summary标签内的既有 handoff summary供另一个 LLM 接续。其MUST规则构成完整的指令契约逐条解析如下。1. 全量保留 增量追加preserve all previous-summary information; add new progress, decisions, context.更新不是重写旧摘要中的每一条信息都必须原样保留新消息中产生的新进展、新决策、新上下文以追加方式融入。这保证了多轮压缩后摘要的信息单调递增不因二次压缩而丢失任何历史结论。2. 状态迁移Progress 子节的三态流转Progress: move completed In Progress items to Done. update Next Steps for completed work.摘要中Progress采用任务看板式的三态管理### Done已完成### In Progress进行中### Blocked被阻塞。每次更新时已完成项必须从In Progress迁移到Done对应源码模板中的- [x]与- [ ]复选框标记同时把已完成的条目从Next Steps中移除或改写。这种看板状态机让接续模型一眼就能判断当前任务到底推进到了哪一步。3. 关键信息零失真preserve exact file paths, function names, error messages.这是面向代码 Agent 场景的硬性要求文件路径、函数名、错误消息属于不可泛化重述的精确事实。一旦被模型转述成近似表述接续模型将无法定位代码、复现错误。因此提示词明确禁止对这类信息做模糊化处理。4. 遗留问题的显式交接If new messages end with an unanswered user question/request: add it to Critical Context; replace any previous pending question if answered.对话常以未回答的问题或待执行的请求收尾例如用户要求请运行命令并粘贴输出。此时该问题必须被写入Critical Context显式交接若上一轮遗留的问题在本轮已被回答则用新问题替换之避免接续模型继续执行已经过时的旧请求。这与初始摘要提示词中的对应约定preserve that exact question/request一脉相承。5. 输出纪律与格式约束output only the structured summary; NEVER extra text. keep sections concise. preserve relevant tool outputs/command results. include mentioned repository state changes (branch, uncommitted changes).四条输出纪律缺一不可纯结构化输出只输出摘要本身禁止寒暄、解释或任何额外文本保证压缩结果可直接作为系统上下文注入节制长度各小节保持精简控制压缩后的 token 开销工具结果留存相关工具输出/命令结果如 grep 命中、测试输出需要保留它们是后续模型判断正确性的证据仓库状态快照若对话中提到分支切换、未提交改动等仓库状态变化必须记录进摘要——代码 Agent 接续时若不知道当前在哪个分支、有哪些脏改动很可能在错误的代码基上继续工作。三、输出格式模板七个章节的语义与协作提示词规定使用以下结构化格式且允许省略不适用的章节章节职责更新时的主要操作## Goal会话总体目标保留既有目标任务扩展时追加新目标## Constraints Preferences约束与偏好保留既有约束补充新发现的约束## Progress / ### Done已完成工作并入之前已完成项与本次新完成项## Progress / ### In Progress进行中工作依据进展实时更新## Progress / ### Blocked阻塞事项保留未解决阻塞已解决的删除## Key Decisions关键决策全部保留旧决策追加新决策及其简短理由## Next Steps下一步动作按当前状态重排为有序列表## Critical Context关键上下文保留重要上下文追加未回答的遗留问题等## Additional Notes补充说明其他无法归入上述章节的重要信息Key Decisions采用- **[Decision]**: [Brief rationale]的形式强制模型为每个决策附带一句理由这样后续模型不仅能知道做了什么决定还能理解为什么这么决定。七个章节共同构成一份可接续任务书比自由文本摘要更适合作为代码 Agent 的会话骨架。四、源码级的调用链摘要如何被拼装与执行compaction-update-summary 提示词并非孤立文本它在 compaction.ts 中被组织成一次完整的 LLM 调用let basePrompt previousSummary ? UPDATE_SUMMARIZATION_PROMPT : SUMMARIZATION_PROMPT; if (options?.promptOverride) { basePrompt options.promptOverride; } if (customInstructions) { basePrompt ${basePrompt}\n\nAdditional focus: ${customInstructions}; } // Build the prompt with conversation wrapped in tags let promptText conversation\n${conversationText}\n/conversation\n\n; if (previousSummary) { promptText previous-summary\n${escapeSummaryBoundaryTags(previousSummary)}\n/previous-summary\n\n; } promptText formatAdditionalContext(options?.extraContext); promptText basePrompt;该调用链揭示了几个值得注意的实现细节输入结构三件套待总结的新消息包裹在conversation标签内、旧摘要包裹在previous-summary标签内、可选的额外上下文通过formatAdditionalContext以additional-context列表追加compaction.ts。三个标签让模型明确区分新材料与既有资产边界标签转义escapeSummaryBoundaryTags会处理摘要中可能出现的嵌套标签防止模型混淆标签边界自定义指令注入调用方可通过promptOverride完全替换基础提示词或通过customInstructions追加Additional focus段落实现按会话定制的摘要侧重点远程端点支持若配置了remoteEndpoint同一份promptText会通过requestRemoteCompaction发送到远端压缩服务compaction.ts提示词逻辑在本地/远端两种模式下保持一致。五、多窗口迭代增量更新如何被反复执行长会话可能超出单次 LLM 调用的输入上限此时管线会先按 token 预算切分对话窗口planSummaryWindowscheckTokenBudget见 compaction.ts然后串行迭代执行增量更新carriedSummary await summarizeConversationWindow(window1, undefined, ...); // 首次初始摘要 carriedSummary await summarizeConversationWindow(window2, carriedSummary, ...); // 后续增量更新 carriedSummary await summarizeConversationWindow(window3, carriedSummary, ...);第一个窗口没有历史摘要走SUMMARIZATION_PROMPT生成初始摘要从第二个窗口起carriedSummary不断回传每一轮都进入更新模式即每次调用都使用本文所讲的 compaction-update-summary 提示词把前一轮的摘要作为previous-summary喂给模型增量合并。这一机制与 compaction-summary-context.md 中summary{{summary}}/summary的上下文拼装模板相互配合实现分窗消化、逐窗接力的压缩策略。窗口若被提供商实际上限拒绝ContextOverflow管线还会将窗口对半拆分重新规划compaction.ts期间每一层拆分都会再次触发增量更新确保信息逐层无损传递。六、与姊妹提示词的协作关系compaction-update-summary 是 oh-my-pi 压缩提示词家族的一员与相邻提示词各司其职目录见 packages/agent/src/compaction/prompts提示词职责compaction-summary.md首次压缩时从零生成结构化 handoff summary定义了与 update 版相同的七章节格式基准compaction-update-summary.md已有摘要时的增量更新强调保留 迁移 追加compaction-short-summary.md生成精简版摘要SHORT_SUMMARY_PROMPT用于对长度更敏感的场合compaction-turn-prefix.md单轮会话摘要的前缀提示词以conversation拼接handoff-document.md生成完整 handoff 文档供会话导出/交接使用compaction-summary-context.md提供summary标签模板声明基于先前工作构建、绝不重复的规则其中 compaction-summary 与 compaction-update-summary 构成一对初始/增量双生模板格式完全对齐均为 Goal → Constraints Preferences → Progress → Key Decisions → Next Steps → Critical Context → Additional Notes只是更新版额外强调状态迁移、遗留问题替换与仓库状态记录。这种成对设计让两种模式产出的摘要格式一致接续模型无需区分摘要来源即可消费。七、实践要点与适用边界在使用或定制该提示词时可参考以下要点务必保留标签结构conversation与previous-summary的 XML 式包裹是模型区分新旧信息的锚点任何解析、转义逻辑escapeSummaryBoundaryTags都围绕这两个标签展开精确信息是底线文件路径、函数名、错误消息的保真度直接决定接续模型能否继续干活这也是提示词将preserve exact…列为 MUST 的原因状态迁移要显式In Progress → Done的迁移与Next Steps的同步更新是摘要保持任务可执行性的关键写摘要时不应只做信息堆砌长度与信息量权衡提示词同时要求keep sections concise与preserve all previous-summary information实际效果取决于模型对精简表述、完整语义的理解必要时可通过customInstructions补充侧重说明适用边界该提示词是压缩管线的内部实现细节面向 LLM 输入而非用户界面其行为受会话是否已有previousSummary自动控制调用方无需手动指定模式。综上compaction-update-summary 以保留 迁移 追加 交接四步为核心配合看板式三态 Progress 与七章节结构化模板保证了 oh-my-pi 在多轮长会话中摘要的连续性、完整性与可执行性而 compaction.ts 中窗口化迭代调用链则为这一提示词提供了逐窗接力、层层增量的工程化落地。【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 oh-my-pi 会话压缩中的增量摘要更新提示词：compaction-update-summary 的设计与实现
oh-my-pi 会话压缩中的增量摘要更新提示词compaction-update-summary 的设计与实现【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi导读oh-my-picrates 与 packages 组成的 Coding Agent 项目在会话上下文逼近窗口上限时会触发压缩compaction流程将长对话浓缩为结构化 handoff summary供后续 LLM 无缝接续任务。compaction-update-summary.md 正是该流程中负责增量更新已有摘要的核心提示词当会话中已存在上一轮压缩产出的 summary 时它指导模型以保留 更新的方式合并新旧信息而不是从头重写。读完本文你将掌握该提示词的完整指令语义、输出格式契约以及它在 oh-my-pi 压缩管线中的实际调用位置与多窗口工作机理。一、为什么需要增量更新式摘要从初始摘要到持续接续会话压缩的本质是用一段结构化摘要替换掉被裁剪的对话但压缩不是一次性的首次压缩时没有历史摘要管线使用 compaction-summary.md初始摘要提示词从零开始总结后续再次压缩时上一轮留下的 summary 必须被保留并增量更新否则接续模型会丢失此前所有决策与进展。这一分支在源码中有直接体现。compaction.ts 的summarizeConversationWindow中// Use update prompt if we have a previous summary, otherwise initial prompt let basePrompt previousSummary ? UPDATE_SUMMARIZATION_PROMPT : SUMMARIZATION_PROMPT;SUMMARIZATION_PROMPT由compactionSummaryPrompt渲染而来UPDATE_SUMMARIZATION_PROMPT则来自本文主角compactionUpdateSummaryPromptcompaction.ts。也就是说只要存在previousSummary就会自动切换为更新模式这正是 compaction-update-summary 提示词被触发的前提。二、提示词的核心指令契约MUST 规则逐条拆解compaction-update-summary 在开篇即明确任务定义从上方新消息中更新previous-summary标签内的既有 handoff summary供另一个 LLM 接续。其MUST规则构成完整的指令契约逐条解析如下。1. 全量保留 增量追加preserve all previous-summary information; add new progress, decisions, context.更新不是重写旧摘要中的每一条信息都必须原样保留新消息中产生的新进展、新决策、新上下文以追加方式融入。这保证了多轮压缩后摘要的信息单调递增不因二次压缩而丢失任何历史结论。2. 状态迁移Progress 子节的三态流转Progress: move completed In Progress items to Done. update Next Steps for completed work.摘要中Progress采用任务看板式的三态管理### Done已完成### In Progress进行中### Blocked被阻塞。每次更新时已完成项必须从In Progress迁移到Done对应源码模板中的- [x]与- [ ]复选框标记同时把已完成的条目从Next Steps中移除或改写。这种看板状态机让接续模型一眼就能判断当前任务到底推进到了哪一步。3. 关键信息零失真preserve exact file paths, function names, error messages.这是面向代码 Agent 场景的硬性要求文件路径、函数名、错误消息属于不可泛化重述的精确事实。一旦被模型转述成近似表述接续模型将无法定位代码、复现错误。因此提示词明确禁止对这类信息做模糊化处理。4. 遗留问题的显式交接If new messages end with an unanswered user question/request: add it to Critical Context; replace any previous pending question if answered.对话常以未回答的问题或待执行的请求收尾例如用户要求请运行命令并粘贴输出。此时该问题必须被写入Critical Context显式交接若上一轮遗留的问题在本轮已被回答则用新问题替换之避免接续模型继续执行已经过时的旧请求。这与初始摘要提示词中的对应约定preserve that exact question/request一脉相承。5. 输出纪律与格式约束output only the structured summary; NEVER extra text. keep sections concise. preserve relevant tool outputs/command results. include mentioned repository state changes (branch, uncommitted changes).四条输出纪律缺一不可纯结构化输出只输出摘要本身禁止寒暄、解释或任何额外文本保证压缩结果可直接作为系统上下文注入节制长度各小节保持精简控制压缩后的 token 开销工具结果留存相关工具输出/命令结果如 grep 命中、测试输出需要保留它们是后续模型判断正确性的证据仓库状态快照若对话中提到分支切换、未提交改动等仓库状态变化必须记录进摘要——代码 Agent 接续时若不知道当前在哪个分支、有哪些脏改动很可能在错误的代码基上继续工作。三、输出格式模板七个章节的语义与协作提示词规定使用以下结构化格式且允许省略不适用的章节章节职责更新时的主要操作## Goal会话总体目标保留既有目标任务扩展时追加新目标## Constraints Preferences约束与偏好保留既有约束补充新发现的约束## Progress / ### Done已完成工作并入之前已完成项与本次新完成项## Progress / ### In Progress进行中工作依据进展实时更新## Progress / ### Blocked阻塞事项保留未解决阻塞已解决的删除## Key Decisions关键决策全部保留旧决策追加新决策及其简短理由## Next Steps下一步动作按当前状态重排为有序列表## Critical Context关键上下文保留重要上下文追加未回答的遗留问题等## Additional Notes补充说明其他无法归入上述章节的重要信息Key Decisions采用- **[Decision]**: [Brief rationale]的形式强制模型为每个决策附带一句理由这样后续模型不仅能知道做了什么决定还能理解为什么这么决定。七个章节共同构成一份可接续任务书比自由文本摘要更适合作为代码 Agent 的会话骨架。四、源码级的调用链摘要如何被拼装与执行compaction-update-summary 提示词并非孤立文本它在 compaction.ts 中被组织成一次完整的 LLM 调用let basePrompt previousSummary ? UPDATE_SUMMARIZATION_PROMPT : SUMMARIZATION_PROMPT; if (options?.promptOverride) { basePrompt options.promptOverride; } if (customInstructions) { basePrompt ${basePrompt}\n\nAdditional focus: ${customInstructions}; } // Build the prompt with conversation wrapped in tags let promptText conversation\n${conversationText}\n/conversation\n\n; if (previousSummary) { promptText previous-summary\n${escapeSummaryBoundaryTags(previousSummary)}\n/previous-summary\n\n; } promptText formatAdditionalContext(options?.extraContext); promptText basePrompt;该调用链揭示了几个值得注意的实现细节输入结构三件套待总结的新消息包裹在conversation标签内、旧摘要包裹在previous-summary标签内、可选的额外上下文通过formatAdditionalContext以additional-context列表追加compaction.ts。三个标签让模型明确区分新材料与既有资产边界标签转义escapeSummaryBoundaryTags会处理摘要中可能出现的嵌套标签防止模型混淆标签边界自定义指令注入调用方可通过promptOverride完全替换基础提示词或通过customInstructions追加Additional focus段落实现按会话定制的摘要侧重点远程端点支持若配置了remoteEndpoint同一份promptText会通过requestRemoteCompaction发送到远端压缩服务compaction.ts提示词逻辑在本地/远端两种模式下保持一致。五、多窗口迭代增量更新如何被反复执行长会话可能超出单次 LLM 调用的输入上限此时管线会先按 token 预算切分对话窗口planSummaryWindowscheckTokenBudget见 compaction.ts然后串行迭代执行增量更新carriedSummary await summarizeConversationWindow(window1, undefined, ...); // 首次初始摘要 carriedSummary await summarizeConversationWindow(window2, carriedSummary, ...); // 后续增量更新 carriedSummary await summarizeConversationWindow(window3, carriedSummary, ...);第一个窗口没有历史摘要走SUMMARIZATION_PROMPT生成初始摘要从第二个窗口起carriedSummary不断回传每一轮都进入更新模式即每次调用都使用本文所讲的 compaction-update-summary 提示词把前一轮的摘要作为previous-summary喂给模型增量合并。这一机制与 compaction-summary-context.md 中summary{{summary}}/summary的上下文拼装模板相互配合实现分窗消化、逐窗接力的压缩策略。窗口若被提供商实际上限拒绝ContextOverflow管线还会将窗口对半拆分重新规划compaction.ts期间每一层拆分都会再次触发增量更新确保信息逐层无损传递。六、与姊妹提示词的协作关系compaction-update-summary 是 oh-my-pi 压缩提示词家族的一员与相邻提示词各司其职目录见 packages/agent/src/compaction/prompts提示词职责compaction-summary.md首次压缩时从零生成结构化 handoff summary定义了与 update 版相同的七章节格式基准compaction-update-summary.md已有摘要时的增量更新强调保留 迁移 追加compaction-short-summary.md生成精简版摘要SHORT_SUMMARY_PROMPT用于对长度更敏感的场合compaction-turn-prefix.md单轮会话摘要的前缀提示词以conversation拼接handoff-document.md生成完整 handoff 文档供会话导出/交接使用compaction-summary-context.md提供summary标签模板声明基于先前工作构建、绝不重复的规则其中 compaction-summary 与 compaction-update-summary 构成一对初始/增量双生模板格式完全对齐均为 Goal → Constraints Preferences → Progress → Key Decisions → Next Steps → Critical Context → Additional Notes只是更新版额外强调状态迁移、遗留问题替换与仓库状态记录。这种成对设计让两种模式产出的摘要格式一致接续模型无需区分摘要来源即可消费。七、实践要点与适用边界在使用或定制该提示词时可参考以下要点务必保留标签结构conversation与previous-summary的 XML 式包裹是模型区分新旧信息的锚点任何解析、转义逻辑escapeSummaryBoundaryTags都围绕这两个标签展开精确信息是底线文件路径、函数名、错误消息的保真度直接决定接续模型能否继续干活这也是提示词将preserve exact…列为 MUST 的原因状态迁移要显式In Progress → Done的迁移与Next Steps的同步更新是摘要保持任务可执行性的关键写摘要时不应只做信息堆砌长度与信息量权衡提示词同时要求keep sections concise与preserve all previous-summary information实际效果取决于模型对精简表述、完整语义的理解必要时可通过customInstructions补充侧重说明适用边界该提示词是压缩管线的内部实现细节面向 LLM 输入而非用户界面其行为受会话是否已有previousSummary自动控制调用方无需手动指定模式。综上compaction-update-summary 以保留 迁移 追加 交接四步为核心配合看板式三态 Progress 与七章节结构化模板保证了 oh-my-pi 在多轮长会话中摘要的连续性、完整性与可执行性而 compaction.ts 中窗口化迭代调用链则为这一提示词提供了逐窗接力、层层增量的工程化落地。【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考