perf: 1.9.7 WorkBuddy 制作 11 页 PPT 耗时 53 分钟的端到端分析与改进建议 #65

结论

2026-11-12 的一次 WorkBuddy 实测：用户只要求“使用最新版本的 deckuse 制作一个 PPT 介绍武功山风景”，从请求到最终回复 53m06.230s，文件交付工具返回在 52m48.575s。日志确认安装并运行的是 @deckflow/deckuse 1.9.7 community，当次 npm 查询的 latest 也是 1.9.7。

主要瓶颈是端到端工作流：长时间的发现/外部等待、宿主临时文件策略冲突、预览失败后的自制预览器及修复循环、局部修改触发全量重建。没有证据说明 Deckuse 的单次 PPTX 写入耗费了 50 分钟。 首次正式 233 条操作的 apply 调用区间约 22.3s；后面两个完整重建脚本调用分别为 56.7s、54.0s。

另一个重要结果：最终交付有结构校验，但没有成功的 Deckuse 渲染或原生 PowerPoint 视觉验证。额外耗时没有换来可确认的原生排版质量。

数据范围与计时方法

• 对用户提供的一份 JSONL 全量分析：353 条事件，128 次工具调用与 128 条配对结果，无未匹配调用；61 次 Bash、19 次 ViewImage、14 次 Edit、10 次 Write。
• 以下 L<n> 指原始 JSONL 的一基行号，T+ 为相对初始用户请求的时间。公开 issue 不附原始对话、账户标识、个人目录及图片 blob 引用。
• 对所有 call→result 时间区间取并集，得到 23m48.903s（44.8%）；其余 **29m17.327s（55.2%）**没有被工具区间覆盖。后者可包含模型思考/输出、宿主调度和未记录活动，不能称为纯模型推理耗时或用户审批等待。
• 直接累加调用时长会得到 52m42.092s，因并发/批量回传重复计算，不可作为真实工具用时。
• 使用仓库现有 scripts/agent-log-analysis.mjs 复核总量，并人工检查命令及结果。其 firstOperations 命中的是图片测试用的 probe-ops.json，不是正式 11 页初稿；里程碑必须区分探针和真实交付。
• 附件只有日志及部分工具文本，没有最终 PPTX、图片 blob、完整运行工作区；本报告不声称复现了原生渲染，也不把日志中的“视觉检查通过”当成独立验收。

无重叠阶段时间线

阶段是墙钟分段，不等于各项都可以消除。素材研究、设计和必要质量检查本身有价值。

原因与证据

1. 外部发现与批量回传形成两个大等待段（约 13m03s，24.6%）

• L16–L21：npm view @deckflow/deckuse ...; npm view deckuse ...、获取完整 README、景点 WebSearch 同批执行；三个结果在几乎同一时刻回传，区间 553.3s（T+46.9→600.2）。
• L62–L67：本地 Grep、Wikimedia WebFetch、render preflight 同批，区间 229.9s（T+896.6→1126.4），结果也集中回传。
• 无法据此断言 npm 单独慢了九分钟，或 render preflight 慢了四分钟。日志缺少单工具实际进程完成时间；慢外部调用或宿主批次屏障都可能拖住独立结果。
• 安装前先搜索工具、抓完整 README、查询已废弃无作用域包；安装后虽成功使用 skill-path（L35）并读取随包 Skill（L39），仍多次跨 examples/schema/docs 搜索图片字段（L46/L54/L62/L71），再建立 probe workspace。
• 安装使用新建任务内 .npm-cache，且运行 audit/fund/update notifier；这些是冷启动成本的可能放大项，但没有子阶段计时，不能量化各自占比。

改善： 复用已验证 CLI；需要 latest 时仅解析 canonical scoped 包一次并固定版本；优先已有受限时 bootstrap。给网络工具明确超时与有限重试；不要让本地 contract/preflight 等待研究类工具整批返回。宿主记录独立 start/process-end/returned 时间。为高频“图片+标题+正文”提供紧凑且字段完整的 recipe，避免再建图片格式探针。

2. 宿主删除限制同时影响 shell/Python 和渲染器；不能全部归咎于 Deckuse 写入

