多智能体并行重建架构拆解image-to-editable-ppt-skill的page worker分派与并发控制设计【免费下载链接】image-to-editable-ppt-skillCodex skill for converting slide images, PDFs, and image-based PPTX files into editable PowerPoint decks.项目地址: https://gitcode.com/gh_mirrors/im/image-to-editable-ppt-skillimage-to-editable-ppt-skill是一个 Codex 技能能把幻灯片图片、PDF 和图片版 PPTX重建成对象级可编辑的 PowerPoint.pptx。它的核心卖点不是转一次而是多智能体并行重建主 agent 只做编排每一页交给独立的page worker并行重建再用一套文件化的租约状态机做并发控制。本文拆解它的 page worker 分派机制、并发槽位模型以及为什么慢 worker 不被重置是刻意设计。为什么需要多智能体单页重建的算力现实先看一个反直觉的事实复原一页 PPT 可能要 10 分钟以上一套 10 页的 deck 可能消耗掉整段 agent 额度。原因很简单——每一页都要跑一遍完整的视觉重建管线分离前景视觉资产、修背景、渲染公式、测文字几何、重建原生元素、逐对象自检。如果把 10 页串行跑完用户要等 100 分钟。而这套 skill 的答案是把页拆成独立的执行单元让多个 page worker 同时干活把总耗时压到ceil(总页数 / 并发槽位) × 单页耗时。分派模型主 agent 编排page worker 各管一页整个架构只有两种角色边界划得极死角色负责什么不能做什么主 agent父编排、用户交互、跑editppt状态命令、报告进度不能写任何页面产物manifest.json、page.pptx、preview.png 等page worker子只负责一个pages/page_NNN/目录从决策到自检全程独立不能碰其他页目录、deck 级状态、原始输入这套一页一目录一 owner的模型就是并发能安全成立的前提每个 worker 的写入范围互不重叠不需要文件锁。单页走本地多页才分派分派不是无条件的。editppt run next会先判断页数恰好 1 页→ 返回stagerebuild_page_locally。主 agent 用editppt run dispatch --local认领这一页然后自己按 page worker 的同一份 prompt 本地重建。没有子 agent 也照样能跑但走的是完全相同的 prompt、产物和校验路径。多页→ 返回stagedispatch_pages。主 agent 必须为每一页 spawn 一个 page worker。如果当前环境不支持子 agent 分派skill 明确要求停下来告诉用户而不是退化成父 agent 串行重建所有页——这是刻意的避免多页输入悄悄降级成串行。并发控制槽位模型与活跃租约槽位怎么算并发上限来自page_jobs.json里的max_concurrent_pages默认 6可以在editppt prepare时用--max-concurrent-pages N覆盖。核心公式只有一行见 deck_run_state.py可用槽位 max(0, max_concurrent_pages - 当前 dispatched 页数)只有statusdispatched的页才占槽位。pending待分派和recorded已验收都不占。editppt run next每轮就取可分派页 × 可用槽位的交集作为suggested_pages一次性建议一批。dispatched 是活跃租约不是空闲槽位这是整个设计里最容易被误读的一点值得单独说dispatched状态是一个活跃租约active lease不是一个空闲槽位。意思是一个 worker 一旦拿到某页这一页就锁给它哪怕它跑得很慢、很久没发消息也不能因为占着槽位不动就被终止、归档或换人。复杂页面合法地运行很久这套 skill 用两条硬规则防止父 agent 误杀run next返回stagewait时明确指示等待已分派 worker不要 reset 慢的活跃 workerrun reset对 dispatched 页有双重保护必须同时提供--confirm-lost标志且--agent-id与当初分派时记录的 worker id 完全一致否则直接报错拒绝。只有拿到终态证据terminated / failed / archived / not found、用户取消、或连续可达性检查失败才允许 reset。reset 之后该页回到pending重新走一遍分派流程。状态机五个状态只能沿命令推进页面生命周期只有五个状态且每次跃迁都必须通过editppt命令禁止手改状态 JSONpending → dispatched → recorded → accepted → complete ↑ │ └── run reset ┘ 需 --confirm-lost 匹配 agent-idpending由editppt prepare创建或由run reset恢复dispatched由run dispatch记录一个真实 spawn 的 worker或单页--local认领recorded由run record在校验通过后写入只有validation.json顶层passed: true的页才能到达accepted/complete由run finalize写入。校验门禁record 之前先验证失败页永不入册并发带来的风险是一个坏页污染整本 deck。skill 用editppt run record这道门禁堵住先跑validate_pptx.py把page.pptx对照manifest.json做确定性校验——缺定位对象坐标、manifest 无法独立重建页面、或validation.json没有顶层passed: true直接失败该页永不记录记录时强制agent-id 匹配record传入的--agent-id必须等于当初dispatch时写入的 worker id防止张冠李戴通过后把 7 个必需产物manifest.json、imagegen-jobs.json、page.pptx、preview.png、split_assets_contact.png、validation.json、page_result.json的路径与SHA-256 哈希一并写入page_jobs.json作为后续 finalize 的溯源锚点。页面内的图像任务imagegen、修背景、拆资产表虽然是页内串行的但页与页之间是并行的——页内串行 页间并行这是并发模型里最关键的粒度选择。状态如何驱动主 agentrun next是唯一方向盘父 agent 不自己判断下一步该干嘛而是反复调用editppt run next它读文件后返回一个明确的 stage 和 next_command返回 stage含义父 agent 该做什么configure_backend还没配图像后端先跑run backendrebuild_page_locally单页本地认领dispatch --local后自己重建dispatch_pages有可分派页 有空槽构建 prompt → spawn worker →run dispatchwait槽位被占或有页未完成等待只读run status观察不动状态finalize全部页 recorded跑run finalize组装终稿这种状态全在文件里、动作全靠命令的设计带来两个工程收益可恢复断点续跑只需重读page_jobs.json和确定性同一输入多次跑状态机行为一致。editppt run status则是纯只读检查器供调试或人工查看不参与调度。设计小结三个可借鉴的取舍把这套架构抽象出来其实是三个可复用的多智能体工程决策用目录边界替代文件锁。每个 worker 只写自己的pages/page_NNN/并发安全靠互不重叠的写入范围而不是分布式锁。用文件哈希做溯源。dispatch 记录 prompt 的 SHA-256record 记录全部产物的 SHA-256finalize 用 manifest 重建终稿并校验媒体哈希——每一步都可审计、可复现。把慢和死区分开。活跃租约默认不可打断reset 需要双重确认--confirm-lost 匹配 agent-id从根本上防止编排层把还在认真工作的 worker当成卡死的 worker清理掉。如果你想在更多页的大 deck 上跑把--max-concurrent-pages调大即可线性扩展如果环境不支持子 agent单页输入照样能走本地模式完成。理解这套 page worker 分派与并发控制是读懂image-to-editable-ppt-skill从能转到能稳定并行转的关键一步。【免费下载链接】image-to-editable-ppt-skillCodex skill for converting slide images, PDFs, and image-based PPTX files into editable PowerPoint decks.项目地址: https://gitcode.com/gh_mirrors/im/image-to-editable-ppt-skill创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考