长期项：视觉校验把整张预览图读进上下文——约 29s/次代价，根因在上游 deepagents

## 根因（来自 #3421 的排查，实测 SHA `866d29b53`）

PPTX 生成时 `visualInspection=required`，模型渲染每页 PNG 后 `read_file` 读回校验；`read_file` 对 PNG **返回整张图的 base64**，5 页合计 32–88 万字符**进上下文，此后每轮都带着**。

**量化**：同 run 内模型轮次耗时 **1.80s (n=80) → 7.57s (n=50)，4.2 倍**，10 个 run 全部同向（2.8–5.8×）。⇒ 约 **29 秒/次**，长尾更多。

## 为什么不在 #3421 里修

图片块的构造在**上游 deepagents**：`native_file_delegation.py:44` 自述「image blocks ... remain upstream」——不在本仓代码范围内，需要单独设计（例如低 DPI 另渲一套用于校验、或校验后从上下文里裁掉、或改用摘要而非整图）。

## 已知可能的方向（未评估代价，不要直接实现）

- `render-office.py` 的渲染 DPI 现写死 `-r 96`（仅 ~2s），也许可以另渲一套**更低 DPI 的校验专用图**，交付仍用 96 DPI。
- 校验完成后**主动从上下文裁掉**已读入的图片块（若上游/框架支持）。
- 改视觉校验为**结构性校验**（例如检查文件大小、页数、OOXML 结构）而非整图视觉审查——但这会削弱「模型真的看过渲染结果」这个能力，需要产品判断。

## 要求

- **先设计再实现**：这是跨 `apps/deep-agent-service` 与上游 `deepagents` 的改动，先给出方案 + 代价 + 取舍，不要直接写代码。
- 若方案涉及降低视觉校验的严格程度，**必须说明对正确性的影响**并给候选方案+推荐，不要抛开放性问题。
- 修复后判据落在**端到端耗时**，并给可复现测量命令；#3421 里的仪器 `apps/api/tests/agent-runtime/pdf-perf-measure.live.ts` 已支持 `WX_PDF_PERF_PROMPT`，测 PPTX **不需要改代码**，可直接复用。

## 相关

#3421（PPTX 性能，已定位此根因但未修，因超出该 issue 范围）、#3401/#3406（PDF 性能，同族但不同机制——那次是脚本试错，这次是上下文膨胀）。

Start with native_file_delegation.py:44 in upstream deepagents and the render-office.py rendering path to map how PNGs become image blocks. Review apps/api/tests/agent-runtime/pdf-perf-measure.live.ts and reuse WX_PDF_PERF_PROMPT for an end-to-end PPTX baseline. Done means a documented design with cost and correctness trade-offs, a recommendation, and a reproducible measurement command showing the performance impact.

Written by the indexing model from the issue text.