调查: 产物对 xls/doc/ppt/pdf/图片的处理能力(无上传/无多模态)与改进方案

[EpisodeYu]

背景

真实工作中的资料多为 xls / doc / ppt / pdf / 图片。当前产物不支持文件上传、未做多模态模型适配。本 issue 记录一次实测调查:在"用户开启 desktop-commander 全部工具 + confirm: none(放行一切 tool 调用)"的前提下,产物能否处理这些文件(尤其是"自己调用 python 库处理"),以及表现不好时如何改进。

测试设置

• 产物:coding-assistant preset 生成,desktop-commander__* 通配全开,confirm: none。
• 模型:真实 MiMo mimo-v2.5-pro(OpenAI 兼容端点;key 走 .env,仅引用 env 变量名)。test-llm PASS。
• 环境:uv ✓、node v20 ✓;故意不预装 office 库(还原真实用户机器)。
• 测试文件含可验证"暗号" + 需计算的数字。
• 本次调查真实消耗 ≈ 141 万 token(其中约 132 万为 provider 缓存命中);cost=$0 仅因未配单价。

实测结果

文件	结果	抽取正确性	步数	该轮 token	实现路径
sales.xlsx	✅	North 总营收 4400、AUDIT_CODE 暗号	5	110k	DC read_file 原生解析 xlsx + calculator
report.docx	✅	代号 / 日期 / 暗号 全对	2	50k	DC read_file 原生解析 docx
deck.pptx	✅	MAU / 暗号 / 页数 全对	18	369k	DC 读不了 → agent 自己装 python-pptx 跑 REPL
whitepaper.pdf	✅	碳减排 37% / 暗号 全对	26	518k	DC 读 pdf 超时 → agent 自己 uv pip install pypdf
scan.png(图片/扫描)	❌	超时无答案	19+	耗尽	无多模态通路 + OCR 全缺

结论:文本类 4/4 = 100% 正确,能力确实具备。 但"回退 python"时步数/token 暴涨 4~13 倍。

机制剖析

1. xlsx/docx 又快又准,靠的是 desktop-commander 内置 office 解析(read_file 直接回结构化单元格/正文),不是产物自带能力。
2. pptx/pdf 才是"自己调 python":能成,但一路踩坑,摩擦全在环境 plumbing:
   • 机器上 3 个 python(python3→uv 管的 3.14、pip→系统 3.11、产物 .venv),pip install 装到一个解释器、运行的是另一个 → import 反复失败折腾十几步;
   • 用 python3 -i 交互式 REPL 逐行喂代码,多行块要补空行、频繁 SyntaxError;
   • 产物/模型没有任何"用哪个解释器/什么库/写脚本而非 REPL"的引导,全靠模型瞎试。
3. 图片/扫描件彻底失败,两层硬缺口:
   • harness 层没做多模态适配:read_file 对 png 只回 Image file: ... (image/png),loop 把 tool 结果当字符串,永远不会把图片字节(base64 / image_url)塞进消息——换视觉模型也读不了。
   • 纯文本模型的 OCR 兜底也走不通:tesseract / pytesseract / easyocr 全无,apt-get 无权限,pip install easyocr(带 torch)挂死 100+ 秒 → 超时。

附带发现(bug)

被硬终止(timeout/SIGTERM)的 run 会残留孤儿子进程(挂死的 pip 安装 + 多个未回收的 desktop-commander / uvx MCP server)。产物在硬终止时没有把 MCP 子进程组一并收掉。

改进方案(按"薄优先 + 两层心智 + 红线"分层)

A. 零成本、立竿见影(运行期行为,改 prompt 或 RULES.md,不加依赖)

• 给产物加文件处理引导:处理 office/pdf 时写 .py 脚本再 uv run --with <lib> script.py 一把跑,别用 pip install + python3 -i REPL;推荐 openpyxl/python-docx/python-pptx/pypdf。uv run --with 自带隔离环境,一举消除多解释器错配 + PEP668。预期把 pptx/pdf 从 18~26 步压到 ~3-5 步。

B. 中等、仍薄、opt-in(模板层)

• 加 spec 开关式 read_document 内置工具(类比 MCP/web/memory 的 opt-in 方式),用纯 python 库确定性抽取 xls/docx/pptx/pdf 文本,作为可选依赖组(~50-100 行)。不依赖 desktop-commander、不靠模型现装,"关闭零痕迹"。

C. 多模态 + 文件上传(大改,命中 CLAUDE.md §6 红线,需人审签字)

• 改 LLM API 面以支持把图片以 image_url/Anthropic image 块发给视觉模型(§6 第 4 条,需批准)。
• 纯文本模型 OCR 兜底:重依赖,不进薄默认,走"装 tesseract 文档"或 OCR MCP server。
• Web 产物"上传文件":目前只能处理文件系统上、DC 够得到的文件,远程用户无法 attach;需 opt-in 上传端点。

D. 工程/运维

• 修复硬终止时 MCP 子进程未回收(子进程绑 run 生命周期、SIGTERM 杀整个进程组)。

建议落地顺序

先做 A(零依赖、收益最大),再评估 B;C 命中红线先决策;D 作为独立 bug 修复。