頁面可訪問，不等於交付通過。
最快解法：先用同一張驗收表記錄環境身份、權限、工作區、模型工具鏈、持久化、重啟恢復與交接材料；任何關鍵項目無法重現，就先整改，不要直接投入持續運行的 Agent 任務。

誰應該使用這份驗收表

技術採購人員可以把抽象需求轉成可簽收的交付項。開發者可以確認遠端環境能完成真實任務，而不是只展示一個可開啟的畫面。

運維團隊則需要用它界定重啟、日誌、權限、版本更新與故障回退責任。這也是一份適合在租用期開始前留存的交付清單。

最後更新於 2026 年 8 月 18 日，資料核實自 DeepSeek Harness 官方程式庫、Web UI 指南、模型設定指南與架構文件；雲端 Mac 的配置、交付方式、節點和恢復能力不從官方文件推導。(github.com)

先固定環境身份

DeepSeek Harness 目前仍標示為 developer preview，官方明確提醒可能出現相容性破壞變更。因此，驗收表第一欄不是「這台是哪一款 Mac」，而是交付當日實際運行了什麼。(github.com)

請在遠端 Mac 執行並保存以下資料：

sw_vers
uname -m
node --version
which dsh
dsh --version
pwd
dsh --profile web --dump-config

若 dsh --version 不可用，就保存實際啟動命令、套件鎖定檔、提交版本或交付頁面中的版本識別。不要從「某款 Mac」或「某個預設配置」推測 DeepSeek Harness 版本。

驗收項目 檢查動作 必須留下的證據 通過標準
作業系統與硬體身份 執行 sw_vers、uname -m 原始命令輸出 與交付單一致
Harness 來源 記錄 npm、原始碼或其他來源 啟動命令、版本或提交識別 可在之後重新定位
執行依賴 記錄 Node.js、套件管理器與依賴安裝方式 版本輸出與鎖定檔 另一位工程師可重現
Profile 與配置 執行 dsh --profile web --dump-config 脫敏後的配置輸出 實際啟動樹與交付說明一致

官方 Web UI 預設在 http://127.0.0.1:3080 提供服務。這個 3080 只是預設連接埠，不代表遠端使用者已經能安全或正確地進入控制面；外部存取方式仍要由交付方說明並實測。(github.com)

再劃清存取與控制邊界

雲端 Mac 常見的第一個誤判，是把「可以遠端登入 macOS」等同於「可以自由控制 Agent」。兩者必須分開驗收。

你需要測試：

  1. 遠端登入帳戶是否為個人帳戶，是否仍保留交付方共用帳戶。
  2. 登入帳戶是否具備管理員權限，以及哪些動作需要額外授權。
  3. Web UI 是只在本機回環位址提供，還是透過反向代理、VPN 或其他入口轉發。
  4. 交接後能否由你更換 SSH、遠端桌面、Web UI 與 API 憑據。
  5. 未授權帳戶是否能看見工作區、會話紀錄、模型設定或命令控制面。

DeepSeek Harness 的模型設定頁會保存憑據參照，而不是在頁面回傳完整金鑰；官方文件也說明 API 金鑰寫入憑據檔，設定檔只保留參照。驗收時仍要確認該檔案的權限、所在路徑、備份範圍和交接後的更換流程，不能只因畫面顯示遮罩就判定安全。(github.com)

另外，遠端 Mac 登入權限與 Harness 內部的命令審批策略不是同一層。你要分別記錄「誰能登入主機」和「Agent 執行哪類工具時需要批准」。若只測試前者，仍可能留下過寬的檔案或命令操作範圍。

用隔離工作區測試檔案邊界

官方指南指出，啟動 dsh 的目錄會成為預設檔案系統位置，但新 Web UI 在加入工作區前並沒有已選定的工作區。這正是交付驗收的關鍵：工作目錄設定文字不能代替檔案存取測試。(github.com)

準備一個不含機密的測試倉庫，放入：

  • 可讀取的說明檔。
  • 允許修改的測試檔。
  • 明確標記為只讀的檔案。
  • 倉庫外、但同一使用者可見的測試路徑。
  • 一個要求執行命令後才會產生的輸出檔。

