2026 DeepSeek Harness 圖片附件怎麼驗收？

rc.7 的 Release Notes 明確寫出「MCP/ACP 支援持久化圖片附件」及「PTC Mode 可轉發巢狀圖片」。這是產品功能層面的確認，不是您目前配置已經通過驗收的證據。DeepSeek Harness 仍處於 Developer Preview，官方 README 也提醒可能出現相容性破壞變更。(github.com)

另一個容易混淆的點是模型能力。官方 DeepSeek Chat Completions 文件目前將訊息內容描述為文字欄位，並沒有把圖片輸入當成一般 /chat/completions 路由的通用能力。換句話說，自訂 Provider 在介面中宣告 image 或 attachment，不能等同於上游端點實際支援圖片。(api-docs.deepseek.com)

第一項驗收不是「圖片能不能拖進輸入框」，而是「目前模型是否被系統標記為可接收圖片」。我們會保存三份資料：

1. 模型或自訂 Provider 的能力設定。
2. 介面允許、攔截或拒絕附件的畫面紀錄。
3. 上游請求與回覆中的內容型別、錯誤碼或拒絕原因。

測試圖片不要使用客戶截圖。建議製作一張無敏感資料的合成圖片：放入三個不同顏色的幾何圖形、兩段不相同的短文字，以及一個明顯位置標記。任務描述只要求模型回答其中兩項，例如「指出右上角圖形顏色，並抄錄底部標記」。這樣比問「請描述圖片」更容易判定模型是真的讀圖，還是只回覆泛化文字。

若模型名稱看起來像多模態，不代表它就是視覺模型。若 Provider 設定寫了支援圖片，也不代表上游路由會接受圖片。這是 DeepSeek Harness 圖片附件驗收中最常見的誤判來源。

MCP 或 ACP 通道通過，不等於附件內容正確抵達。傳輸驗收要同時看素材、順序與任務上下文。

MCP 與 ACP 的驗收紀錄至少要包含附件識別、原始檔案名稱或雜湊、傳遞時間、任務識別，以及模型實際回覆。若安全政策不允許保存原圖，可以保存合成測試圖的雜湊與局部遮罩，但不能只留一張上傳成功的螢幕截圖。

這裡也要避免把「收到本機路徑」誤認為「收到圖片」。路徑可能只對目前遠端使用者有效；模型端點若沒有讀取該路徑的權限，實際上仍然沒有取得圖像內容。

rc.7 的功能描述提供了持久化方向，但驗收仍要拆成三種狀態：

• 介面快取：刷新前後仍看見縮圖。
• 會話紀錄：舊訊息中仍保留附件引用或訊息內容。
• 可讀取資產：系統能在新的連線或程序中，再次取得圖片並讓模型讀取。

我們會依下列順序測試：

1. 在新會話傳送合成圖片，要求模型回覆唯一標記。
2. 關閉頁面並重新開啟。
3. 讓客戶端斷線後重新連線。
4. 重啟 DeepSeek Harness 相關程序。
5. 開啟舊會話，要求模型再次讀取圖片中的另一個細節。
6. 對比原始附件識別、會話紀錄與模型回覆。

若只有縮圖出現，但重新提問時模型回覆「看不到圖片」，判定為介面或會話層保留，不能算附件持久化。若會話文字仍在，但實體附件已失效，也不能標記為通過。

官方多輪對話文件指出，DeepSeek /chat/completions 是無狀態 API，呼叫端需要自行帶回對話歷史。這會讓圖片恢復更容易出現邊界問題：系統可能保存了訊息，但未保存可重新取得的圖片資產。(api-docs.deepseek.com)

PTC Mode 的驗收重點不是主任務能否看圖，而是子任務是否收到「正確的那一張圖」。我們會設計一個主從任務：

• 主任務讀取圖片左側的藍色標記。
• 巢狀任務讀取右下角的文字標記。
• 另一張相似圖片只作為干擾，不應被子任務引用。

驗收資料要保存三段：

1. 主任務建立巢狀任務時的附件引用。
2. 子任務實際收到的訊息或附件識別。
3. 子任務回覆與失敗位置。

若主任務回答正確、子任務回答錯誤，責任可能在 PTC Mode 轉發、附件解析或子任務 Provider，而不是原始上傳。若任務軌跡只記錄「已建立子任務」，沒有附件識別與輸入內容，測試結果只能判為限制，不應判定通過。

圖片工作流最危險的故障不是一次拒絕，而是恢復後無限重播。典型流程是：舊會話包含圖片；上游端點拒絕圖片；恢復程序把相同請求再次送出；系統再次失敗，最後形成循環。

我們會為每個含圖片會話準備三條回退路徑：

• 移除附件：保留任務文字，改用圖片摘要或人工標註。
• 切換模型：改用已明確宣告圖像輸入、且通過單圖測試的視覺模型。
• 建立新會話：不重播原始附件，只帶入必要的文字上下文與測試結果。

判定時記錄恢復次數、上游拒絕原因、是否產生重複請求，以及回退後能否繼續任務。若同一圖片在短時間內被重送，必須標記為「恢復風險」，即使最後一次請求成功，也不宜直接投入無人值守工作流。

