DeepSeek 插件式框架把代理變工具

以前是模型順手做一切，現在是先拆成工具再讓代理動手。

我自己做 agent workflow 做到後來，最煩的不是模型答錯，是它太順了。工具一接、流程一串、demo 看起來超像那麼回事，結果要上線時才發現整套東西像一坨看不見邊界的膠水：誰能呼叫什麼、哪段程式在改狀態、出了事要怎麼追，通通糊在一起。這種東西在簡報裡很漂亮，進 production 就開始冒煙。

我這次去看的是 The New Stack 對 DeepSeek 開源 agent harness 的整理。它提到 DeepSeek 把很多能力做成 plugin，還把 WebAssembly 拉進來當可能的隔離層。老實講，我不會把這種安全敘事當神諭，但這個架構方向很值得拆，因為它逼你把邊界畫出來，而這正是很多 agent 系統最欠的東西。

把行為藏在模型裡，最省事也最危險

DeepSeek open sources an agent harness where everything is a plugin.

翻譯一下就是：它想把 agent 從「一個大模型加一堆隱性 helper」改成「一個殼，裡面掛很多名字清楚的能力」。這聽起來很無聊，但我碰過太多 agent 專案，一開始都說先讓模型自己做，後來才開始追問：誰准它碰網路？誰准它寫檔？誰准它改 production config？

我最不喜歡的就是這種做法：先把權限全開，等出事再補 guardrail。那不是工程，那是把問題往後拖。DeepSeek 這種 plugin-first 的思路厲害的地方，不在於它多炫，而在於它強迫你命名每一個能力。只要是 plugin，我就能看、能測、能版本控管，也能決定要不要讓它進 runtime。

我之前幫一個團隊看過一個很典型的 agent：模型可以讀文件、查 API、改資料、發通知，全部透過一個大 wrapper 混在一起。結果 bug 來了，大家只會說「agent 怪怪的」。怪個頭，根本是你把責任切成一團漿糊。

實操寫法很簡單：把 agent 能力拆成獨立模組，每個模組都有明確介面。不要讓模型直接碰整個系統。每個能力都要能單獨審、單獨測、單獨關掉。先這樣做，你才有資格談 agent。

• 一個 plugin 對一個外部系統，不要一包全包。
• 一個 permission boundary 對一個 plugin，不要共用權杖。
• 一個 action 對一個測試面，失敗才看得出來。

WebAssembly 有趣，因為它很會限制人

The New Stack 那篇文章把 WebAssembly 當成可能補洞的方向，我覺得這點有意思，不是因為 WASM 很潮，而是因為它天生就很會把東西關起來。它不是拿來讓你亂跑的，它是拿來讓你跑得沒那麼自由。對 plugin 執行來說，這種「不自由」剛剛好。

也就是說，如果 plugin 跑歪了，爆炸半徑可以小很多；如果某個 plugin 只需要一點點能力，你就只給那一點點能力。這比把一個一般用途 runtime 丟給 agent，然後祈禱 prompt 會自律，實在太多了。

我看過很多團隊先把 agent 做出來，然後才開始補安全，最後補成一堆 deny list。問題是 deny list 很容易在真實需求前面碎掉。WASM 不會自動幫你設計 policy，但它至少讓執行層不那麼鬆散。這件事已經贏一半。

如果你要摸這條路，我會先看 WebAssembly.org、WASI SDK，還有 Wasmtime。這些東西不是拿來裝懂的，是拿來真的把隔離跑起來的。

實操寫法：如果你的 agent 會跑第三方或半信任邏輯，就把 plugin execution layer 做成可替換的 sandbox。今天不用 WASM 也沒關係，但架構先照「之後可以換 runtime」去設計，輸入、輸出、權限都要明確。

Plugin 只有在可檢查時才有價值

我對 plugin 架構一直有一個很現實的標準：它是不是模組化，不是看名字，是看我能不能快速回答三件事：它能做什麼、誰做的、誰准的。答不出來，那就不是插件，那只是把風險切小塊而已。

這也是我覺得 DeepSeek 這種 harness 值得看的地方。它如果真的把 plugin 當第一等公民，就必須有 registry、版本、來源、簽章、權限這些東西，不然只是把一坨大 blob 拆成十坨小 blob，麻煩一樣沒少。

我之前看過一個內部工具接 agent 的案例，前端 demo 很順，後端卻沒人知道現在跑的是哪版 plugin。文件寫 A，實際跑 B，出事時還不能 rollback，因為根本沒人把 plugin 當 production dependency 管。這種運維債，通常都是 demo 掌聲結束後才開始收利息。

• 每個 plugin 都要有 manifest：版本、擁有者、作用範圍。
• 契約要小，能用 fixture 測就不要靠人眼猜。
• 每次 action 都要記錄 agent、plugin、input、result。

實操寫法：把 plugin 當正式依賴管。能簽章就簽章，能 pin version 就 pin version，能 review diff 就 review diff。若 harness 能從任何地方自動抓 code，你不是在做 plugin system，你是在等 supply chain 事故上門。

把 planning 跟 execution 分開，agent 才不會亂摸世界

我 debug 過最多的 agent 問題，其實都卡在同一個爛點：同一個元件又負責想、又負責做。這對 prototype 很方便，對有使用者、有預算、有資安審查的系統來說，超級不妙。DeepSeek 這種 plugin harness 的價值之一，就是它把這件事往比較正常的方向推。

