2026 DeepSeek Harness 图片附件怎么验收？

验收 DeepSeek Harness 图片附件时，第一道门不是上传按钮，而是模型能力声明。

官方 rc.7 发布说明确认：MCP 与 ACP 新增持久化图片附件，PTC Mode 支持嵌套图片转发。这个结论说明 Harness 链路具备相关功能，但没有说明任意模型都能处理图片。模型是否接受图片，仍取决于模型配置、Provider 声明和实际上游端点。

当前 DeepSeek 官方 Chat Completions 文档列出了 deepseek-v4-flash 与 deepseek-v4-pro 两个模型 ID，同时把用户消息 content 定义为文本字段。官方 Anthropic API 兼容文档也将 image 内容标为不支持。因此，不能因为模型名称、Web UI 或自定义 Provider 写着“视觉模型”，就推断图片已经进入推理请求。

能力声明的检查动作

准备一张带有唯一标记的测试图，例如在四个区域分别放置不同字母。不要使用客户截图、真实密钥、仓库路径或包含个人信息的画面。

先用当前模型发送图片，再发送同样的文字但不附图。两次结果都要保存。若模型回复只复述提示词，或者错误信息明确指出不支持图片，应把问题归到“模型能力”节点，而不是 MCP 或 ACP 节点。

这里的关键证据是三件套：

• 配置层：模型、Provider、输入类型声明。
• 传输层：请求中是否存在真实图片内容或可读取附件引用。
• 上游层：模型是否返回针对图片内容的可验证答案。

图片附件传输通过后，第二关是确认“收到的是正确素材”。

MCP 的资源规范允许资源包含二进制数据，并使用 blob 表示经过编码的内容；这证明协议可以承载二进制资源，但不等于每个 MCP 客户端都会自动把它交给视觉模型。ACP 也定义了文件上传类型，但实际能否进入 Agent 上下文，仍要看实现和能力协商。可参考 MCP Resources 官方规范 与 ACP 官方协议规范。

我们建议使用两张外观相近、内部标记不同的图片：

• 图片 A：左上角写入 RED-41。
• 图片 B：右下角写入 BLUE-82。
• 任务描述明确要求先回答 A，再回答 B。
• 第二轮交换附件顺序，但不改变文字说明。

如果模型始终只回答“看到了两张图片”，这还不够。合格结果必须能把标记、位置和任务顺序对应起来。否则可能只是附件对象存在，模型上下文里却没有真实图像内容。

不要只截取上传后的 UI。至少保留附件 ID、MIME 类型、任务序号、接收端记录和模型回答。对于远程 Web 工作流，还要记录浏览器端、Harness 服务端和 Provider 端各自的时间点，便于定位到底是前端、协议层还是上游拒绝。

图片附件的持久化至少要拆成三层：

1. 界面缓存：刷新后缩略图仍显示。
2. 会话记录：历史消息中还保留附件 ID 或 URI。
3. 真实资产：系统仍能读取图片二进制，并交给后续请求。

这三层经常被混为一谈。浏览器缓存可以让图片继续显示，但实际文件已经被清理；会话 JSON 可以保留一个路径，但远程进程已经没有读取权限；附件资产也可能存在，却因为 Provider 不支持图片而无法继续推理。

建议按以下顺序执行：

• 打开新会话，发送带唯一标记的测试图。
• 刷新 Web UI，重新要求模型回答标记。
• 断开客户端，再重新连接 MCP 或 ACP。
• 停止并重启 Harness 进程。
• 清理浏览器缓存后再次打开旧会话。
• 检查附件资产、会话文件和权限。
• 记录每一步的读取结果与错误信息。

判定时不要只写“刷新后正常”。应明确写成“界面缓存通过、会话记录通过、进程重启失败”这类分层结论。只有真实资产可再次读取，且模型在恢复后的新请求中再次正确识别图片，才可以把该项标记为通过。

PTC Mode 的嵌套任务需要单独验收。主任务能读图，不代表子任务收到了同一张原图。常见错误包括：子任务只收到图片文件名；收到的是缩略图；附件 URI 在子任务工作目录中无权限；任务链重放时使用了旧附件。

设计一个能区分责任节点的测试：

• 主任务发送图片 A，要求识别左侧标记。
• 嵌套任务发送或转发图片 B，要求识别右侧标记。
• 主任务与子任务使用不同问题，避免只复述同一答案。
• 保存父任务轨迹、子任务输入、子任务输出和最终汇总。
• 故意移除 B 的读取权限，再执行一次，观察失败节点。

