2026 DeepSeek Harness OpenTelemetry 怎麼配置才不洩露會話？

本週建議：先把 DeepSeek Harness OpenTelemetry 配置維持在 DISABLED，完成資料分類後再用 FEEDBACK_ONLY 做隔離試點；只有端點認證、傳輸邊界、失敗行為、停機收尾與資料刪除都驗證完成，才考慮 FULL。 這套順序適用於需要集中排查遠端 Mac 上 Agent 故障、又不能把完整會話內容直接交給外部接收端的平台與安全團隊。

這篇文章適合三類人：需要集中排查遠端 Mac Agent 故障的平台工程師、負責判斷會話資料能否離開執行環境的安全或合規人員，以及準備交付可觀察 DeepSeek Harness 環境的運維負責人。

先記住一個邊界： OpenTelemetry 是傳輸與觀察框架，不是自動完成資料脫敏的安全方案。只要會話、工具結果、檔案路徑或使用者輸入被放進遙測事件，TLS 只能保護傳輸途中，不能改變接收端已取得資料的敏感性。

SECTION 01 啟用前的資料分類

會話遙測不是普通執行紀錄

一般執行紀錄可能只包含啟動時間、錯誤類型與程序狀態；會話遙測則可能涉及更接近任務內容的欄位，例如：

• 使用者輸入及 Agent 回覆；
• 工具呼叫名稱、參數與工具結果；
• 工作區路徑、儲存庫名稱、分支或檔案識別資訊；
• 回饋標記、評分、錯誤上下文及工作階段識別碼；
• 可能間接暴露 API 金鑰、環境變數、客戶名稱或內部網域的字串。

DeepSeek Harness 的公開專案說明也顯示，Harness 會處理會話持久化、工具操作、成本追蹤與工作區檔案，因此不能把「只觀察錯誤」與「外送完整會話」視為同一件事。(github.com)

在開始 DeepSeek Harness OpenTelemetry 配置前，建立一張資料責任表，至少列出四欄：

如果資料所有者、用途或禁止內容其中一項無法確認，就不要用「先開啟看看」代替審批，直接保持 DISABLED。這也是你應在資料與隱私政策說明中對照的責任邊界。

SECTION 02 第一個里程碑：共享政策先於端點

三種模式不是日誌詳細程度

官方配置目錄確認遙測插件提供 DISABLED、FEEDBACK_ONLY 與 FULL 三種共享模式；它們代表不同的資料共享政策，而不是「少記一點」或「多記一點」的日誌等級。

• DISABLED：最穩妥的預設，適合尚未完成資料分類、處理機密程式碼，或不需要集中回饋的環境。
• FEEDBACK_ONLY：只在你已界定回饋資料範圍、並能確認不會夾帶會話正文與工具結果時，用於小規模試點。
• FULL：只有在資料欄位、接收端用途、留存期限、刪除責任與版本相容性都已驗證後，才進入評估範圍；名稱本身不代表內容風險已消失。

模式設定還應有明確的擁有者。建議將「誰可以修改」分成三層：部署人員可讀取、平台負責人可申請變更、安全負責人或指定審批者可批准 FULL。若設定散落在啟動腳本、環境變數及控制台，交付前要統一記錄有效值與優先順序。

SECTION 03 第二個里程碑：隔離 OTLP 測試

OpenTelemetry 的設定通常可透過環境變數或 SDK 設定檔提供；不同語言 SDK 的支援範圍可能不同，因此不能只把通用變數名稱貼進 DeepSeek Harness 就當成已生效。官方 SDK 配置文件也明確提醒，各語言對環境變數的支援並不完全一致。(SDK 配置說明) (opentelemetry.io)

配置檔可先採用不含真實憑據的佔位形式：

telemetry:
  sharing_mode: DISABLED
  exporter:
    protocol: http/protobuf
    endpoint: https://otel-test.invalid/v1/logs
    headers:
      Authorization: ${OTEL_TEST_AUTH}
    tls:
      verify: true

這段只表示配置結構，不能直接視為 DeepSeek Harness 的完整欄位名稱；實際鍵名、載入位置與版本相容性必須以目前版本的配置目錄及原始碼為準。端點、Header 與令牌不應在文章、工單或交付截圖中展示。

測試順序

1. 建立只含公開字串的隔離 OTLP 測試端點，禁止直接接入正式儲存區。
2. 核對完整 URL、/v1/logs 路徑、TLS 憑證驗證與網路出口規則。
3. 建立只能用於測試的短期服務憑據，設定最小寫入權限與可撤銷期限。
4. 先維持 DISABLED，啟動最小會話，確認本地沒有意外外送。
5. 切換至 FEEDBACK_ONLY，使用無敏感內容的單一測試任務。
6. 對照 Harness 產生的事件、測試端點收到的紀錄及網路連線記錄，確認目標一致。
7. 若資料欄位或目的地不一致，立即回退 DISABLED，不要以刪除接收端資料代替修正。

