目前確認的是更名，不是已證實的能力重構。截至 2026 年 8 月 18 日，v0.1.0-rc.7 的官方發布說明只確認英文內置預設由 Code Mode 更名為 PTC Mode；你本週應先檢查介面名稱、保存的設定引用與團隊文件，不必僅因名稱變化重做部署。

這篇適合正在使用舊 Code Mode 名稱、擔心升級後設定失效的開發者，也適合維護預設、插件或團隊交接文件的工具鏈負責人。若你正在評估是否為 PTC Mode 單獨準備一套執行環境，文中的判斷條件可以直接拿來做決策。

最後更新於 2026 年 8 月 18 日，資料核實自官方 v0.1.0-rc.7 發布說明、DeepSeek Harness 官方倉庫、使用指南與 Cordis 文件。

01

先分清楚：官方確認了什麼

官方 v0.1.0-rc.7 發布說明把這項變更放在「體驗優化」項目中，原文是將英文內置預設 Code mode 更名為 PTC mode。同一份發布說明另外列出插件設定卡片、MCP 與 ACP 圖片附件、Cordis 動態插件面板，以及模型推理強度等變更；因此不能把所有同版本變更都歸因於 PTC Mode 名稱本身。(官方 v0.1.0-rc.7 發布說明)

目前沒有同一份官方說明可以證明以下事項已經改變：

  • 工具呼叫的底層執行方式。
  • 預設可使用的插件組合。
  • 使用者確認或授權的權限邊界。
  • cordis 設定鍵、插件註冊介面或持久化格式。
  • 執行 PTC Mode 所需的記憶體、處理器、儲存空間或並發資源。

所以，DeepSeek Harness PTC Mode 和 Code Mode 有什麼區別，目前最穩妥的回答是：官方已確認名稱不同，但尚未確認能力契約因此改變。你可以把 PTC Mode 視為同一套 DeepSeek Harness 內置預設的新英文名稱，而不是立即視為獨立產品、新協議或全新執行引擎。

DeepSeek Harness 官方 README 將 dsh 定義為開源 agent harness，並說明其採用「一切皆插件」的架構。Cordis 則是支援動態組合的 meta-framework，不等於 PTC Mode 本身。(DeepSeek Harness 官方倉庫)

02

現有 Code Mode 使用者：先做名稱盤點

升級後原來的 Code Mode 設定還能不能用？
在沒有官方遷移說明或明確的設定鍵變更前，不應直接判定設定失效。真正需要確認的是你的設定引用了「顯示名稱」，還是引用了穩定的預設識別值。

這兩者影響不同：

  • 只在 Web UI 中顯示 Code Mode：通常只需要重新確認畫面文字。
  • 團隊手冊寫死 Code Mode：需要補充新舊名稱對照，避免交接時選錯。
  • 自動化腳本以名稱尋找預設：必須檢查腳本是否依賴文字匹配。
  • 插件設定卡片直接顯示舊名稱：需要在實際版本中確認是否已更新。
  • 設定檔保存了預設 ID：不要自行把 ID 改成 ptc，除非官方文件明確要求。

官方使用指南顯示，Web UI 的工作區、模型與操作權限是分開處理的。使用者先設定模型，再選擇工作區；需要批准的操作則由目前的權限政策處理。這種文件結構支持一個重要判斷：預設名稱、工作區設定與權限政策不是同一層概念，不能因名稱更新就推論權限已經變更。(DeepSeek Harness 使用指南)

你可以先保留一份升級前的設定備份，再在新版本中完成一次最小任務：

  1. 記錄升級前顯示的預設名稱。
  2. 匯出或複製現有設定檔，不要覆蓋原檔。
  3. 升級至 v0.1.0-rc.7 後，確認畫面是否顯示 PTC Mode。
  4. 載入原工作區，執行只讀取檔案的測試任務。
  5. 再測試一個需要使用者批准的操作。
  6. 比對工具清單、批准流程與任務結果。
  7. 若只有文字變化，保留現有部署，不要擴大變更範圍。
03

PTC Mode 的定位：預設名稱，不是新協議

