DeepSeek Harness API Key 儲存：2026個人與團隊選擇

官方 Python 範例明確使用 1 個環境變數名稱 DEEPSEEK_API_KEY 讀取憑據，而 API 本身以 Bearer Token 驗證。(api-docs.deepseek.com) 因此，本週的建議不是把所有密鑰都搬到同一個地方：個人 Web UI 試用可使用內置寫入式憑據儲存；Python SDK、CI 與可重建任務優先採用執行時注入的環境變數；共享雲端 Mac 則應由受限帳戶管理，避免多人共用同一把密鑰。

這篇文章適合三類人：在個人 Mac 上首次配置 DeepSeek Harness 模型的開發者、維護共享或遠端 Mac 環境的平台工程師，以及需要制定輪換與離職回收規則的團隊負責人。若你只想知道哪個按鈕最方便，答案很短；若你要對「誰擁有密鑰、誰能讀取、誰負責更換」負責，請繼續看完整判斷。

SECTION 01 DeepSeek Harness API Key 儲存，先看密鑰由誰負責

截至 2026 年 8 月 18 日 核對的行為，Web UI 儲存後，設定檔會保留憑據引用，頁面只回傳脫敏描述，而不是再次展示完整密鑰；官方模型配置指南確認其寫入位置為 $DSH_HOME/.credentials.yaml。這代表「畫面看不到」不等於「本機無法讀取」：能讀取該使用者家目錄、備份檔案或遠端工作階段的人，仍可能取得使用權。

個人互動試用時，內置入口通常是合理選擇，因為你不必把密鑰硬編碼到程式碼，也能讓設定與單一使用者的工作階段保持一致。不過，你仍要限制 Mac 登入帳戶、檢查家目錄備份範圍，並關閉不必要的遠端登入與螢幕共享權限。

真正容易被忽略的成本有三項：

• 所有權不清楚：密鑰若由某位開發者建立，卻被共享任務使用，離職或轉組時便很難判斷誰有權撤銷。
• 重建能力不足：憑據只存在某台 Mac 的使用者目錄，換機、重裝或切換執行帳戶後，任務可能無法啟動。
• 備份與紀錄外洩：設定檔、終端機歷史、錯誤輸出、工作階段記錄及自動備份，都可能把憑據引用、請求內容或敏感上下文帶到不應讀取的位置。

DeepSeek API 的官方驗證方式是 Bearer Auth；這也說明了為何你不應把 API URL、模型名稱或一段測試文字誤當成密鑰本身。(api-docs.deepseek.com)

SECTION 02 第一階段：按執行場景選入口，而不是按介面偏好選

下面的比較，重點不是「檔案比較安全」或「環境變數一定安全」，而是密鑰的生命週期是否能配合執行身份。環境變數若由共享帳戶啟動，仍可能被同一帳戶內的程式或診斷流程讀取；憑據檔案若權限隔離得當，也可以只讓特定帳戶使用。

DeepSeek Harness 保存的 API Key 在哪裡？
在已核對的版本行為中，Web UI 寫入 $DSH_HOME/.credentials.yaml，設定內容保留憑據引用，介面只顯示脫敏描述。你不應把這個檔案直接複製到工單、聊天頻道或版本庫，也不要因為檔名以點號開頭就當成「不可讀取」。

Python SDK 應該怎樣讀取 DeepSeek API Key？
優先讓程式從 DEEPSEEK_API_KEY 讀取，而不是把值寫進 .py 檔案。官方 Python 範例使用 os.environ.get('DEEPSEEK_API_KEY')，並以 https://api.deepseek.com 作為 API 位址。(api-docs.deepseek.com)

import os
from openai import OpenAI

api_key = os.environ["DEEPSEEK_API_KEY"]

client = OpenAI(
    api_key=api_key,
    base_url="https://api.deepseek.com",
)

上例刻意沒有展示真實密鑰。你可以在啟動程序前注入環境變數，但不要把 export DEEPSEEK_API_KEY=... 寫進提交至版本庫的啟動腳本、工作日誌或截圖。官方的命令列範例同樣以 shell 環境變數放入 Authorization 標頭。(api-docs.deepseek.com)

SECTION 03 第二階段：Python、CI 與遠端任務要綁定執行身份

Python SDK 的環境變數方案適合獨立會話目錄和可重建工作流程，因為更換密鑰時只需更新啟動環境，不必修改程式碼；但這個優點只有在「啟動者」清楚時才成立。若所有團隊成員都登入同一個 Mac 帳戶，環境變數只是把共享問題從檔案移到程序環境，並沒有真正完成隔離。

遠端自動化任務應按照下列順序設計：

1. 先建立執行身份：為 CI、排程或批次任務指定專用帳戶，不要以所有使用者共用的管理員帳戶啟動。
2. 再決定注入位置：讓任務啟動器在執行時提供 DEEPSEEK_API_KEY，不要把密鑰值放入專案設定。
3. 限制讀取範圍：只讓需要呼叫模型的程序取得環境變數，其他建置、測試或檔案處理步驟不必繼承。
4. 驗收輸出：檢查任務日誌、例外堆疊、失敗重試、會話記錄和除錯封裝，確認不會輸出 Authorization 標頭、完整環境內容或請求物件。
5. 定義失效訊號：密鑰撤銷或更換後，先接受新任務應立即失敗並回報清楚，再確認舊工作階段是否只保存模型與 Provider 識別，不會繼續持有可用的新請求權限。

