oh-my-pi 瞬时侧信道回合机制side-channel-no-tools 系统提示词与无工具问答管线解析【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi导读本文聚焦 oh-my-picoding agent内部一套鲜为人知但至关重要的机制——瞬时侧信道回合Ephemeral Side-Channel Turn。它以 side-channel-no-tools.md 这份系统提示词为行为约束支撑着/btw、/omfg、IRC 自动回复、会话交接handoff等不打断主任务的旁路问答能力。读完本文你将理解这套提示词每一行的设计意图、它在 agent-session.ts 中的完整执行管线快照构建、prompt cache 保持、工具调用丢弃、响应去重以及它在 IRC 总线与 RPC 控制帧两个场景下的落地方式。一、先看文档本身五行的铁律side-channel-no-tools.md全文只有五句话属于系统级system-remindersystem-reminder Ephemeral side-channel turn; reuses current conversation context. Tool catalog attached only to keep prompt cache warm; tools NOT available this turn. Do NOT emit tool calls; reply plain text only. Tool calls discarded without execution. /system-reminder逐句拆解它同时立下了四条约束瞬时Ephemeral这是一个用完即弃的回合不写入会话历史、不修改任何持久化状态复用当前上下文reuses current conversation context模型看到的是与主回合一致的会话快照因此能基于进行中的任务给出上下文相关的旁路回答工具目录仅供暖缓存keep prompt cache warm工具目录照常附上但仅供保持 provider 侧 prompt cache 命中本回合不真正可用严禁工具调用Do NOT emit tool calls即使模型误发工具调用也会被丢弃且不执行本回合只能输出纯文本。正是这份只有约束、没有业务逻辑的提示词被注入到每次侧信道回合的上下文末尾与模型当前 system prompt 共同决定模型的旁路行为。它本身几乎不包含逻辑真正的工程实现全部落在宿主代码中——这正是本文后续要展开的部分。二、宿主实现runEphemeralTurn与瞬时快照构建2.1 入口一次只读的并行推理在 agent-session.ts 中runEphemeralTurn是侧信道回合的统一入口其 JSDoc 精确描述了设计契约Run a single ephemeral side-channel turn against this sessions current model system prompt history. The main turns tool catalog is sent to preserve the prompt cache, but the model is reminded not to call tools and any tool calls are discarded. The side request does not block on, or interfere with, any in-flight main turn. The sessions history and persisted state are NOT modified by this call.这段注释直接呼应了提示词中的每一行主回合的工具目录照发但只用于保缓存对应第 2 句、工具调用被丢弃对应第 4 句、不阻塞也不干扰进行中的主回合、不改写历史与持久化状态对应第 1 句瞬时。从调用链看BtwController/btw与OmfgController/omfg共享这套快照 流式管线见 btw-controller.ts而sdk.ts中的注释则把侧信道请求的家族完整列出/btw、/omfg、IRC 自动回复、handoff见 sdk.ts。2.2 快照构建把半成品回答也喂给模型#buildEphemeralSnapshotagent-session.ts负责组装本次旁路回合的输入消息逻辑分三步深拷贝当前消息列表保证后续追加不污染真实会话合并正在流式输出的主回合回答如果streaming.role assistant且内容非空则把其中的thinking块与已输出的文本块提取出来替换掉消息列表中最后一条 assistant 消息或追加一条。这样模型在旁路问答时能看到主回合写到一半的内容而不是对缺失上下文做猜测。实现中还特意保留 thinking 块注释指出 DeepSeek 系编码器会把它们重放为reasoning_content一旦缺失就会直接 HTTP 400 拒绝请求依次追加两条虚拟消息role: developer的消息内容正是sideChannelNoToolsReminder该提示词文件通过with { type: text }以文本形式导入见 agent-session.tsrole: user的消息内容为本次旁路请求的实际 prompt 文本。2.3 Provider 会话与缓存独立血统、共享缓存键流式选项中有两处精心设计agent-session.tssessionId: \${cacheSessionId}:side:${Snowflake.next()}——旁路回合使用**独立请求血统**不共享 OpenAI/Codex 那种 append-only 的会话状态因为 IRC 与/btw 可能在主回合调用工具中途并行发起同时每次生成唯一后缀避免不同旁路回合互相污染promptCacheKey保持与主会话一致——prompt cache 键稳定才能让旁路回合命中主回合已经建立好的缓存这也是提示词第 2 句保持缓存温暖的代码落点。注释还补充了一个细节共享的providerSessionState映射仍然必须传入因为 Codex 需要在侧信道 session id 下分配 websocket 状态。2.4 响应收尾净化、去重与降级runEphemeralTurn对流式事件的收尾同样值得细读text_delta 实时转发通过onTextDelta回调把增量文本推给 UI如/btw面板逐字渲染并配合#deobfuscatedProviderTextReadyForDelta做机密脱敏后再外发done 事件健壮性Array.isArray(event.message.content) ? event.message.content : []——自定义扩展 provider 或 gateway 包装的 OAuth 流issue #4323可能把content字段丢弃或替换为undefined此处归一化为空数组让复盘回合显示空回复而非把一次畸形旁路响应升级成会话静默崩溃工具调用强制剔除content.filter(block block.type ! toolCall)——即使模型违反提示词发了工具调用也会在 sanitize 阶段被物理删除与提示词第 4 句Tool calls discarded without execution双重呼应回复去重默认经dedupeEphemeralReply折叠退化重复行并限制长度见 messages.ts只有调用方显式传dedupeReply: false时才返回原文。三、场景一/btw与/omfg瞬时问答/btw是侧信道机制最典型的交互入口。btw-controller.ts 在用户发起旁路提问后用btwUserPrompt模板渲染问题文本调用runEphemeralTurn({ promptText, onTextDelta, signal })把流式增量直接渲染到BtwPanelComponent面板完成后标记面板完成、可一键复制答案到剪贴板并支持 AbortSignal 取消。关键体验是提问时主任务仍在跑。由于侧信道回合不阻塞、不写历史用户可以在 Agent 忙于工具调用时顺口一问得到答案后主任务不受任何影响。/omfgOmfgController与/btw共享同一套快照 流式管线差异只在触发方式与 UI 呈现。此外event-controller.ts 中的 idle recap空闲复盘也使用瞬时侧信道回合生成。四、场景二IRC 自动回复与等待语义侧信道机制的另一大应用是 IRC 协作。配套提示词 irc-incoming.md 描述了模型在收到 IRC 消息时的三种回应策略通过 Handlebars 条件分支注入已自动回复autoReplied任务中途时系统已代表 agent 生成了侧信道自动回复并记录在消息之后模型如需纠正只能通过hub工具op: send、to: {{from}}补发停止时转发relayOnStop若回复在停止时可用则通过hub发送否则本回合最后yield或收尾说的话会在停止时送达对方默认策略需要回复时通过hubop: send发送允许先完成当前步骤且无人代为回复。在 irc/bus.ts 中注释明确指出这套设计取代了旧的自动回复模型send永远不会阻塞接收方任务中途的入站消息可以由上下文即时生成一个侧信道自动回复。更微妙的是超时语义irc/bus.tspeer 的agent_end事件是已停止的权威信号但侧信道自动回复可能比主回合活得久因此等待逻辑先等session.waitForIrcReplies()清空在途回复再宣告 peer 停止空回复或失败回复则自然落入干净的停止结果。这套等待/追讨逻辑归属 irc-bridge.ts侧信道回复以irc:autoreply类型经 hub/messaging.ts 送达而 handoff会话交接同样依赖runEphemeralTurn见 session-handoff.ts。五、旁路帧RPC 层的插队通道侧信道并不仅指 LLM 推理回合还包含 RPC 输入流中的控制帧插队。在 rpc-mode.ts 中dispatchRpcControlFrame的注释直接写道Dispatch side-channel frames that must overtake the serialized command queue.分发必须超越串行命令队列的侧信道帧。这类帧包括extension_ui_response扩展 UI 的响应帧按 id 立即 resolve 挂起的扩展请求host_tool_result / host_tool_update宿主机工具的结果与进度host_uri_result宿主机 URI 回调结果。它们之所以能插队是因为 rpc-mode.ts 的 stdin 读取循环保持持续向前即使一个长耗时的bash命令还在后台执行后续的abort_bash与侧信道帧也能被即时读取并分发。这与 LLM 侧的侧信道回合在精神上一脉相承——高优先级旁路流量不排队、不阻塞、不污染主线。六、设计权衡小结为什么需要一套无工具的旁路综合提示词与源码可以总结出侧信道回合的四点设计动机不打断主任务旁路回合与在途主回合并行不阻塞工具调用也不被主回合阻塞——这是/btw能在 Agent 干活时插话的前提不污染会话历史与持久化状态只读快照用完即弃避免旁路问答误写上下文、影响主任务后续决策保缓存、零浪费工具目录照发只为维持 prompt cache 命中配合稳定promptCacheKey让旁路回合以最低推理成本复用主回合的上下文窗口双保险禁用工具提示词明令 sanitize 阶段物理过滤toolCall块保证旁路回复永远是纯文本、可预测、无副作用。这套机制的价值在于把闲聊式提问从任务执行中彻底解耦模型可以在两个并发上下文中分别扮演执行者与应答者而共享同一份对话记忆。如果你打算基于 oh-my-pi 开发自定义扩展或研究 Agent 内部调度side-channel-no-tools.md、agent-session.ts 与 irc-incoming.md 三份文件构成了一条完整可追踪的阅读线索从提示词约束到执行管线再到 IRC 侧的具体落地。【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/11 13:39:36 · 阅读 1.2k oh-my-pi 瞬时侧信道回合机制：side-channel-no-tools 系统提示词与无工具问答管线解析
oh-my-pi 瞬时侧信道回合机制side-channel-no-tools 系统提示词与无工具问答管线解析【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi导读本文聚焦 oh-my-picoding agent内部一套鲜为人知但至关重要的机制——瞬时侧信道回合Ephemeral Side-Channel Turn。它以 side-channel-no-tools.md 这份系统提示词为行为约束支撑着/btw、/omfg、IRC 自动回复、会话交接handoff等不打断主任务的旁路问答能力。读完本文你将理解这套提示词每一行的设计意图、它在 agent-session.ts 中的完整执行管线快照构建、prompt cache 保持、工具调用丢弃、响应去重以及它在 IRC 总线与 RPC 控制帧两个场景下的落地方式。一、先看文档本身五行的铁律side-channel-no-tools.md全文只有五句话属于系统级system-remindersystem-reminder Ephemeral side-channel turn; reuses current conversation context. Tool catalog attached only to keep prompt cache warm; tools NOT available this turn. Do NOT emit tool calls; reply plain text only. Tool calls discarded without execution. /system-reminder逐句拆解它同时立下了四条约束瞬时Ephemeral这是一个用完即弃的回合不写入会话历史、不修改任何持久化状态复用当前上下文reuses current conversation context模型看到的是与主回合一致的会话快照因此能基于进行中的任务给出上下文相关的旁路回答工具目录仅供暖缓存keep prompt cache warm工具目录照常附上但仅供保持 provider 侧 prompt cache 命中本回合不真正可用严禁工具调用Do NOT emit tool calls即使模型误发工具调用也会被丢弃且不执行本回合只能输出纯文本。正是这份只有约束、没有业务逻辑的提示词被注入到每次侧信道回合的上下文末尾与模型当前 system prompt 共同决定模型的旁路行为。它本身几乎不包含逻辑真正的工程实现全部落在宿主代码中——这正是本文后续要展开的部分。二、宿主实现runEphemeralTurn与瞬时快照构建2.1 入口一次只读的并行推理在 agent-session.ts 中runEphemeralTurn是侧信道回合的统一入口其 JSDoc 精确描述了设计契约Run a single ephemeral side-channel turn against this sessions current model system prompt history. The main turns tool catalog is sent to preserve the prompt cache, but the model is reminded not to call tools and any tool calls are discarded. The side request does not block on, or interfere with, any in-flight main turn. The sessions history and persisted state are NOT modified by this call.这段注释直接呼应了提示词中的每一行主回合的工具目录照发但只用于保缓存对应第 2 句、工具调用被丢弃对应第 4 句、不阻塞也不干扰进行中的主回合、不改写历史与持久化状态对应第 1 句瞬时。从调用链看BtwController/btw与OmfgController/omfg共享这套快照 流式管线见 btw-controller.ts而sdk.ts中的注释则把侧信道请求的家族完整列出/btw、/omfg、IRC 自动回复、handoff见 sdk.ts。2.2 快照构建把半成品回答也喂给模型#buildEphemeralSnapshotagent-session.ts负责组装本次旁路回合的输入消息逻辑分三步深拷贝当前消息列表保证后续追加不污染真实会话合并正在流式输出的主回合回答如果streaming.role assistant且内容非空则把其中的thinking块与已输出的文本块提取出来替换掉消息列表中最后一条 assistant 消息或追加一条。这样模型在旁路问答时能看到主回合写到一半的内容而不是对缺失上下文做猜测。实现中还特意保留 thinking 块注释指出 DeepSeek 系编码器会把它们重放为reasoning_content一旦缺失就会直接 HTTP 400 拒绝请求依次追加两条虚拟消息role: developer的消息内容正是sideChannelNoToolsReminder该提示词文件通过with { type: text }以文本形式导入见 agent-session.tsrole: user的消息内容为本次旁路请求的实际 prompt 文本。2.3 Provider 会话与缓存独立血统、共享缓存键流式选项中有两处精心设计agent-session.tssessionId: \${cacheSessionId}:side:${Snowflake.next()}——旁路回合使用**独立请求血统**不共享 OpenAI/Codex 那种 append-only 的会话状态因为 IRC 与/btw 可能在主回合调用工具中途并行发起同时每次生成唯一后缀避免不同旁路回合互相污染promptCacheKey保持与主会话一致——prompt cache 键稳定才能让旁路回合命中主回合已经建立好的缓存这也是提示词第 2 句保持缓存温暖的代码落点。注释还补充了一个细节共享的providerSessionState映射仍然必须传入因为 Codex 需要在侧信道 session id 下分配 websocket 状态。2.4 响应收尾净化、去重与降级runEphemeralTurn对流式事件的收尾同样值得细读text_delta 实时转发通过onTextDelta回调把增量文本推给 UI如/btw面板逐字渲染并配合#deobfuscatedProviderTextReadyForDelta做机密脱敏后再外发done 事件健壮性Array.isArray(event.message.content) ? event.message.content : []——自定义扩展 provider 或 gateway 包装的 OAuth 流issue #4323可能把content字段丢弃或替换为undefined此处归一化为空数组让复盘回合显示空回复而非把一次畸形旁路响应升级成会话静默崩溃工具调用强制剔除content.filter(block block.type ! toolCall)——即使模型违反提示词发了工具调用也会在 sanitize 阶段被物理删除与提示词第 4 句Tool calls discarded without execution双重呼应回复去重默认经dedupeEphemeralReply折叠退化重复行并限制长度见 messages.ts只有调用方显式传dedupeReply: false时才返回原文。三、场景一/btw与/omfg瞬时问答/btw是侧信道机制最典型的交互入口。btw-controller.ts 在用户发起旁路提问后用btwUserPrompt模板渲染问题文本调用runEphemeralTurn({ promptText, onTextDelta, signal })把流式增量直接渲染到BtwPanelComponent面板完成后标记面板完成、可一键复制答案到剪贴板并支持 AbortSignal 取消。关键体验是提问时主任务仍在跑。由于侧信道回合不阻塞、不写历史用户可以在 Agent 忙于工具调用时顺口一问得到答案后主任务不受任何影响。/omfgOmfgController与/btw共享同一套快照 流式管线差异只在触发方式与 UI 呈现。此外event-controller.ts 中的 idle recap空闲复盘也使用瞬时侧信道回合生成。四、场景二IRC 自动回复与等待语义侧信道机制的另一大应用是 IRC 协作。配套提示词 irc-incoming.md 描述了模型在收到 IRC 消息时的三种回应策略通过 Handlebars 条件分支注入已自动回复autoReplied任务中途时系统已代表 agent 生成了侧信道自动回复并记录在消息之后模型如需纠正只能通过hub工具op: send、to: {{from}}补发停止时转发relayOnStop若回复在停止时可用则通过hub发送否则本回合最后yield或收尾说的话会在停止时送达对方默认策略需要回复时通过hubop: send发送允许先完成当前步骤且无人代为回复。在 irc/bus.ts 中注释明确指出这套设计取代了旧的自动回复模型send永远不会阻塞接收方任务中途的入站消息可以由上下文即时生成一个侧信道自动回复。更微妙的是超时语义irc/bus.tspeer 的agent_end事件是已停止的权威信号但侧信道自动回复可能比主回合活得久因此等待逻辑先等session.waitForIrcReplies()清空在途回复再宣告 peer 停止空回复或失败回复则自然落入干净的停止结果。这套等待/追讨逻辑归属 irc-bridge.ts侧信道回复以irc:autoreply类型经 hub/messaging.ts 送达而 handoff会话交接同样依赖runEphemeralTurn见 session-handoff.ts。五、旁路帧RPC 层的插队通道侧信道并不仅指 LLM 推理回合还包含 RPC 输入流中的控制帧插队。在 rpc-mode.ts 中dispatchRpcControlFrame的注释直接写道Dispatch side-channel frames that must overtake the serialized command queue.分发必须超越串行命令队列的侧信道帧。这类帧包括extension_ui_response扩展 UI 的响应帧按 id 立即 resolve 挂起的扩展请求host_tool_result / host_tool_update宿主机工具的结果与进度host_uri_result宿主机 URI 回调结果。它们之所以能插队是因为 rpc-mode.ts 的 stdin 读取循环保持持续向前即使一个长耗时的bash命令还在后台执行后续的abort_bash与侧信道帧也能被即时读取并分发。这与 LLM 侧的侧信道回合在精神上一脉相承——高优先级旁路流量不排队、不阻塞、不污染主线。六、设计权衡小结为什么需要一套无工具的旁路综合提示词与源码可以总结出侧信道回合的四点设计动机不打断主任务旁路回合与在途主回合并行不阻塞工具调用也不被主回合阻塞——这是/btw能在 Agent 干活时插话的前提不污染会话历史与持久化状态只读快照用完即弃避免旁路问答误写上下文、影响主任务后续决策保缓存、零浪费工具目录照发只为维持 prompt cache 命中配合稳定promptCacheKey让旁路回合以最低推理成本复用主回合的上下文窗口双保险禁用工具提示词明令 sanitize 阶段物理过滤toolCall块保证旁路回复永远是纯文本、可预测、无副作用。这套机制的价值在于把闲聊式提问从任务执行中彻底解耦模型可以在两个并发上下文中分别扮演执行者与应答者而共享同一份对话记忆。如果你打算基于 oh-my-pi 开发自定义扩展或研究 Agent 内部调度side-channel-no-tools.md、agent-session.ts 与 irc-incoming.md 三份文件构成了一条完整可追踪的阅读线索从提示词约束到执行管线再到 IRC 侧的具体落地。【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考