接著依序執行：

  1. 在 Web UI 選取指定工作區。
  2. 要求 Agent 列出目前可見的檔案。
  3. 要求它只修改允許修改的測試檔。
  4. 要求它嘗試修改只讀檔案，確認是否被拒絕或要求批准。
  5. 要求它讀取倉庫外路徑，記錄實際結果。
  6. 執行命令產生輸出，再確認結果是否寫回預期位置。
測試場景 成功信號 失敗信號 判定
讀取工作區 只列出測試倉庫內內容 看不到已選工作區或讀取錯誤 工作區未完成
受控修改 指定檔案出現可核對差異 修改到未授權檔案 邊界不合格
只讀任務 Agent 保持檔案不變，必要時提出批准 直接寫入或繞過策略 權限需整改
越界路徑 拒絕、遮蔽或清楚要求批准 直接讀寫倉庫外資料 不得簽收
命令結果寫回 輸出出現在指定目錄 結果遺失或落到未知路徑 需追查檔案流向

用固定任務驗證模型與工具鏈

模型清單能出現，只能證明設定頁有資料。正式驗收要走完「憑據、最小回應、工具呼叫、命令批准、結果寫回」整條鏈。

固定基準任務可以很小，例如：

讀取測試倉庫中的 README.md，找出指定函式，提出一項最小修改，先要求命令批准，再執行測試並把結果寫入 artifacts/result.txt。

保存四種產物：

  • 原始輸入與工作區識別。
  • 模型回應及實際選用的模型路由。
  • 工具呼叫、批准畫面或拒絕訊號。
  • 最終檔案差異與測試輸出。

官方模型指南指出，模型變更會在下一次請求生效，不需要重新啟動伺服器；已經送出請求的會話則會保留其紀錄中的模型。這代表你必須分開測試「新會話模型切換」和「既有會話是否沿用原模型」，不能只看設定頁的目前選項。(github.com)

官方架構把模型介面、工具登錄、會話紀錄和 Agent loop 都設計成可替換插件；核心架構文件列出的核心套件至少有 6 個，並把事件分成多個不同用途的處理層。對採購與運維來說，這意味著插件組合本身就是交付身份，不能只寫「已安裝 DeepSeek Harness」。(github.com)

受控重啟並核對狀態

重啟驗收不要一開始就重開整台 Mac。先建立測試會話，加入非敏感配置，完成一次可辨識的工具呼叫，再依照交付方建議的方式重啟 Web UI 或相關執行程序。

重啟前記錄：

  • 會話識別與最後一則訊息。
  • 已選工作區。
  • 目前模型與 Provider ID。
  • 啟用的插件或 Profile。
  • 未完成任務與待批准命令。
  • 日誌檔案位置。

重啟後逐項核對：

  1. 原會話是否仍可開啟。
  2. 工作區是否需要重新選取。
  3. 模型是否仍為原路由。
  4. 插件是否按原順序載入。
  5. 未完成任務是恢復、停止，還是需要人工重新提交。
  6. 會話日誌是否能查到重啟前的工具結果。

官方架構把 session log 視為模型可見上下文的來源，並說明恢復、分支、轉錄與持久化都由這條事件流衍生。驗收時應要求交付方展示原始日誌或脫敏後的事件紀錄，而不是只展示重啟後一個空白頁面。(github.com)

FAQ：把長尾疑問變成簽收條件

雲端 Mac 能打開 DeepSeek Harness 就算交付成功嗎？

不能。頁面可開啟只代表 Web UI 有回應，尚未證明模型憑據、工作區、命令審批、檔案邊界與重啟後狀態都正常。正式簽收前，至少要完成固定任務並保存成功與失敗證據。

交付時要保存哪些版本和運行資訊？

請保存 macOS 版本、硬體識別、DeepSeek Harness 來源與版本、Node.js 或其他執行依賴、啟動命令、設定檔位置及模型路由。每項資料都應來自實際命令輸出或交付頁面，不要從機型名稱推測。

DeepSeek Harness 重啟後，原來的會話和配置一定會保留嗎？

不一定。官方架構把會話紀錄、設定、憑據參照與插件組合分開管理；你必須先建立測試會話，再執行受控重啟，逐項確認會話、工作區、模型與插件是否恢復。未測試的項目不能寫成保證。