遠端 Mac 能不能多人共用一個模型密鑰？
技術上可能，但不應把「能執行」當作「可管理」。如果多人共用一個密鑰，你通常無法從 Provider 端分辨是哪位使用者觸發請求，也難以只撤銷某個專案；客戶專案、內部專案與不同成本中心更不應預設使用同一把密鑰。

官方整合文件在不同工具中反覆採用環境變數或設定檔引用，而非要求把密鑰寫入程式碼；這支持「配置與程式分離」的方向，但不代表 DeepSeek Harness 已內置作業系統鑰匙串、企業秘密管理系統或自動輪換能力。(api-docs.deepseek.com)

SECTION 04 三種方案怎樣配合輪換與撤銷？

更換 API Key 後，舊會話是否還能繼續不能只看畫面上的歷史記錄。新請求是否成功，取決於該次請求使用的憑據；而舊會話中已保存的訊息、模型名稱與 Provider 標識，則是另一組資料。刪除憑據或更換 Provider 可能影響新請求，但你仍需在隔離環境確認舊會話的恢復、重試及錯誤表現，不能只依賴 UI 顯示。

提醒：「檔案沒有顯示完整密鑰」只代表介面採用脫敏或引用方式，不代表密鑰已不可讀取。請把檔案權限、程序繼承、備份、終端機歷史與遠端存取一併納入驗收。

安全敏感團隊至少要把五個動作寫入責任表：

• 建立：誰申請密鑰、用途是什麼、屬於哪個專案。
• 交付：誰把憑據交給哪個執行身份，是否留下不含密鑰值的證據。
• 使用：哪些程序可以讀取，哪些帳戶只能啟動任務而不能查看設定。
• 輪換：誰在更換前驗證新值，誰負責重啟相關程序。
• 撤銷：誰在離職、專案結束或疑似外洩時撤銷，哪些任務必須立刻停止。

SECTION 05 本週可執行的五步驗收時間表

第一步：列出所有執行者。
把個人 Web UI、Python 腳本、CI、排程服務與共享 Mac 帳戶逐一列出，並在每一列填寫密鑰擁有人、讀取者和輪換負責人。任何一欄寫不出名字或團隊角色，都先不要投入長時間任務。

第二步：為每個場景選單一責任邊界。
個人試用可使用內置憑據入口；SDK 與 CI 優先使用執行時環境變數；共享環境則建立受限任務帳戶。不要把同一把個人密鑰複製到多台 Mac。

第三步：做一次無密鑰重建測試。
在隔離工作目錄建立不含秘密值的設定模板，清除當前憑據後，以正確執行身份重新注入測試密鑰，確認程式能啟動、缺失時會明確失敗，而不是靜默改用另一個帳戶。

第四步：檢查洩露面。
搜尋 Git 歷史、shell history、CI 日誌、錯誤封裝、會話匯出、備份清單和螢幕錄影；只要發現完整密鑰，就先撤銷，再處理清理與重建，不能只刪除文字檔。

第五步：模擬輪換與撤銷。
以測試密鑰驗證更新、重啟、舊會話恢復和失效後停止訊號，記下時間、執行身份、受影響任務及驗證結果。若共享 Mac 無法區分使用者，回退到帳戶隔離，而不是繼續增加設定檔數量。

如果你正在規劃遠端 Mac，除了 API Key，亦應先看清楚遠端 Mac 的帳戶與權限管理能否配合你的執行身份設計；若需求包含臨時測試環境，也可以先比較可用方案與計費方式，再決定是否把長時間任務放到共享主機。

SECTION 06 最後的取捨：方便不應凌駕於所有權

如果你目前把密鑰放在個人 Mac、多人共用的遠端帳戶，或直接寫進 Python 程式，真正的缺點通常不是設定步驟多，而是無法追責、無法只替換一個專案，以及撤銷時可能讓所有任務同時中斷；對需要持續執行的工作，還會增加備份、權限和重建的不確定性。

因此，請先按你的身份選方案：個人 Web UI 試用採用內置憑據存儲，Python SDK 與 CI 採用環境變數，團隊共享環境則以受限帳戶和分專案密鑰為基本線。若你需要臨時算力或隔離的遠端測試環境，租用 VPSNIX 的 Mac 方案會比把同一組權限長期攤在現有共享 Mac 上更容易界定帳戶、任務與輪換責任；但若你需要長期固定重負載、實體介面或完全掌控硬體，直接自購 Mac 仍可能更合適。

在啟動 Agent 前，先下載或複製一份不含密鑰值的輪換檢查表，逐項記錄誰擁有、誰能讀取、誰負責撤銷；只要共享環境仍答不出這三個問題，就先完成隔離，再開始正式任務。