DeepSeek Creator Mode 能建立哪些插件？5 個工作流檢查重點

DeepSeek Harness 官方展示了一個 Pomodoro 計時器：使用者在 Creator Mode 輸入需求，代理載入 Cordis 插件開發技能、檢查執行環境，接著寫出插件檔案、安裝並驗證狀態。這段流程呈現了「用對話把功能接進代理工作環境」的可能性，但它是官方展示，不是獨立效能測試，也不能證明每個人的專案都能一次成功。

真正要評估的問題是：Creator Mode 多提供了哪一層能力？它怎麼接上原有開發流程，又會取得哪些資料與操作權限？如果正在比較代理工具，可先看AI agent harness 的執行環境如何影響工具與任務邊界；接下來聚焦 DeepSeek Harness 的插件建立與導入檢查。

一、官方 Pomodoro 展示新增了哪一步？

它示範以自然語言提出插件需求，再由代理建立檔案、安裝到 Harness 並檢查執行狀態。這說明操作入口可以是對話，不能據此推論產出的插件已適合正式環境。

DeepSeek 的產品頁展示，代理先載入 cordis-plugin-development 技能，再檢查可用介面，建立 package.json 與用戶端程式碼，透過 Plugin Manager 安裝，最後查看即時狀態。頁面記錄的這次示範耗時 5 分 24 秒，所指的是該次展示中的流程，並非一般任務的平均時間或可重現的效能數據。

Creator Mode 因而縮短的是「描述需求到接觸插件建立工具」之間的操作距離。插件仍需要符合 Cordis（DeepSeek Harness 使用的插件框架）結構、執行環境與可用介面。規格若變更，生成的程式也可能需要修改；即使安裝成功，功能是否正確仍要按實際輸入、錯誤情境和資料寫入逐項檢查。

「透過聊天建立插件，以擴充工具、技能與介面。」（DeepSeek 官方產品頁中文譯述）

這項新增能力落在工具與工作環境的擴充層。它和 DeepSeek Harness 的代理架構或自主修 Bug 能力不同：前者處理代理如何循環工作，Creator Mode 則讓使用者建立或設定插件，改變代理可使用的功能。關於 harness 本身如何組合工具和代理流程，可參考AI agent harness 的架構評估；兩者可能搭配，但不能當成同一項功能。

二、Creator Mode 擴充代理工作流的哪一層？

它主要協助建立或設定插件，讓 Harness 加上工具、技能或介面元件。模型、代理循環、執行環境與權限政策仍由整體 Harness 和當前設定共同決定。

DeepSeek Harness 採用「everything is a plugin」架構，官方原始碼庫說明其底層由 Cordis 支援，模型介接、工具、工作階段紀錄和代理循環等也以插件組成。對使用者而言，這代表插件可以插入既有組合，延伸特定能力；它不表示一段提示就能任意改寫所有系統行為，也不代表每個部署 profile 都提供相同功能。

Creator Mode 和自行開發插件的差別，主要是入口與操作方式。對話模式可以協助探索需求、產生程式和呼叫管理功能；自行開發則讓工程師直接控制套件結構、設定、測試和版本。兩條路最後都要面對相容性、授權、錯誤處理和維護，選哪一條要看團隊是否需要快速試作，或是否已有正式的發佈與審查流程。

做法	主要用途	導入前仍要確認
Creator Mode 對話建立	快速探索功能、產生初版插件	程式碼、套件內容、資料存取與測試結果
工程師自行開發	控制架構、測試和發佈流程	Cordis API、版本相容、維護人力與授權

官方文件把 Creator Mode 定義為可使用 Plugin Manager 與唯讀執行環境檢查的模式；插件設定屬於目前 profile，會影響該 profile 的工作階段並保留於重新啟動後。可見介面和具體設定需要依 profile 判斷，不能只因在某個 Web 設定成功，就假設其他環境也已啟用。

三、插件如何接上既有工作流？

先確認插件安裝到哪個 profile，再看管理結果、必要的重啟或熱更新狀態，以及工具是否能完成預期呼叫。設定存在不等於已生效，任務也不應在驗證完成前交給它處理真實資料。

DeepSeek 官方 MCP 文件提供第二個案例：開發者可以用提示要求在目前 profile 設定一個可連線的 MCP 伺服器，代理會建立只含設定的 bundle，安裝 MCP client，再測試伺服器的 ping 工具。文件要求同時確認管理結果為 application: applied，且實際工具呼叫成功；若顯示 restart-required，代表設定尚未在當下工作階段啟用。這是持續性設定流程示例，不是對任何 MCP 服務穩定度或安全性的保證。

