從 DeepInfer 到 DeepSeek Harness：為 Agent 劃一個可審計的範圍
第一個問題不是選哪個模型、接哪個 API，而是：這個 agent 只允許完成哪一件任務，它能讀什麼，能改什麼，不可逆的那一步由誰批准。
本文是由 SpringBrand 提供的、明確標示的客座文章。SpringBrand 沒有參與本站其他頁面的編輯，文中的技術主張都連結到一手資料。本站仍然是獨立、非官方的資料站。
上一篇客座文章畫出了棧：模型、DeepInfer 這樣的推理引擎、DeepSeek Harness 這樣的 agent harness，以及 agent 能呼叫的工具。這一篇往下走一步，把那張圖變成一次真實部署的範圍表。
多數團隊一開始問錯了問題：哪個模型最聰明、哪個 API 連接器最多、怎樣在週五之前把 agent 跑起來。這些問題後面再問。第一個問題要窄得多：這個 agent 只允許完成哪一件任務，什麼證據能證明它完成對了？
這個問題也是最便宜的失敗點。一個任務含糊、工具權限很寬的 agent，不是生產力勝利，而是一場等著發生的 incident——而審批人從沒見過它準備執行的動作。下面這套方法，就是在 agent 跑起來之前把邊界畫出來。
一個任務，一個終點
「研究一下我們的競爭對手」不是任務。它沒有停止條件，沒有可接受的產出，也無法區分一份有用的簡報和一堆看起來合理的段落。把它收窄之後，聽起來沒那麼宏大，但能跑：
「針對三個指定的預約類產品，比較它們公開幫助頁面對多門店支持的說法。輸出一份 300 字簡報，每條主張附來源連結和抓取日期，列出頁面沒有回答的問題，然後停止。不要聯絡廠商，不要使用客戶資料。」
這個範圍寫明了輸入、產出、證據和停止條件，也讓審批點變得清楚：市場負責人在簡報變成定位文案之前審閱。研究任務內部不發生任何外部動作。
換成 coding agent，等價物是倉庫路徑、測試命令和完成定義。換成客服 agent，是一個工單類別、允許的回覆集合和轉人工規則。形狀會變，紀律不變。
工具契約
任務收窄之後，列出它真正需要的工具。不是廠商有多少工具，也不是團隊下個季度可能會用的工具，而是把這件事從輸入推進到「可審閱產出」的那兩三個連接。
寫這份清單時，按後果分類，而不是按產品名分類：
| 動作類別 | 含義 | 例子 |
|---|---|---|
| 讀 | 取得已批准的來源或記錄，不改變狀態。 | 抓取公開幫助頁；讀取一條 CRM 記錄。 |
| 準備 | 起草、比較或標記，不對外發布。 | 起草簡報；建議一個 CRM 欄位更新。 |
| 寫 | 修改記錄或發送內部產物。 | 儲存筆記；建立工單草稿。 |
| 不可逆 | 對外發送、發布、付款、刪除或授權。 | 給潛客發郵件；發布頁面；退款。 |
多數第一次部署應該停在「讀」和「準備」。這不是保守，而是先驗證檢索品質，再決定要不要給它行動能力。SpringBrand 那篇梳理 agent 需要連接哪些工具的文章，從另一個方向說了同一件事：從一個業務問題開始，先解析帳戶或來源，只在任務需要時增加連接。
契約還要寫清工具失敗時怎麼辦。查詢超時不等於「沒有記錄」；憑據過期也不等於空結果。如果任務分不清這兩種狀態，審閱者就無法判斷他看到的是一個已驗證的空白，還是一條斷掉的連接。
讀與寫，是憑據層面的決定
把權限寫成 prompt 指令很誘人：「不要刪除任何東西。」那不是控制。真正的控制落在憑據、工具 schema 和執行層。
先給 agent 一個唯讀憑據。確實需要寫時，再給它一個獨立身份、窄 scope，並把寫動作放在沒有審批就調不到的工具後面。不要因為方便就複用人類管理員的 token。如果 agent 能碰到管理員能碰到的記錄，一次 prompt injection 就有同樣的觸達範圍。
SpringBrand 的AI agent 安全指南在這裡很好用：先畫資料、工具、身份和動作的邊界；把讀權限和寫權限分開；把外部內容當作不可信輸入；把授權留在模型之外。最後一條最常被跳過。網頁裡可以有一句指令，但它不能授予權限。
DeepSeek Harness 在執行時也提供了同樣的接縫：scoped 工具註冊表、審批策略、沙箱模式和只追加的工作階段日誌。它們不會替代你的存取模型，但給了你執行存取模型的位置。
在不可逆的那一步之前放一個人
審批點不是「流程裡的某個地方」，而是不可逆動作之前的最後一步，而且要讓審閱者看到即將發生的具體內容：收件人、主旨、正文、目標地址、金額或記錄變更。
郵件發出去之後再審批，只是通知。發送前三步審批，可能審的是一份中途已經改過的草稿。審閱者需要看到最終要執行的動作，不是計劃摘要。
這也是 SpringBrand 那篇human-in-the-loop 工具對比的核心：在後果之前暫停，保留被審閱的版本，把決定和實際執行的動作綁定，並定義拒絕或超時後怎麼辦。無論工具是 Gumloop、n8n、Zapier，還是自建審批隊列，模式都一樣。
對 dsh 來說，這落在審批策略和工具呼叫邊界上。如果動作是「發送」，審閱者就該看到那封郵件；如果動作是「發布」，就該看到頁面和 URL。「批准這個任務」太粗了。
如果用 bot 團隊，先讀邊界
DeepSeek Harness 的社群外掛生態在長。一個例子是 DeepSeek Bot：它給 harness 加上具名 bot、bot 之間的訊息和群組聊天。它不是 DeepSeek 官方產品，也不是使用 dsh 的必需品。
但它是一個有用的案例。SpringBrand 那篇DeepSeek Bot 的角色與邊界，把一個研究簡報拆給來源收集、比較和起草三個 bot，然後問真正重要的問題：共享記憶放在哪裡，卸載後儲存的資料怎麼辦，誰在簡報被使用前核對來源？
這些問題會隨著 bot 數量放大。bot 團隊增加協調和模型用量，不會自動增加覆蓋。如果三個助手在複述同一個頁面，團隊得到的是更多文字，不是更多證據。只有當新角色有獨立工作——比如獨立核對引用——才值得加。
留一條人能讀的審計線索
無法被重建的 agent，不值得託付有後果的動作。至少記錄：
- 任務和已批准的範圍；
- 呼叫了哪些工具、輸入是什麼、回傳了什麼；
- 模型或提供方版本，以及 harness 版本；
- 誰批准了不可逆動作，他看到了什麼；
- 外部結果，包括失敗和超時。
dsh 的只追加工作階段日誌，是前三條的天然骨架。審批隊列和目標系統負責後兩條。關鍵設計是用一個穩定的 task ID 或 proposal ID 把它們串起來，讓審閱者的決定能對上實際執行的動作。
這也是「演示成功」過不了審計的地方。聊天記錄裡寫一句「done」，不能證明 CRM 更新發生了、郵件發出去了，或者審閱者批准的那版內容就是潛客收到的那版。
一頁範圍表
接第一個工具之前，先把這張表填完。哪一行空著，agent 就還沒準備好做那件事。
| 欄位 | 寫什麼 |
|---|---|
| 任務 | 一句話，帶停止條件和可接受的產出。 |
| 輸入 | 具名來源、帳戶和記錄；明確不做什麼。 |
| 工具 | 讀、準備、寫、不可逆動作，各自對應一個具名工具。 |
| 身份 | 用誰的憑據、哪些 scope、誰能撤銷。 |
| 審批 | 人看到的具體動作、誰批准、沉默時怎麼辦。 |
| 失敗 | 超時、拒絕、空結果、部分成功分別怎麼表示。 |
| 審計 | task ID、工具呼叫、審批和外部結果存在哪裡。 |
| 負責人 | 誰能停止 agent，誰對資料負責。 |
方法就這麼樸素。模型可以換，推理引擎可以換，harness 也可以換；範圍、權限和審計線索，才是讓這次部署站得住的東西。
想繼續看 agent 範圍、工具契約和審閱設計，SpringBrand 的agent 工作流博客收了這些例子背後的長文。把它們當設計參考，不要當自己工作流的測試替代品。
常見問題
這是 DeepSeek Harness 的安裝教學嗎？
不是。這是一套針對單個 agent 任務的範圍方法。安裝和執行時細節，請從 DeepSeek Harness 官方倉庫和本站上一篇客座文章開始。
用 DeepSeek Harness 必須用 SpringBrand 嗎？
不需要。dsh 是獨立軟體，這裡的方法也不綁定具體工具。SpringBrand 提供 API、外掛和指南；用不用是實施選擇，不是前提。
DeepSeek Bot 是 DeepSeek 官方外掛嗎？
不是。DeepSeek Bot 是社群外掛，不屬於 DeepSeek Harness 倉庫，DeepSeek 也不審核社群外掛。使用前請審計程式碼和權限。
第一次應該接幾個工具？
兩三個真實任務需要的。更大的目錄不會拯救一個含糊的範圍。先接讀和準備類工具，量出產出，再決定寫或不可逆動作值不值得加。
來源
- DeepSeek Harness 倉庫 — README、許可證、developer preview 說明、啟動命令。
- DeepSeek Harness 架構文件 — profile、bundle、工具註冊表、工作階段日誌。
- DeepSeek Harness 安全說明 — 沙箱與審批建議。
- 推理之上的一層 — 本站上一篇客座文章，講四層棧。
- DeepInfer 的限制 — 為什麼推理引擎不是完整服務棧。
繼續讀：比較總覽，或DeepInfer 的架構。