如何用 DeepSeek Harness 控制瀏覽器

DeepSeek Harness 可以控制真實瀏覽器，但本機 DSH Web UI 並不是瀏覽器控制器。它需要外掛與瀏覽器 runtime。Tabbit 發布的開源 DSH bundle 會載入 tabbit-browser Skill，再由 tabbit-cli 操作本機 Tabbit Browser。

需求已出現在社群。一位 r/DeepSeek 使用者寫道：「I have created so many plugins, that's crazy」，接著列出 Git、計畫、worktree、通知與介面外掛。瀏覽器控制符合相同模式：為 agent 新增環境能力，而不是重寫 agent loop。查看 Reddit 原留言。若要先理解大類，可比較瀏覽器自動化與只回答問題的助手。

重點結論

• DeepSeek Harness 是 DeepSeek AI 的開源 developer preview agent harness，核心架構是「everything is a plugin」。

• Tabbit 外掛提供 DSH Skill，由 Skill 呼叫本機 tabbit-cli，再連到 Browser-owned Runtime Service。

• 目前需穩定版 Tabbit Browser 1.9.0+，且與 DSH shell 位於同一主機。

• 命名 task space 隔離不同工作的頁面、狀態與回執，同一非無痕 profile 可沿用登入狀態。

• 這是能力接入，不是權限繞過；優先 API、先唯讀、不可逆動作須確認，遇到驗證碼應停止。

瀏覽器控制鏈路

DSH agent + Tabbit Skill + tabbit-cli + 本機 Tabbit runtime = 瀏覽器操作

這是一座 harness 到瀏覽器環境的橋，不會把遠端 shell 自動變成瀏覽器 agent。

DeepSeek Harness 是什麼

DeepSeek 官方發布頁將 harness 定義為幫助模型理解環境、使用工具並持續完成真實工作的層。DSH 基於 Cordis，模型、工具、skills、sessions、sandboxes、storage、loops、scheduling 與 UI 都可作為外掛掛載。

npx @deepseek-ai/dsh web

此命令啟動目前文件中的 http://127.0.0.1:3080 本機介面。需要區分瀏覽器中的 DSH 介面、公開網頁檢索，以及能導覽、點擊、填寫並驗證即時頁面的瀏覽器控制。Tabbit bundle 解決第三種需求，屬於瀏覽器 agents能力層，DSH 仍是協調者。

DSH 仍為 developer preview。官方 repository警告會有破壞相容性的變更。一位早期採用者也說「DSH is still pretty rough in a lot of places」。這是個人看法，preview 狀態則是官方事實。查看留言脈絡。

Tabbit 外掛如何運作

公開的 Tabbit-Browser/dsh-plugin repository包含 Cordis bundle、安裝工具與完整 tabbit-browser Skill。安裝後可用 skill({ name: "tabbit-browser" }) 或 /tabbit-browser 載入。

第一次工作會檢查國際穩定版 Tabbit 或國內穩定版 Tabbit Browser，至少一個達 1.9.0。開發版會被忽略。若瀏覽器缺少或過舊，DSH 建立背景下載工作，依地區選擇官方套件並儲存至 Downloads，但不會自動開啟 .dmg 或 .exe。

若瀏覽器符合要求但 runtime 缺少，Skill 會要求重新啟動一次 Tabbit，不會默默改用 Chrome、雲端瀏覽器、原始 CDP 或其他後端。準備完成後，tabbit-cli 在命名 task space 中執行；相同名稱可沿用頁面、JavaScript globals、回執與登入狀態。這更接近持續工作的瀏覽器自動化 agent，而非彼此無關的網頁抓取。

在本次提供的 source checkout 上，15 項 npm test 均通過，npm pack --dry-run 也正確列出 Skill 與參考檔。這驗證特定 commit 的套件邏輯，不代表每個網站或 DSH 版本都有端到端測試。

安裝步驟

先依官方文件準備 DSH，再執行：

dsh --version
dsh plugin --profile web add github:Tabbit-Browser/dsh-plugin
dsh web

