oh-my-piomp cleanse迟到诊断注入机制follow-up 提示如何让修复 Agent 在收尾前补齐剩余问题【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi本篇文章围绕 oh-my-pi⌥ Coding agent with the IDE wired in的自动修复命令omp cleanse展开聚焦其核心 Prompt 文件 follow-up.md 所定义的迟到诊断late diagnostics注入机制当正在运行的修复子代理repair worker专属文件出现了新诊断时编排器如何通过聊天消息将其推送给该子代理并要求其在收尾yielding前一并修复。读完本文你将理解这套流式诊断 → 文件粘性所有权 → 迟到诊断聊天注入 → 失败重排队的完整闭环以及它与子代理工作提示assignment、诊断采集checkers、主循环loop之间的协作方式。一、follow-up 提示要解决的问题omp cleanse的整体流程是先由检查器checker流式产出诊断再按文件分组后分发给多个修复子代理并行修复最后做一次验证verify扫描确认是否干净。其核心难点在于检查器是边运行边输出的修复子代理可能已经启动而此时检查器又输出了它专属文件上的新诊断。follow-up.md 全文如下Additional diagnostics were reported for files you own. Fix these too before yielding: {{diagnostics}}翻译过来即在你所拥有的文件上又报告了额外的诊断。请在收尾之前一并修复这些诊断。其中{{diagnostics}}是模板变量运行时由渲染器替换为实际诊断列表。这段 Prompt 不是静态提示而是通过进程内消息总线IrcBus被注入到正在运行的子代理聊天中成为一条新的用户消息让子代理在结束前处理掉新增问题。二、这条提示在 cleanse 编排中的位置follow-up 机制是 cleanse 三大提示协作的一部分三者都位于 prompts 目录提示文件角色注入时机discovery.md检查器发现把用户诉求翻译成可运行的 checker 命令argv 数组 cwd parser一轮 cleanse 开始时assignment.md工作分派告诉某个修复子代理它负责哪些文件、哪些诊断、写入范围、并发对等方每次分发 worker 时follow-up.md迟到诊断注入让 worker 修复其专属文件的新增诊断worker 运行期间新诊断到达时其中 assignment.md 第 11 行就预先告知了 workerFurther diagnostics for your files may arrive as chat messages while you work; fix those too before yielding.你文件的更多诊断可能在你工作期间以聊天消息形式到达收尾前也修复它们——follow-up 正是这句话的运行时兑现。三、源码级实现诊断如何追上正在运行的 Agent3.1 渲染与发送CleanseAgentRuntime.followUp在 agent.ts 中运行时实现了followUp(worker, diagnostics)方法async followUp(worker: number, diagnostics: readonly CleanseDiagnostic[]): Promiseboolean { const agentId workerAgentIds.get(worker); if (!agentId) return false; const receipt await IrcBus.global().send({ from: MAIN_AGENT_ID, to: agentId, body: prompt.render(followUpPrompt, { diagnostics: formatDiagnostics(diagnostics) }), }); if (receipt.outcome failed) return false; sessionManager.appendCustomEntry(cleanse_follow_up, { worker, count: diagnostics.length }); return true; }关键细节worker → agent id 映射workerAgentIds是Mapnumber, string在dispatchWorker分发时通过reserveStructuredSubagentId登记worker 结束时在finally中删除。若 worker 尚未注册或已结束followUp直接返回false表示无法投递。通过 IrcBus 发送消息体是渲染后的follow-up.md模板{{diagnostics}}由formatDiagnostics生成见下。发送失败receipt.outcome failed也返回false。会话留痕每次成功注入都会写入cleanse_follow_up会话条目记录 worker 编号与诊断数量。formatDiagnosticsagent.ts把诊断结构化为- [severity] file:line:col — checker code: message格式并附上可选的Suggested fix:建议单条消息正文被截断在MAX_DIAGNOSTIC_MESSAGE 4_000字符以内避免消息过长。3.2 路由决策粘性所有权与 held 队列真正决定哪些诊断走 follow-up的是主循环 loop.ts。每个文件在分发时与某个 worker 绑定sticky保证两个 worker 永远不会并发编辑同一文件。route函数loop.ts对每条新诊断做分流const route (diagnostic: CleanseDiagnostic, touched: SetOwnerEntry): void { const fileKey diagnostic.file ?? ; const entry owned.get(fileKey); if (entry) { entry.held.push(diagnostic); // 该文件已有 worker 在改 → 走 follow-up touched.add(entry); return; } // 否则进入 pending 队列等待空闲 worker 承接 const queued pending.get(fileKey); if (queued) queued.push(diagnostic); else pending.set(fileKey, [diagnostic]); };即文件键fileKey一旦被某个在飞的 worker 拥有owned后续到达的所有诊断先进入该 worker 的held缓冲等待被注入聊天未被拥有的文件诊断则进pending排队由后续 worker 承接。trySendloop.ts负责把 held 诊断投递出去并保证每个 worker 同时只有一个在途发送批投递成功继续处理该 worker 剩余的 held 诊断投递失败且 worker 仍在运行诊断被重新放回held头部entry.held.unshift(...batch)等待下次触碰或释放时重试投递失败且 worker 已释放entry.released诊断被重新route回pending由新的 worker 重新接手——注释中明确说明此时这些诊断可能已被修复新 worker 会验证并无操作。四、投递失败时的重排队闭环兜底在 loop.ts 的launch与 worker 完成逻辑中可以看到完整的兜底链路worker 结束done时设置entry.released true从owned中删除其文件键将entry.held中尚未投递的残留诊断取出并重新route此时所有权已释放自然落入pending触发pump()只要有空闲槽位就为这些诊断启动新的 worker。而文档级注释也明确了不变量每条诊断最多被分发一次最终由验证verify阶段判定是否 clean。runCleanseLoop的结尾逻辑loop.ts在验证报告diagnostics.length 0时返回clean否则返回stalled随后由 index.ts 映射为 CLI 退出码clean → 0unresolved → 1。五、从 CLI 到状态的完整调用链omp cleanse的入口在 index.ts主要参数与默认值如下参数默认值说明--agents/maxAgents32并发修复子代理上限必须为正整数否则抛错--modelsmol驱动 cleanse 子代理的模型选择--include-tests关闭额外启用测试类检查器cargo test、pytest、go test 等--request无绕过内置检查器发现直接把自由文本交给发现子代理生成自定义 checker--all关闭跳过交互式选择器直接运行所有发现的检查器调用链为runCleanseCommand注册 SIGINT/SIGTERM 取消→runCleanse发现检查器/选择目标→runCleanseLoop流式采集 分发 验证→dispatchWorker渲染 assignment 提示启动修复子代理→followUp注入 follow-up 提示。测试覆盖位于 cleanse.test.ts其中明确断言了迟到诊断被投递给正在运行的 worker 1以及投递失败时诊断被重新排队给新 worker两条关键行为。六、运行效果与设计取舍减少重复劳动迟到诊断直接进入当前 owner 的聊天worker 可在同一轮里一并修完而不是等文件释放后另起一个 worker 重新加载上下文。避免编辑冲突文件粘性所有权保证 follow-up 只发给唯一 owner杜绝并发写同一文件。不阻塞、不丢诊断投递是异步批量的每 worker 单批在途投递失败或 worker 已结束时诊断自动退回 pending 重排队验证阶段兜底判断最终是否 clean。子代理侧约束收到 follow-up 消息的 worker 仍受 assignment.md 中的critical规则约束——必须在写入范围内修复根因、不得压制有效诊断、不得越权编辑 peer 拥有的文件。七、小结follow-up.md 虽然只有两行却是omp cleanse并行修复可靠性的关键拼图它与 assignment.md、discovery.md 一起构成 cleanse 的提示体系由 agent.ts 负责渲染与通过 IrcBus 投递由 loop.ts 负责粘性路由、批量在途与失败重排队。理解了这一机制你就掌握了如何在多 Agent 并行修复时把不断产生的诊断稳定地送达正在工作的 Agent这一可复用的工程范式。如需深入可继续阅读agent.ts、loop.ts、checkers.ts、types.ts 以及测试文件 cleanse.test.ts。【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