對 OTLP 日誌而言，官方規格支援 HTTP 傳輸、TLS、Header、壓縮及逾時等配置；目前配置參考列出的 OTLP/HTTP 單次匯出預設逾時為 10,000 毫秒，但 Harness 是否採用同一 SDK 預設，仍需以當前版本實作確認。(OTLP/HTTP 配置參考) (opentelemetry.io)

不要把端點可達當成資料安全驗收。 可達只證明網路路徑成立；你還要確認端點收到的欄位、認證範圍、接收端留存及刪除責任。

SECTION 04 第三個里程碑：脫敏與失敗邊界

這一階段要驗證的不是「有沒有看到一筆紀錄」，而是敏感資料是否在任何事件類型中出現。至少準備四組測試字串：

• 假 API 金鑰與假 Authorization 值；
• 假使用者輸入，包含像檔案路徑、電子郵件及內部專案名稱的樣本；
• 假工具結果，包含命令輸出與錯誤堆疊；
• 假儲存庫識別資料與工作區路徑。

逐一檢查接收端的欄位與屬性，不要只查看訊息摘要。OpenTelemetry 本身提供通用的資料模型與匯出方式，但不會替你決定哪些 Agent 欄位應該被遮罩；敏感資料處理仍要由應用程式、Collector 或接收端策略完成。(敏感資料處理指引) (opentelemetry.io)

失敗測試必須記錄事實，不要預先寫死「一定重試三次」或「一定丟棄」。依序執行：

• DNS 無法解析；
• TLS 驗證失敗；
• 端點回傳拒絕；
• 網路出口暫時封鎖；
• 端點恢復後重新執行正常會話。

每次測試都記錄五項結果：Agent 任務是否繼續、畫面是否阻塞、是否出現錯誤、是否產生本地暫存、恢復後是否補送。若版本原始碼沒有明確保證重試次數、佇列容量或丟棄策略，文章與運維文件就只能寫「需實測確認」。

SECTION 05 遠端 Mac 的停機與交接

轉入遠端 Mac 後，風險會多一層：你不只要控制資料，也要控制機器交接時誰仍能取得端點憑據與本地暫存。

建議按照以下五步完成：

1. 將共享模式改回 DISABLED，並保存變更前後的設定雜湊或截圖證據。
2. 停止 DeepSeek Harness 主程序及其背景工作者，確認沒有新的會話事件產生。
3. 等待導出器正常收尾；若超過版本設定的逾時邊界，記錄未送出紀錄的實際狀態。
4. 撤銷 OTLP 測試或正式端點憑據，清理環境變數、鑰匙圈項目及本地暫存。
5. 由接收端負責人確認測試資料刪除，交付文件則寫明刪除時間、範圍與責任人。

如果你需要更完整的遠端執行交接，可參考遠端 Mac 環境支援說明，並把遙測停用項目加入既有的租期結束驗收，而不是另存一張容易遺漏的私人清單。

SECTION 06 上線門檻表與停用清單

在評估 FULL 前，先用下面的門檻表做決策。任何一項回答為「否」，都應回退到 DISABLED，或最多停留在已受限的 FEEDBACK_ONLY 試點。

本週可執行的驗收清單

• [ ] 指定會話資料、工具結果與回饋資料的所有者。
• [ ] 列出允許用途及禁止上傳欄位。
• [ ] 確認目前版本的共享模式有效值與載入位置。
• [ ] 將模式設為 DISABLED，並保存初始證據。
• [ ] 建立隔離 OTLP/HTTP 測試端點與短期憑據。
• [ ] 使用無敏感內容的最小會話驗證目標與接收紀錄。
• [ ] 檢查使用者輸入、路徑、儲存庫資訊及工具結果是否外送。
• [ ] 執行 DNS、TLS、拒絕及恢復測試，不自行假設重試行為。
• [ ] 在遠端 Mac 停機前關閉遙測、清理本地憑據並撤銷端點權限。
• [ ] 取得接收端刪除測試資料的書面確認。

若你目前使用本地方案，常見缺點是觀察資料分散、遠端故障難以重現，而且停機時容易遺留本地設定與憑據；若改用一般雲端主機，則未必具備目標 Apple 環境，還要額外處理權限、網路出口及交接清理。對需要短期集中排查的團隊，租用 VPSNIX 的遠端 Mac，並把 DISABLED 起步、端點隔離及租期結束回收納入同一份驗收文件，通常比臨時拼裝一台長期主機更容易控制責任邊界；但若你需要長期穩定重負載、固定實體介面或完全掌握硬體，仍應評估自購 Mac。

若你只是要臨時算力、測試環境或一次性的 Agent 交付，先從DeepSeek Harness API Key 儲存指南與上述停用清單開始，再決定是否需要 VPSNIX 的遠端 Mac 方案。

延伸閱讀

• API 金鑰儲存與遮罩：先堵住敏感資料外洩入口
• 遠端 Agent 後台任務交接：補足觀測與責任邊界
• AI Agent 外掛安全：從權限隔離降低執行風險