若 DSH 已執行，請重新啟動並重新整理頁面。穩定版 Tabbit 1.9.0+ 要與 DSH shell 同機；runtime 未執行時，重新啟動 Tabbit 一次。

Windows 的受限 sandbox 可能無法存取 named pipe。只有偵測到瀏覽器、launcher 與 runtime process 都存在、但仍出現 BROWSER_RUNTIME_UNAVAILABLE 時，外掛才建議 Full Permission，不應預設使用。

第一次先下達有邊界的要求：

使用 tabbit-browser skill。打開此專案的公開 GitHub repository，閱讀 README，
用表格回傳安裝命令、最低 Tabbit 版本與已知限制。
不要登入、送出表單，也不要關閉我已有的分頁。

能做與不能做的事

Skill 透過 CLI 提供 Playwright 風格流程，可導覽、檢查可見狀態、點擊與填寫、處理多頁、擷取結構化資料、截圖、下載與驗證。推薦循環是：

檢查相關狀態 → 執行一組連貫動作 → 驗證結果

它能支援AI agent 瀏覽器自動化的公開研究、dashboard 檢查與受監督重複流程，但 DSH 必須連到瀏覽器主機 runtime；遠端 E2B 或 container 不會自動回連；外掛不偵測開發版、不自行啟動 runtime，也不替使用者執行安裝程式。真實 session 仍有登入過期、版面改變、權限、驗證碼與網站政策。

若不熟悉產品，可先讀什麼是 Tabbit Browser與Tabbit AI 瀏覽器完整指南。

低風險實作範例

先讓 DSH 檢查三個公開專案頁，收集最新 release 與系統需求，再回傳附來源的表格。DSH 管理目標、模型對話、權限與答案；Tabbit Skill 建立環境；tabbit-cli 在同一 task space 開啟來源並逐列核對。

一位討論日常網頁與 ERP agent 的社群成員得到建議：優先 API，把瀏覽器自動化當工具，並在 submit、pay、delete 前設人工批准。查看 Reddit 討論。研究保持唯讀並附來源；表單在送出前停止，這也是研究者 AI 瀏覽器較穩健的模式。

按工作選擇後端

dsh-better-browser 公開 repository是另一種架構：DSH 到 Kimi WebBridge 的 adapter。應依目標瀏覽器環境選擇。

另一位 Reddit 使用者認為真實機器與真實瀏覽器 session 更可靠，同時指出它較難擴展且有硬體管理負擔。查看原留言。這是個人經驗，不是規避偵測的許可。遇到驗證碼或網站拒絕自動化就應交還控制權。

安全邊界與是否適合

信任模型有四層：DSH 權限、外掛範圍、瀏覽器 session、網站動作。先使用唯讀或 workspace-scoped 權限；不要把密碼、API key、付款資料或無關私密分頁放進 prompt；不要擷取 cookies 或 browser storage；傳訊、敏感上傳、權限變更、購買與刪除前必須重新確認。

正式流程應保留 prompt、來源 URL、動作、結果與確認，並先在可還原 sandbox 或測試帳戶驗證。所有agentic AI 瀏覽器皆適用：session 越有用，權限越要審慎。

若你已在 DSH 同機使用 Tabbit、需要真實瀏覽器而非公開檢索，且可以監督動作，此外掛值得試用。若 agent 僅在遠端 container、現在就需要 production-stable API，或已有可靠直接整合，則應等待或選其他後端。

最小下一步是：從公開 repository 安裝 bundle，使用低風險獨立 profile，只讓 DSH 讀取一個公開頁面並附來源回覆。當環境檢查、動作與驗證都可理解，再逐步擴充。這是AI 瀏覽器真正實用的承諾：從意圖到可核驗動作的可見路徑。

Secholar.L

Tabbit 成長與內容

Secholar.L 專注 AI 瀏覽器與 Agent 工作流的實測寫作,基於真實調研比較工具,引用可查證的一手來源。