fix:可以解析图片 ，pdf，doc，docx文件

[Melon80]

文件解析功能总结

核心目标

测试 MiniMax M2.7（通过 Anthropic Messages API）集成为桌面宠物的 LLM 后端，支持完整的工具/函数调用、自动连接 MCP 工具（understand_image、web_search），并处理文件上传（图片、PDF、DOCX、文本）。

已完成的工作

1. MiniMax 供应商实现

• 协议：minimax-anthropic → anthropic_messages.Provider，原生支持 Tools API
• 图片处理：由于 MiniMax 是纯文本模型，通过 WithDisableImages(true) 在调用 API 前剥离 msg.Media 中的图片 data URL
• 错误修复（解决 2013 错误）：
  • 移除 reasoning_split 自动注入
  • 合并多个 system 消息
  • 跳过空的 assistant 消息
  • 孤立的 tool_result 降级为纯文本
  • 使用 max_completion_tokens 字段名

2. 文件拖拽与二进制支持

• 前端修复：page.tsx 中 handleDrop 正确读取 e.dataTransfer.files 并调用 sendFileDropped()
• 二进制文件：新增 FileIsBinary 字段，PDF/DOCX 等二进制文件以 base64 读取（不是 UTF-8 文本），避免乱码

3. 文档解析

• DOCX：Go 标准库 archive/zip + encoding/xml，剥离 w: 命名空间前缀后解析 word/document.xml
• PDF：github.com/ledongthuc/pdf 库，无需外部 pdftotext
• .doc（OLE）：不支持，用户需转换为 .docx 或 .pdf

4. MCP 自动下载

• uvx 安装：ensureUVX() 按顺序查找：PATH → .goclaw-runtime/bin/uvx.exe → GitHub 下载
• 命令解析：resolveCommand() 自动解析 uvx/uv 为完整路径
• 构造函数：NewManagerWithBinDir(binDir) 指定下载目录

5. MCP 配置

• 服务器名：minimax-coding-plan
• 命令："uvx"（运行时解析，不使用 -y 标志）
• 环境变量：MINIMAX_API_KEY、MINIMAX_API_HOST（必须为 https://api.minimaxi.com）

6. 图片处理策略

• 不使用 load_image：该工具对纯文本模型返回无用的 [image:media://] 引用
• 使用 understand_image：通过 MCP 注册为 mcp_minimax-coding-plan_understand_image，参数为 prompt + image_source

关键决策

决策	原因
Anthropic Messages API 而非 OpenAI	原生支持 tools/function calling
无 streaming	MiniMax API 不支持
uvx 自动下载到 .goclaw-runtime/bin/	零用户配置，重启后生效
DOCX 用 Go 标准库解析	无第三方依赖
PDF 用 ledongthuc/pdf	无需外部 pdftotext

下一步

1. ✅ 验证 DOCX 拖拽解析
2. ✅ 验证 PDF 拖拽解析
3. ✅ 验证 MCP understand_image 正常工作

重要注意点

• logger.Infof 不输出（默认 warn 级别），logger.Warnf 可见
• 网关二进制名为 picoclaw.exe（不是 goclaw.exe）
• uvx -y 不支持 → 使用 uvx minimax-coding-plan-mcp
• Settings 窗口关闭后销毁 → forwardFileToSettings() 会自动重建

[fennoai]

Found a few correctness issues in the new file-upload and MCP bootstrap paths. The comments below are the ones that look worth fixing before relying on this in normal use.

[hazy-cloudy]

@fennoai 帮我检查一下这个pr，把重要的信息告诉我

[fennoai]

Review

1. high clawpet-frontend/clawpet/electron/main.js:2207
   原生文件选择器把“支持的文件”限制在代码/文本/图片扩展名，缺少 .pdf、.docx、.doc。但同一文件里的拖放处理又把这些后缀当成二进制文档支持（main.js:2366）。这会让“点击浏览”路径无法选择 PR 描述里主打的 PDF/DOCX 文件，功能实际不完整。

2. high clawpet-frontend/clawpet/electron/main.js:1910
   当文件提示窗已经打开时，createFilePromptWindow() 只会 focus() 然后直接返回；但 handleFileDropEvent() 在这之前已经把 pendingFileInfo 改成了新文件（main.js:2385）。结果是：界面上显示的是旧文件名，提交时发送的却是新文件内容（main.js:2413）。这是一个明确的错配 bug，连续拖多个文件时很容易复现。

3. high pkg/providers/factory_provider.go:244
   这个 PR 目前把 provider 相关测试跑挂了。我实际执行了 go test ./pkg/providers/...，失败包括 TestCreateProviderFromConfig_MinimaxInjectsReasoningSplit 和 TestCreateProviderFromConfig_MinimaxPreservesUserExtraBody。即使这里的行为变更是有意的，也需要在同一个 PR 里把测试同步更新，否则当前分支处于红灯状态。

4. high pkg/providers/anthropic_messages/provider.go:224
   同一轮 go test ./pkg/providers/... 里，pkg/providers/anthropic_messages 也失败了：TestBuildRequestBody_ConsecutiveToolResultsMerged 和 TestBuildRequestBody_UserToolResultsMerged。从实现看，tool_result 在无法合并时会被降级成新的纯文本 user message（provider.go:244、provider.go:316），这和现有的消息合并语义不一致。至少测试还没跟上，较大概率还带来了真实的协议回归。

5. medium clawpet-frontend/clawpet/electron/main.js:2368
   PR 描述写的是 “.doc（OLE） 不支持，用户需转换为 .docx 或 .pdf”，但实现里 .doc 仍然被当作可上传二进制文件接收。后端既不会解析 .doc，又会在提取失败后提示模型去用 read_file 读取原始文件（service.go:980、service.go:999），而 read_file 对这类二进制文件本来就不可用。这会把“不支持”变成一次失败体验，而不是明确引导用户转换格式。

Notes

• 没找到仓库内的 CLAUDE.md，本次审查按仓库现有代码和 PR 描述执行。
• 我实际跑过：go test ./pkg/providers/...，当前结果为失败，失败点如上。

View job run