遠端 Mac 要怎樣驗收工作區和命令權限？

不要只看畫面上的工作目錄。你應使用隔離測試倉庫，分別測試讀取、受控修改、只讀檔案、命令審批與越界路徑，並記錄 Agent 實際能看到和能修改的範圍。

持續運行 AI Agent 的交付包應該包含什麼？

至少包括環境清單、存取責任、模型與工具測試紀錄、日誌取得方式、備份範圍、更新責任、重建邊界與回退步驟。交接資料不得保留明文 API 金鑰，並應清楚標出哪些恢復動作仍需人工處理。

建立故障止損與交接材料

持續運行的 Agent 環境，真正的成本通常不在第一次啟動，而在故障後找不到責任邊界。交付方至少要回答：

  • 日誌由誰取得？保存多久？是否能匯出單一會話？
  • 基礎健康檢查包含 Web UI、模型請求、工作區讀取和工具執行嗎？
  • DeepSeek Harness 或插件更新由誰負責？更新前是否先備份配置？
  • 備份包含會話、工作區、插件設定，還是只包含 macOS 使用者目錄？
  • 哪些情況可以回退到上一個 Profile？
  • 若環境需要重建，哪些步驟由交付方執行，哪些步驟需要你重新提供？
  • 是否有已實測的重建流程？若沒有，不要把任何恢復時間寫成承諾。

交接包建議分成五份：

  1. 環境清單：作業系統、硬體身份、依賴、來源、Profile、啟動命令。
  2. 存取責任表：遠端登入、Web UI、管理權限、憑據更換人員。
  3. 測試紀錄：固定任務輸入、成功結果、失敗訊號、檔案差異和日誌位置。
  4. 備份範圍：哪些資料已備份，哪些資料明確不在備份內。
  5. 回退步驟：如何停止 Agent、切換配置、撤銷插件與恢復工作區。

不要在交接文件中留下明文金鑰。只記錄憑據名稱、存放方式與更換程序。

用三種結論完成簽收

你可以把所有指標收斂成以下決策條件：

  • 若七類關鍵指標都有可重現證據，且固定任務成功完成，則選「通過」。
  • 若只有非核心項目缺少文件，例如日誌保存期限或更新責任未寫清，但目前任務可重現，則選「限期整改」，並寫明負責人、期限與驗證方法。
  • 若模型鏈路、工作區邊界、命令審批、會話恢復或憑據交接任一項無法重現，則選「拒絕簽收」，先回退到測試狀態。
  • 若交付方要求你以配置名稱、演示畫面或口頭保證代替實測，則回退到逐項驗收，不接受模糊結論。

這套條件也能套用到 DeepSeek Harness 雲端 Mac 租用方案 的前置確認，先把並發任務、隔離要求、遠端登入方式和預期租期寫清楚，再核對實際能交付的環境。

目前方案與 MACCOME 方案的取捨

如果你現在是把 DeepSeek Harness 放在個人 Mac 上長期運行，常見缺點是主機被日常工作占用、遠端登入和權限交接依賴個人設定，重啟後的會話與插件狀態也未必有人負責核對。若改用臨時雲主機或自行拼裝遠端環境，則可能遇到 macOS 相容性不足、圖形化遠端操作不順，以及模型、工具和檔案邊界需要你自己維護的問題。

因此，當你的目標是短期測試、團隊驗收或需要一台獨立 Mac 來重現固定任務時，較合理的做法不是先承諾某個未驗證配置，而是把這份驗收表交給 MACCOME，連同並發需求、隔離要求與預期租期一併核對。你也可以先查看不同地區的雲端 Mac 算力交付選項，再依實際測試結果決定是否投入持續運行。

若你的工作是長期固定重負載、必須接觸實體 USB 或需要完全控制硬體生命週期，自購 Mac 可能更合適；若只是臨時算力、版本驗證或交付前測試，租用一個能按同一張清單驗收的雲端 Mac，通常比自行維護一套未經核對的遠端方案更容易止損。你亦可參考香港雲端 Mac 算力配置，再提出你的實際驗收條件。