DSH 接本地 AI：工具能用之後，瓶頸才開始浮現

模型能在本機回答問題之後，下一步是讓它做事：讀檔、建立資料、修改文件，再用程式檢查結果。我選擇接進既有的 DSH（DeepSeek Harness），讓它管理工具與對話迴圈。

這輪確實完成了基本檔案任務，也遇到一個很有代表性的落差：一次診斷加日誌整理，完整流程花了 23 分鐘；但其中一段可解析快照裡，40 次工具執行合計只有 27.808 秒。工具本身的執行速度，解釋不了大部分等待。

本文記錄我與 AI 工具協作核對的歷史結果。第一篇的硬體受控基準、這篇的 agent 流程耗時，以及介面顯示的 tok/s，各有不同量測範圍。

實作接線：DSH 管工具，Strata 做本地推論

一次任務的路徑是：使用者提出工作 → DSH 組合提示與工具資訊 → 本地模型提出工具呼叫 → DSH 執行 → 結果回到上下文 → 模型決定下一步或回答。

這個區分很重要。Strata 直接聊天的 MCP 檢查當時仍是 servers=[]、tools=0；DSH 可以提供工具，不代表 Strata 自己的聊天介面已裝好 MCP。也不能因為模型在本機，就宣稱整條知識庫檢索流程都離線：檢索階段仍可能依賴雲端。

第一個瓶頸：一個任務會反覆支付模型等待成本

第一輪同時做工具診斷與日誌整理。完整 23 分鐘來自我的使用回報與更正；可解析的匯出檔只涵蓋其中一段，約 12 分 48 秒。以下數字僅屬於這份快照。

前兩段合計約 739.921 秒，約佔這段快照時間的 96%。這裡是模型回應階段，包含處理、等待與串流，不能全算成 GPU 推論；也不能把比例外推成完整 23 分鐘的精確分布。

第二輪 41 次呼叫的組成如下。它與整個匯出檔的 43 次不是同一範圍。

中間還遇到解壓格式不支援、安裝路徑錯誤、暫存寫入遭拒與腳本未簽署。檔案存在與雜湊核對約在本輪第 4 分 11 秒完成，解壓日誌直到約第 9 分 3 秒才成功。這些繞路會觸發更多模型輪次，所以「請模型自己分析日誌」也會改變原本要量的工作量。

第二個瓶頸：工具回傳越多，下一輪越重

一次目錄列舉回了 49,931 字元。緊接著一輪記錄 inputTokens=14,767，首個串流事件前等待 47.705 秒。

這是一個具體的上下文膨脹觀察，尚不是控制其他變因後的因果實驗。但它已足以提示下一輪測試：工具結果應只保留完成任務需要的路徑、欄位與錯誤片段，再比較提示長度與完整耗時。

當工具迴圈持續累加，速度不只取決於生成每個 token 多快。每次重新送出的工具描述、歷史對話、目錄輸出與錯誤訊息，都可能增加 prefill 或後續決策成本。

同一快照另有 inputTokens=28,112、outputTokens=6,243、cacheReadTokens=1,148,409。這些是逐步累計欄位，不能把 114 萬 cache tokens 說成單次塞進超過百萬 tokens 的上下文。

第三個瓶頸：快取有效，要看請求長什麼樣子

硬體測試中，一次 22,664-token 請求花 34 秒讀提示、19 秒生成 524 tokens，prefill 約佔兩段時間的 64%。這能解釋為什麼只盯 decode tok/s，常常錯過主要等待。

我也測了 Strata 的 message-boundary cache。情境刻意固定長歷史，只替換最後一則短訊息：

約 84 倍是這個特定重用段落的時間比，不是 DSH 整體加速。第一次測試的前綴只有 7,551 tokens，未達當時文件的 8,192 門檻，因此沒有觸發；修正測試設計後才得到上表。文件的另兩項條件是尾端不超過 1,024 tokens，以及固定前綴逐字相同。

我的實際 DSH 聊天是累加歷史，當時觀察第一句約 30 秒、第二句明顯變快，符合既有 prompt cache 可重用的形狀；沒有證據顯示再開 message-boundary 開關能帶來額外收益。知識庫則每題送全新單輪請求，不符合這次固定長歷史的測試情境，因此最後沒有採用。