首次接觸 PTC Mode 時，最容易犯的錯是把名稱中的縮寫解讀成已經公開定義的新技術。就目前可引用的官方資料，PTC Mode 首先是 DeepSeek Harness 內置預設名稱。官方文件仍以插件架構、Web UI、CLI、工作區與模型設定作為主要入口，沒有將 PTC Mode 定義成獨立協議。(DeepSeek Harness 官方文件)

PTC Mode 是否會改變工具呼叫和權限？
目前不能這樣下結論。即使發布說明同時提到 PTC Mode 可轉發嵌套圖片，也只能說該版本在相關功能上列出了明確變更；這不代表所有工具呼叫、授權流程或插件生命週期都已改寫。

你需要把三個層次分開：

層次 目前能確認的內容 你應採取的動作
預設名稱 Code mode 更名為 PTC mode 更新介面截圖與操作文字
插件與執行模式 DeepSeek Harness 採用插件化架構，Cordis 負責動態組合背景 核對實際插件註冊結果，不猜測別名
權限與環境 官方未因更名確認新的權限或資源要求 維持現有環境，除非驗證出行為差異

這也解釋了為何不應把本文寫成 Web、Headless、ACP 的重複選型文章。你現在要處理的不是「哪個模式功能最多」，而是「名稱變更是否觸發現有流程的維護成本」。

04

插件作者：檢查名稱依賴與文案

插件作者的風險不在名稱本身，而在名稱是否被硬編碼到程式、設定卡片或文件流程中。v0.1.0-rc.7 的發布說明確認插件可以自行註冊設定卡片，這使插件介面文字成為需要單獨驗收的區域。

建議你依照以下順序檢查：

  1. 在插件原始碼搜尋 Code Mode、Code mode 與大小寫變體。
  2. 檢查設定卡片標題、說明文字與預設選項。
  3. 檢查插件註冊時使用的是顯示名稱、常數還是內部識別值。
  4. 在 v0.1.0-rc.7 中重新載入插件，記錄實際註冊結果。
  5. 只讀取與安全操作各執行一次，確認插件仍能被正確掛載。
  6. 將舊名稱保留在變更紀錄中，但不要自行創造未經官方確認的相容別名。

官方插件文件可用來確認插件層與執行層的邊界。若你的程式只是用文字顯示模式名稱，通常屬於文案修訂；若它用名稱選擇插件集合，則必須進行行為驗收。(DeepSeek Harness 插件文件)

一個常見的插件案例

假設你的團隊插件說明寫著「在 Code Mode 下啟用批次檔案工具」。升級後介面顯示 PTC Mode，但插件仍正常載入。此時最合理的做法是先把文件改成「PTC Mode（原 Code Mode）」；不要立即修改插件註冊邏輯，也不要為了名稱變化建立另一套插件。

相反，如果插件在啟動時以字串尋找 Code mode，升級後載入失敗，這才是需要修正的相容性問題。問題來源是名稱依賴，不是已證實的 PTC Mode 能力重構。

05

團隊維護：先保留映射，再統一術語

團隊最常遇到的不是程式崩潰，而是新舊名稱並存。操作手冊、培訓影片、螢幕截圖、值班筆記與自動化腳本可能在不同時間更新。這會讓新成員以為 Code Mode 和 PTC Mode 是兩個不同選項。

低風險做法是分兩階段處理：

第一階段：建立映射說明。
在團隊文件第一次出現 PTC Mode 時，寫成「PTC Mode（原英文預設名稱 Code Mode）」。舊截圖不必全部重做，但要在圖片旁標註版本與名稱差異。

第二階段：穩定版本後統一術語。
等官方文件補充定義、遷移說明或後續穩定版本確認名稱固定，再一次性更新手冊、交接頁面與內部搜尋關鍵字。

你也應將自動化腳本分成兩類。依穩定識別值選擇預設的腳本可以先保留；依畫面文字、CLI 輸出或模擬滑鼠位置操作的腳本，則應列入升級驗收。這是團隊維護成本的實際來源，與 PTC Mode 是否更快、更省資源無關。