• 43/128 条工具结果包含 Blocked by Security Center rules，涉及 shell 临时文件、Python 临时目录探测、浏览器 preflight probe 和 .NET 解包临时文件。这是“含拒绝的结果数”，不是 43 次用户审批，也不是 43 个 Deckuse 失败。
• L70/L75/L78：下载与建目录遇到临时文件删除拒绝，后续又因 assets 目录不存在失败。L81 的 Python 输出 No usable temporary directory found，随后仍打印 True。
• L124：Deckuse apply 已返回 ok:true、mutationState:committed，其锁/transaction 清理已采用 .deckuse-trash 退休路径；宿主仍追加 shell 临时文件删除拒绝。因此不能建议简单重放整个写入，也不能把这些错误当成 Deckuse 锁清理仍未修复。
• L146 在 T+25:58 读到明确 RENDER_CONVERTER_EXTRACTION_FAILED、stage:converter-extraction、retryable:false、launch:not-probed。这里尚未走到浏览器启动，不能诊断为“缺 Chrome”。
• 共 5 次 preflight 调用尝试（L64/L132/L135/L143/L224；不保证每次都启动了 CLI）。最后一次 L224 在明确不可重试之后又换 DOTNET_BUNDLE_EXTRACT_BASE_DIR，再次遭 .NET 临时文件删除拒绝。改变路径不是已证实的宿主能力修复。

改善： 宿主把策略拒绝作为结构化、可区分的结果返回，分别表达“命令主体成功”“包装器/清理失败”“预览被阻止”；协调宿主提供经批准的临时文件生命周期。Deckuse 一次失败后输出可直接执行的停止/结构交付状态，直到宿主能力实际改变才恢复预览。不可通过换语言、改路径或其它等价操作绕过拒绝。

3. 预览失败后自行实现渲染器，新增了第二套待调试的软件

• L228 写了约 6.1KB preview_from_pptx.py，用 python-pptx + Pillow 读取真实 PPTX 后重新绘图。输入是真的 PPTX，文本排版实现仍不是 PowerPoint 或 Deckuse 渲染器。
• 初版对 TEXT_BOX 查询 auto_shape_type，异常被外层吞掉，导致有填充的背景/卡片不绘制；L237 读对象确认，L240 修复。
• 初版虽定义了逐字 wrap 函数，实际文本绘制没有使用；单个长 run 不按文字框宽度拆分。后续看到的部分“文案溢出”可能来自此实现，不能直接证明原始 PPTX 存在同样问题。
• PPTX 使用 Microsoft YaHei；自制预览器却从 Hiragino Sans GB / Arial Unicode / STHeiti 选字体，并用自定行高、固定边距。据此调整中文孤字/句号不能保证 PowerPoint 中一致。
• L267 为预览器补换行时引入顶层 nonlocal；L287 输出 SyntaxError: no binding for nonlocal 'cur_items' found，L292/L294/L297/L299 又读代码、修脚本、重跑。
• 19 次 ViewImage 中前 5 次为素材检查，其余 14 次为自制预览。日志仅保留 blob 引用，不能据此独立确认每张图的质量。

改善： 默认禁止为完成交付临时开发替代排版引擎。host-blocked 时交付“结构已验证、视觉待验证”的 PPTX，或在已有授权且确实可用的宿主渲染能力上继续。静态布局示意图必须标明来源和局限，不可驱动字体相关的高置信度自动修复。优先完善正式渲染链在受管环境中的可部署性。

4. 小范围润色触发三次完整重建，缺少结束条件

• 初稿后因为导览卡片、页脚、局部文案等修改，依次建立 workspace-v2、workspace-final、workspace-release，正式生成共 4 次，另有图片探针 workspace。
• 第二轮重建的 new/apply/validate/export 单项调用区间合计约 61.7s；后两次整套脚本为 56.7s + 54.0s。即三次额外重建至少占据约 172.4s 已记录工具区间，再叠加决策、改脚本、结果读取和预览。
• L313 T+47:31 开始“句号独占一行”的最终润色；L328 T+50:01 又处理孤字。到 L339 T+51:46 最后看图返回，这段约 4m15s，仍基于非真实字体排版，且不意味着全段都是无价值工作。
• 源码里的增量 patch 能力和 Skill 的“批量收集问题后一次修正”“孤字提示不是单独阻塞条件”都已经存在；本例没有采用。

改善： 局部修改使用 revision-guarded patch，只重验受影响页；原始作者脚本同步修改或保留 base+patch 配方来保证可重建。首轮收集全部有证据的缺陷后集中修复；设定默认润色轮次/预算，单纯美观建议不能无限延迟交付，真实缺失/遮挡/越界仍须处理或明确报告。

5. 进程结果被管道掩盖，增加读结果和误判成本

• 很多命令使用 2>&1 | grep ... | tail ...；L287 的 Python 已 SyntaxError，宿主仍显示 Exit Code: 0，因为记录的是管道尾部结果。
• 多次把 CLI JSON 重定向后，再下一轮启动 Python 读取关键字段（例如 L187/L189→L191，L195/L196→L199，L277→L279，L282→L284），额外增加模型往返。
• 原始 Skill 已要求分开捕获 stdout/stderr、检查退出码与 JSON，并推荐 bundled generation runner，但直到 T+47:56 才开始自写 finalize.py。