「功能有加速效果」與「這個應用能取得該效果」需要兩次驗證。原始效能筆記曾把 SELECT／生成／REVIEW 當成三次本地模型呼叫，後來查碼修正為檢索流程階段；公開結論採用修正後的資料流。

機制參考：Strata message-boundary cache 文件。本文門檻與實測以 2026-10-12 的版本紀錄為準，上游可能更新。

第四個瓶頸：成功旗標與工具清單都不等於驗收

這輪核對日誌時，修正了三個容易被成功報告掩蓋的問題。

因此工具驗收要同時看 exit code、stderr、回傳內容，以及實際產物。對 provider 問題，則要在去除憑證與私人內容後，核對送到 API 的工具 schema、請求與回應；模型自述「我沒有工具」不能取代這些證據。

把任務縮小後，完成了什麼？

下一輪開新 session，只做一個受限檔案任務：建立 CSV，讀回資料，寫摘要，改狀態，再用 PowerShell 的 Import-Csv 獨立計算。

結果回報摘要含「狀態：已驗證」，沒有「狀態：初稿」。input.csv 為 38 bytes，summary.md 為 165 bytes。這輪材料是模型完成回報與 UI 截圖，未另取得原始 JSONL；產物大小與時間都保留這個證據等級。

38 秒從首個 pwsh 取時開始，不含使用者送出到第一個工具的等待，也不含最後回答生成。UI 的步數與工具呼叫數不同；35 tok/s 與緩存百分比的完整計算口徑未查明，不用來推導引擎速度或命中率。

這一次重試也有明確原因：測試提示要求 write 後直接 edit，卻漏了工具規則中的「編輯前先 read」。補讀後修改成功。這個額外失敗來自任務流程設計，不能直接扣成模型能力不足。

因此，23 分鐘與 38 秒不構成加速倍數。前者包含診斷與日誌整理，後者是受限小任務，計時邊界還不一樣。同樣地，先前 UI 的 8.4 tok/s 與後來 35 tok/s，約 4.2 倍的顯示值比，也不是受控效能進步。

接下來該怎麼驗，而不是繼續混在一起測

下面是尚未完成的新一輪驗收設計，不把預期結果當成成果。

1. 固定新 session、模型、非思考設定與相同資料；只允許讀寫指定測試目錄。
2. 在 edit 前明確加入 read。修正後預期八次工具呼叫、零重試，實際仍需跑過確認。
3. 不混入套件安裝、環境搜尋或日誌解壓，讓工具任務本身保持固定。
4. 從按下送出計到最後回答，另外保留每輪等待、工具執行、提示長度與輸出量。
5. 結束後由外部核對產物；不要追加「請自行分析所有日誌」而改變被量測流程。
6. 若比較不同 provider，使用相同任務與獨立新 session，每次只改一個變因，保存去識別請求與回應。

更大型的程式修改、長時間穩定性、剩餘工具、網路搜尋與整體回答品質，都不能由這個 CSV 任務代為驗收。

我對本地 Agent 的實作判斷

DSH 接入這份本地模型，已經讓讀寫、編輯與命令驗證成為可觀察的工作流程。下一個問題是：在真實任務裡，能否控制每輪上下文、避免無效繞路，並用產物證明完成？

這輪資料把優先順序拉得更清楚：先限制工具輸出的範圍，改善任務步驟，再量完整等待；模型的品質、硬體吞吐與 harness 行為則各自保留測試。這樣才知道下一次改善來自哪裡，也知道哪些失敗還沒解決。

資料來源與閱讀範圍

數據主要取自 2026-10-12 的工具診斷更正紀錄與效能驗證紀錄。第一輪有經解析的 JSONL 與產物雜湊核對；完整 23 分鐘由使用者回報；第二輪約 38 秒來自完成回報與 UI 截圖。原始 session、私人檔案與主機位置未公開。

硬體與模型的完整配置、三題品質測試及七項優化評估，見：16GB 外接顯卡跑 125B 本地 AI。延遲量測方法見：RAG 變快了多少？先說清楚量的是哪一段。