遠端 Mac 適合做瀏覽器、編輯器與 Agent 工作流的隔離測試，但不要把遠端執行環境當成天然具備資料持久化或權限隔離。圖片資產可能位於使用者目錄、暫存目錄、瀏覽器快取或應用程式資料夾。不同位置的保留週期與交接權限不一定相同。

在遠端環境中，我們會額外核對：

• 附件實體位置與檔案權限。
• 會話檔案是否與附件分開保存。
• 新連線帳戶能否讀取必要資產。
• 交接後是否可依操作紀錄重現。
• 測試完成後是否清除截圖、密鑰與客戶資料。

若團隊需要固定的遠端 Mac 測試節點，應把「附件可重現」寫入交付條件，而不是只驗收螢幕能否連線。可先參考 MESHLAUNCH 的雲端 Mac 交付方案，再按實際地區與權限政策安排獨立測試環境。若需要先了解可用的遠端 Mac 工作環境入口，也可以查看 MESHLAUNCH 的遠端 Mac 服務頁面，再決定是否把附件交接測試放到獨立節點。

DeepSeek Harness 為甚麼拒絕傳送圖片

先看模型能力聲明，再看介面攔截紀錄。若附件按鈕消失或送出前被拒絕，問題多半在模型設定層；若介面允許但上游回傳不接受內容，問題在 Provider 或端點相容性；若上游成功但回覆無法讀圖，才進一步檢查視覺模型能力與素材格式。

MCP 和 ACP 圖片附件能不能持久化

rc.7 已確認加入持久化圖片附件，但驗收對象是完整工作流，不是 Release Notes 本身。必須做刷新、重連、程序重啟和新工作階段讀取。只保存縮圖或訊息文字，不能證明實體附件仍可用。

PTC Mode 巢狀任務能否收到原圖

功能層面已宣稱支援巢狀圖片轉發。實際驗收仍要檢查子任務輸入。若只看到主任務成功，不能推論子任務取得原圖。主任務、子任務和附件識別需要在同一份軌跡中互相對得上。

遠端運行時怎樣確認圖片沒有丟失

在遠端 Mac 上重新開啟會話，使用新連線讀取圖片中的唯一標記，再核對檔案權限與附件識別。若交接後只能看見歷史縮圖，卻無法讓模型再次讀取，應判定為資產遺失或權限不足。

恢復舊會話後圖片為甚麼會再次傳送

因為無狀態上游需要呼叫端重建歷史，而恢復機制可能把圖片訊息當成可重播請求。若附件引用不穩定，系統就可能重送原始圖片。測試時要確認失敗後能移除附件、切換模型或建立新會話，而不是繼續自動重試。

• [ ] 已記錄實際使用的模型、Provider、端點與版本。
• [ ] 模型設定明確寫出是否支援 image 輸入。
• [ ] 已用不含敏感資料的合成圖片測試唯一標記。
• [ ] 已保存介面攔截、配置聲明與上游回覆證據。
• [ ] 已測試單張圖片、圖片順序與圖片加任務描述。
• [ ] MCP 或 ACP 紀錄能對應附件識別與模型輸入。
• [ ] 已完成刷新、客戶端重連與程序重啟測試。
• [ ] 已區分介面快取、會話紀錄和實際附件資產。
• [ ] PTC Mode 子任務能讀取指定的不同圖片細節。
• [ ] 失敗時能定位模型、轉發、儲存或權限責任節點。
• [ ] 舊會話恢復不會無限重送被上游拒絕的圖片。
• [ ] 已測試移除附件、切換模型與新建會話三種回退。
• [ ] 遠端 Mac 交接後仍能依紀錄重現讀取結果。
• [ ] 測試資料不含真實密鑰、客戶截圖或未授權倉庫內容。

我們建議把結果分成三類，而不是只寫「成功」或「失敗」。

通過：模型能力已確認，MCP 或 ACP 傳輸正確，刷新與重連後附件仍可讀，PTC Mode 子任務取得正確圖片，恢復流程也有安全回退。這類工作流才適合上線。

限制：圖片能傳到主任務，但持久化、巢狀轉發或遠端交接仍缺證據。可用於人工監督的試用，不宜放入無人值守流程。

拒收：模型未宣告圖像輸入、上游明確拒絕圖片、附件在重連後失效，或恢復流程會循環重送。此時應切回文字證據、改用已通過驗收的視覺模型，或暫停該工作流。

相較於直接在本機或一般 Linux 伺服器上測試，現有方案常見的問題是附件落在個人暫存目錄、權限依賴單一帳戶、交接後無法重現，以及重連時缺乏一致的會話檔案。遠端環境也不會自動解決這些責任邊界。若需要臨時建立一個可交接的 Mac 測試節點，MESHLAUNCH 的遠端 Mac 方案能讓我們把瀏覽器、會話檔案與驗收紀錄放在獨立環境中，再按團隊權限安排交付；但長期固定重負載或需要實體周邊的工作，仍應評估自購 Mac。

本週最穩妥的做法，是先下載或自行建立一份空白驗收表，在獨立遠端環境完成一輪合成圖片測試。若附件還要長期保存、供多人複核，接著應把雲端 Mac 交付、權限與會話恢復一併納入驗收，而不是只確認圖片曾經成功上傳。