改善： 直接采用现有受保护 runner；统一返回紧凑 phase/status/revision/artifact/nextAction，完整 stdout/stderr 留在报告。任何过滤输出都必须保留原进程退出码；测试覆盖“工具包装器返回 0，但子进程失败/策略拒绝”的情况。

6. 文档存在，但执行约束未进入运行路径

日志 L39/L47 已读到随 1.9.7 分发的规则：不再写自定义检查器、优先 bundled runner、局部改动使用 patch、不可重试就停止、受限时保留结构交付。然而后续仍反复偏离。

因此本报告不是要求重新添加已存在的 skill-path、bootstrap、retryable:false、runner 或增量渲染。应提高已有默认路径的可执行性：输出结构化状态和下一步，减少需要 agent 从长文中自行选择的分支，并用真实宿主回归验证实际采用率。

与代码和已有工作的对应

核对仓库 commit e2798d229f45a7f1f653cc34faf1652959bd184a，同时以日志中实际读取的随包文档为准：

• render-browser.ts：临时 probe 写入/递归删除；已有清理失败分类。应与宿主能力协商，不能承诺任意禁止删除环境都支持渲染。
• deck2html-exec.ts：已有解包错误分类及不可重试提示；日志证明分类生效，缺的是被正确遵循的停止分支。
• managed-bootstrap.sh：已有 30s 版本解析、180s 安装上限及 audit/fund/notifier 控制，本例没有使用。
• create.md：已有 runner、patch、预览阻止交付状态和恢复流程。
• timing.ts：已有 DECKUSE_TIMINGS_FILE；本附件没有对应内部计时文件，不能把宿主调用时间当作引擎 CPU 时间。

关联 #23、#30（端到端基准），#15、#20、#34（预检），#29、#37（安装/发现），#36（诊断），#64（默认生成/验证流程）。这是 1.9.7 实测未收敛的综合现场报告，不是重复宣称这些能力尚未实现。

建议优先级与可验收条件

P0：让失败分支可靠终止，保留真实交付状态

• 在受管宿主测出临时文件/解包生命周期兼容矩阵；分别报告 CLI 提交、包装器清理、转换器启动、浏览器启动的状态。
• retryable:false 或宿主拒绝后，未确认能力变化时不再做等价预览尝试；转入结构交付或明确的视觉阻塞状态，不新写预览引擎。
• 给宿主适配器增加拒绝/退出码冲突 fixture；已 committed 的写入不因清理拒绝重放。
• 预览失败/字体替换时，产物报告明确区分 structure / preview / visual-review / native-review。不得把静态重绘标记为原生视觉通过。

P1：缩短默认成功路径和小修路径

• 一条已安装 CLI→随包 Skill→compact recipe→guarded runner 路径，不重新搜索 README/旧 alias；版本查询与外部研究不共用阻塞回传批次。
• 为图片型简介提供最小可执行 recipe；构建结果直接返回紧凑摘要，减少重定向后下一轮读结果。
• 基于本次 11 页 fixture，局部两页修改走一个 guarded patch；受影响页定向复验，默认不再完整 new→apply→validate→export 三遍。
• 素材下载保留许可来源、缓存、真实客户端标识、429 退避和明确时间预算；不要求把全部候选图片下载齐才能开始设计。
• 作者源与补丁可复现；排版调整不删除事实限定词，不通过不可信字体替代预览不断压缩文案。

P1：补齐实测和归因，避免“引擎快所以端到端快”

• 同一固定简报在指定 WorkBuddy 版本跑至少 3 次冷启动、3 次热启动；另设预置素材对照及预览拒绝场景。记录实际模型/宿主/CLI/转换器/字体/浏览器配置。
• 分别记录首次正式 operations、首次验证导出、真实视觉完成、文件交付；探针 workspace 不计为首次交付里程碑。
• 同时保留工具区间并集、未归因时间、每进程实际结束时间、Deckuse 内部 timing；报告批量回传歧义，不猜测 npm 或模型单项耗时。
• 统计全量重建、局部 patch、预览器自写次数、不可重试后的重复尝试、含策略拒绝的结果数；后者与人工审批次数分别计数。
• 延续 acceptance: Run the five-minute, zero-delete-prompt benchmark in a managed host #30 的热路径五分钟目标作为待验证目标，公布单次结果和通过率；preview-blocked 单独报告，不能算 reviewed success。本次数据不足以保证某项改动就能把 53 分钟降到五分钟。

可量化的优化空间与限制

最值得优先验证的是两个大批次等待窗口（13m03s）、首次导出后的尾段（17m04s）、其中三次额外全量重建的调用窗口（约 2m52s）。这些不是可直接相加的节省承诺：重建包含在尾段内，尾段也包含必要复核；外部等待还缺少独立完成时间。真正需要减少的是阻塞和无可靠证据的返工，同时保留必要验证，而非只降低单次 apply 的毫秒数。