如果主任务正确、子任务错误，不能把结果记为“图片功能失败”。应进一步判断是 PTC Mode 转发、子任务上下文构造，还是远程权限导致。rc.7 的 Release 说明确认了嵌套图片转发能力，但正式上线前仍需要在实际模型和实际 Provider 上验证。

图片被上游拒绝后，旧会话恢复可能再次发送相同附件。若恢复逻辑只保存了原始消息，没有保存“该模型拒绝图片”的失败状态，就可能出现以下循环：

图片进入队列 → 上游拒绝 → 会话保留附件 → 恢复旧会话 → 自动重放 → 再次拒绝。

我们建议至少测试三条安全回退路径：

• 移除附件：保留文字任务，改用图片摘要或人工标注。
• 切换模型：切换到明确声明支持图像输入的 Provider，并重新建立请求。
• 新建会话：不继承旧附件，确认新会话不会自动重放。

验收记录中要写清“恢复后是否自动发送”“发送了几次”“失败后是否需要人工确认”。这里不必追求无限重试。视觉模型不支持图片时，继续重放不是容错，而是放大故障。

下面的 FAQ 适合放在测试报告中部，作为故障初筛，而不是替代日志。

如果 DeepSeek Harness 拒绝发送图片，先看模型能力声明和请求体。若请求体根本没有图像内容，排查附件构造；若请求体有图片但上游拒绝，排查 Provider 与模型匹配；若上游成功但回答不识别标记，再检查格式、权限和实际资产。

MCP 与 ACP 的图片持久化不能只依据 rc.7 的功能说明下结论。应分别做刷新、重连、重启三次验证，并将两条链路的日志分开保存。

PTC Mode 嵌套任务必须验证子任务输入，而不是只看父任务最终回答。远程运行时则要同时检查文件存在性、会话引用和进程访问权限。恢复旧会话后反复发送图片，通常说明失败状态没有被安全处理。

在远程 Mac 环境中，图片任务至少涉及四类责任：

• 附件文件保存在哪里。
• 会话记录由哪个进程写入。
• 当前用户和服务进程是否有读取权限。
• 交接后路径、密钥和运行目录是否仍然有效。

远程运行并不会天然提供持久化，也不会自动完成数据隔离。测试团队交接时，应交付脱敏后的测试图、会话 ID、附件引用、运行日志、模型配置摘要和恢复结果。不要直接交付真实客户截图或包含 API Key 的完整配置文件。

如果需要临时搭建独立环境，可以先查看 MESHLAUNCH 的 Mac 远程环境方案。对于需要固定 Mac 节点进行团队复核的任务，也可以参考 Mac mini M4 租赁与交付页面。但无论环境来自本地还是远程，都要重新执行附件恢复测试，不能把机器可访问等同于会话可恢复。

• [ ] 记录 Harness 版本，并核对是否为 rc.7 或后续版本。
• [ ] 保存模型配置、Provider 名称和 image 输入声明。
• [ ] 使用不含敏感内容、带唯一标记的测试图片。
• [ ] 核对请求体中是否存在真实图片内容或可读取附件引用。
• [ ] 保存上游响应、错误码和错误文本。
• [ ] 分别测试单图、双图、附件顺序交换。
• [ ] 分别验证 MCP 与 ACP，不把一条链路的结果复制给另一条。
• [ ] 刷新页面后重新要求模型识别图片标记。
• [ ] 重连客户端后重新读取附件。
• [ ] 重启 Harness 进程后验证真实资产是否仍可读取。
• [ ] 检查附件文件、会话文件和服务进程权限。
• [ ] 在 PTC Mode 中让主任务与子任务读取不同图片细节。
• [ ] 保存父任务轨迹、子任务输入和子任务输出。
• [ ] 模拟上游拒绝图片，观察是否出现自动循环重放。
• [ ] 验证移除附件、切换模型、新建会话三条回退路径。
• [ ] 交接前用另一名工程师完成一次独立复现。
• [ ] 删除真实密钥、客户截图和仓库敏感内容后再归档证据。

我们建议将结果分为三档：

如果当前方案是普通本地开发机或一次性 Windows／Linux 远程主机，常见缺点是附件路径依赖个人环境、会话文件没有统一交接、重启后的权限状态不透明，团队也很难复现同一张测试图片。相比之下，使用 MESHLAUNCH 的独立 Mac 环境，可以把远程运行、权限检查和交接流程放进同一份验收记录里；但长期高负载、必须持有物理接口或需要永久保存大量资产的团队，仍应评估自购设备和专用存储。

若只是临时验收一轮图片任务，先准备脱敏测试图和空白记录表，在独立远程环境完成一次完整复现即可。若附件还要长期保存、供多人复核，再继续查看 云端 Mac 交付验收相关环境，并把会话恢复结果纳入交接标准。