06

平台負責人：不要因更名擴容

團隊需要為 PTC Mode 單獨準備執行環境嗎？
目前沒有足夠官方證據支持這個決定。名稱變化本身不能證明新的記憶體需求、並發能力、網路頻寬、儲存空間或長時間執行責任已經不同。

平台與遠端環境負責人應觀察的是可驗證的變化：

  • 相同任務是否產生不同數量的工具呼叫。
  • 相同工作區是否出現新的權限批准要求。
  • 插件初始化時間與失敗率是否改變。
  • 工作階段是否需要不同的持久化資料。
  • 長時間任務是否出現新的背景工作或子代理負載。

如果目前只是預設名稱改變，繼續使用既有環境更合理。若你要在遠端 Mac 上做升級驗收，可先參考 VpsMesh 的遠端 Mac 環境。驗收重點應放在連線、工作區路徑、權限提示與插件載入，而不是先購買更高規格的伺服器。

若你還沒有固定的遠端測試節點，應先確認遠端 Mac 部署的連線方式、工作區路徑與權限驗收是否符合你的測試流程，再決定是否需要調整環境。這一步是部署評估，不代表 PTC Mode 已經提出新的硬體要求。你也可以將這些條件套用到 VpsMesh 的遠端 Mac 測試節點，先完成版本驗收，再決定是否長期保留該環境。

現有方案若是臨時租用的 Windows 或 Linux 主機，常見缺點是圖形介面驗收不直觀、遠端桌面與本機檔案權限容易分離，還要自行處理長時間工作階段、網路延遲與環境清理。若你需要的是短期測試、版本回歸或插件驗收，遠端 Mac 環境可以少掉本機硬體採購、環境重置與團隊共用主機的管理成本；但長期固定重負載、需要實體周邊或必須完全掌控底層系統時，自購 Mac 仍可能更合適。

07

後續重評：看到這些信號才升級處理

以下變化一旦出現在官方 Release、README、CLI 文件或配置文件中，就不應再把 PTC Mode 當成單純更名：

  • 官方新增 PTC Mode 的正式定義，而不只是名稱。
  • 官方列出新的預設插件組合或工具清單。
  • 權限政策、批准流程或工作區隔離方式改變。
  • 設定鍵、預設 ID 或配置檔格式出現遷移說明。
  • 發布說明要求使用者重新建立工作階段或重新驗收插件。
  • 官方文件明確說明 Code Mode 不再相容，或提供相容別名期限。

請以 官方 Release 頁面、官方使用指南和 Cordis 文件作為第一層依據；社群貼文可以用來發現疑問，但不能代替能力、權限或資源需求的官方證據。Cordis 本身仍在活躍開發，官方也提醒其 API 尚未穩定，因此更應避免把架構推測寫成產品承諾。(Cordis 官方文件)

本週可直接執行的檢查清單

  • [ ] 記錄升級前 Code Mode 的畫面名稱與設定引用。
  • [ ] 備份工作區、插件設定與團隊操作文件。
  • [ ] 升級 v0.1.0-rc.7，確認是否只出現 PTC Mode 名稱。
  • [ ] 檢查插件是否以舊名稱硬編碼。
  • [ ] 驗證插件註冊結果與設定卡片文字。
  • [ ] 執行一次只讀任務與一次需要批准的操作。
  • [ ] 比對工具清單、權限提示與工作階段是否正常。
  • [ ] 在文件中加入「PTC Mode／原 Code Mode」映射。
  • [ ] 暫不因名稱變化調高伺服器規格或建立獨立環境。
  • [ ] 等官方補充定義、配置鍵或遷移說明後再重新驗收。

最後的行動結論可以分成三類：若名稱、插件載入與權限行為都沒有變化，就繼續沿用；若只有文件、截圖或腳本文字需要調整，就局部修訂；若官方新增能力定義、權限模型或配置遷移要求，才進入重新驗收。在你確認現有設定受影響之前，不必把 PTC Mode 當成一次新的部署專案；先完成版本檢查與插件驗收，再決定是否調整遠端環境。