第三個案例是社群 dsh-calendar。GitHub 專案將它描述為可連接 CalDAV 日曆的 Harness 插件，列出查看、建立、更新與刪除行程，以及匯入 ICS 檔等功能；專案頁列有 MIT 授權與程式碼、測試和建置檔案。社群插件目錄頁曾列出 0.13.4 版、Web 執行介面與更新紀錄，這些是目錄或專案提供的資訊，仍需在安裝時到原始碼與套件 registry 再核對版本、授權和相依項目。

這個案例也說明插件權限會碰到實際資料：行事曆登入資訊可能讓程式讀取或變更事件。即使程式自述以環境變數或憑證服務保存密鑰、遮蔽日誌，也要檢查密鑰如何注入、刪除功能的確認流程，以及匯入檔案是否包含外來指令或惡意內容。測試應用隔離帳號與無敏感資訊的行程，不應直接連接工作或個人主日曆。

「DeepSeek Harness 仍處於開發者預覽階段，可能出現相容性破壞變更。」（DeepSeek Harness 官方 GitHub 說明中文譯述）

插件挑選與安裝流程也可參考DeepSeek DSec 如何透過沙盒界定代理的操作範圍。無論工具來自官方或社群，來源可追溯只解決「從哪裡取得」的問題，並不能代替程式碼檢查、權限核對和本機驗證。

四、生成、安裝與使用有哪些限制？

不宜只憑生成或安裝成功就投入正式工作。Harness 官方仍標示為預覽，插件與 API 可能變動；使用者需檢查程式、相依項目、資料範圍與權限，並自行測試升級與回復方式。

外部插件程式碼、文件及 MCP 伺服器回傳內容都可能帶有不可信指令。若代理能存取整個專案、呼叫終端機或讀取憑證，錯誤插件可能造成超出原任務的讀寫或外連。先採最小權限：僅開放任務必要的資料夾和工具；用非正式憑證；記錄網路請求、檔案改動與插件輸出；安裝前閱讀套件指令和建置腳本。

相容性與維護也是原因層面的問題。開發預覽中的 API 若改名或改變生命週期，曾能安裝的插件也可能無法載入；官方 GitHub 的版本說明和安全提示應與插件自己的更新紀錄一起看。每次升級前保留可回復版本，在獨立 profile 測試停用、移除及重新安裝，確認舊設定和資料怎麼處理。這些工作會占用工程時間，不能只用第一次生成花多久來估算導入成本。

五、接入工具鏈前，先做哪五項檢查？

從一項低風險、可回復的任務開始，核對來源、相容性、權限、可驗證結果與維護成本。五項都能說明白，再考慮擴大使用範圍。

1. 界定任務：指定一個可用測試資料重做的工作，例如產生本機報表，不先連接正式資料庫或外部帳號。
2. 核對來源與授權：找到原始碼和套件發布者，確認授權、依賴套件、版本標籤及最近維護紀錄。
3. 縮小權限：用隔離 profile、測試憑證和最少資料，檢查檔案讀寫、終端機、外連與密鑰範圍。
4. 驗證結果與回復：準備正常、錯誤和邊界輸入，檢查輸出、日誌、管理狀態，並實際演練停用、移除或回到舊版本。
5. 記錄總成本：比較人工修正時間、任務品質、失敗處理時間、升級和維護工時，不只計算首次生成速度。

低風險試作若能穩定重現、權限範圍清楚，且維護成本低於工作流帶來的收益，才有擴大測試的理由。若插件碰到外部服務、正式憑證或不可逆資料操作，應先補上權限審核與人工確認點。這樣衡量的對象才是整段工作流，而不是一次看起來順利的示範。

• Creator Mode 把插件建立和設定帶進對話流程，官方 Pomodoro 案例呈現生成、安裝及驗證步驟。
• MCP 和社群日曆案例顯示，profile、版本、授權、憑證與資料讀寫都會影響插件是否適用。
• Harness 仍在預覽；先以隔離環境和可回復任務測量品質、權限與後續維護成本。

常見問題

Q1：DeepSeek Creator Mode 是 DeepSeek 模型本身嗎？

不是。Creator Mode 是 DeepSeek Harness 的插件建立與設定入口；Harness 是把模型、工具、工作階段及執行流程組合起來的代理環境。

Q2：官方 Pomodoro 展示能證明插件建立很快嗎？

只能說官方頁展示該次流程約 5 分 24 秒完成，不能當成不同任務、環境或使用者的平均成效。

Q3：安裝社群插件前至少要查什麼？

檢查原始碼、授權、相依套件、支援的 Harness 版本、維護紀錄及要求權限，並在隔離 profile 測試。

Q4：MCP 設定成功後怎麼確認真的可用？

除管理結果顯示已套用外，還要實際呼叫伺服器提供的測試工具；若需重啟，先完成重啟再測。