翻譯一下就是：讓模型先提案，讓 plugin 去執行，而且執行前要有明確驗證。這樣你就能把 intent 跟 effect 分開看。模型想得很怪，你可以在動作前擋掉；plugin 真出包，你也知道是哪個 boundary 壞了，而不是整天喊「agent 自己亂搞」。

我很喜歡這個拆法，因為它讓人可以介入，但不必把整個流程手動化。planner 可以彈性，executor 必須嚴格。這兩個東西混在一起時，每次修正都像在補一個會移動的靶。

實操寫法：把 agent loop 拆成三段，plan、validate、execute。policy check 放在 plan 和 execute 中間。只要 plugin 會寫檔、打 API、觸發 workflow，就一定要經過模型外部的 permission gate。

你還可以順手把觀測拆開：被拒絕的 plan、plugin failure、unsafe request 分別記。數字一分開，你就不會再用「agent quality」這種空話吵半天，而是能直接修掉最爛的那一段。

開源真正有用，是因為邊界看得見

DeepSeek 把 harness 開源這件事，我覺得比很多人想的更重要。封閉平台可以很順，但你常常只能接受它的預設；開源至少讓你看到它怎麼切邊界。對 agent 系統來說，邊界就是核心，不是裝飾。

也就是說，不同團隊可以照自己的 trust model 去改，而不是被 vendor 的預設綁住。新創做內部 workflow，跟要碰客戶資料的公司，根本不是同一種問題，但大家都愛在 kickoff 會議上講「AI agent」講得像同一件事。

我一直對那種「我們很彈性」但其實只能接受預設值的平台很敏感。開源至少讓我能看 extension point 夠不夠真、文件夠不夠清楚、security model 是真的有設計，還是只是寫在簡報上。

如果你想拿這套思路去比別的工具，我會一起看 Anthropic 的 tool use 文件、OpenAI 的 function calling 說明，還有 Microsoft AutoGen。它們不是同一套，但都在處理同一題：怎麼給模型能力，卻不把整個家都交出去。

實操寫法：評估 agent framework 時，先讀 extension points，再看 examples。範例很會演，邊界不會。邊界寫得清楚，這套東西才有機會上線。

我明天就會偷走的設計

如果我今天要重做一套 agent stack，我會直接偷 plugin-first 這個形狀，其他先放一邊。我不會先問模型多聰明，我會先問：哪些能力一定要隔離、哪些動作一定要記錄、哪些事情預設就是不准做。

翻譯一下就是：harness 不是魔法盒，是控制平面。模型負責提案，plugin 負責窄範圍工作，runtime 負責算帳。這個心智模型比讓 agent 拿著一大串 prompt 在系統裡亂逛健康太多了。

我知道這聽起來比一般 agent 文章保守。很好，生產環境本來就該保守。真正好玩的部分是模型，真正值錢的是把風險收斂住。只要資料還在你手上，慢一點根本不是問題。

實操寫法：先挑一個最有價值的能力包成 plugin，隔離執行，加 audit logging，再慢慢加智慧。這樣看起來比較慢，但你不會在六個月後又把同一課補考一次。

可抄的模板

Agent harness design notes（可直接改成你的版本）

目標：把模型行為和工具執行拆開，讓 agent 可以被審、被測、被關掉。

1) Core loop
- Planner：只產生結構化計畫，不直接執行。
- Validator：檢查 policy、權限、風險。
- Executor：只跑已批准的 plugin action。

2) Plugin contract
每個 plugin 必須定義：
- name
- version
- owner
- allowed inputs
- allowed outputs
- required permissions
- failure modes

3) Runtime rules
- 不允許 plugin 任意讀寫檔案系統。
- 不允許 plugin 在未授權下發網路請求。
- 不允許 plugin 存取未授權 secrets。
- 每次 action 都要記錄 timestamp、plugin name、agent id、result。

4) Sandboxed execution
如果可以，把 plugin 跑在隔離 runtime。
若使用 WebAssembly，介面保持很窄：
- input: JSON 或 protobuf
- output: JSON 或 protobuf
- no ambient authority

5) Approval flow
plan -> validate -> execute -> log

6) Example plugin manifest
{
  "name": "ticket_creator",
  "version": "1.0.0",
  "owner": "platform-team",
  "permissions": ["jira:write"],
  "inputs": ["title", "description", "priority"],
  "outputs": ["ticket_id"],
  "policy": {
    "requires_human_approval": true,
    "allowed_projects": ["ENG", "OPS"]
  }
}

7) Review checklist
- 我能不能用一句話說清楚這個 plugin 做什麼？
- 我能不能在不壞掉整個 agent 的情況下關掉它？
- 我能不能追出它每次呼叫了什麼？
- 我能不能換 runtime 而不用重寫 harness？
- 我能不能證明它不會超出 scope？

8) Copyable policy prompt
你是一個 planning agent。不要直接執行動作。
請輸出結構化 plan，包含：
- objective
- required plugins
- data needed
- risk level
- approval requirement

除非某個 plugin 明確授權，否則不要假設你能碰任何系統。

這就是我會直接丟給團隊的版本。它不花俏，但它把危險的地方都攤開了，而攤開就是可控的第一步。

原始來源：The New Stack 文章。這篇拆解是我自己的翻譯、整理和實作化版本，延伸引用了 WebAssembly、WASI SDK、Wasmtime、AutoGen 等公開資料。