WorkBuddy 證明了 Agent 可靠性不靠大模型本身

200+條可驗證清單才是可用 Agent 的起點。

我站在這一邊：可用的 Agent 不是模型能力自然長出來的，而是 Harness 工程把它釘成了產品。

WorkBuddy 這篇復盤最有價值的地方，不是再講一遍 LLM、MCP 或 Tool Call，而是把一個現實事實說透了：同樣的模型，進了不同的上下文、權限、驗證和交接機制，表現會像兩個產品。文章裡反覆強調的不是「模型更聰明了」，而是工具接入、上下文組織、權限邊界、結果驗證、回饋糾正和跨會話延續這些產品側機制，決定了 Agent 能不能在生產環境裡把任務做完。這個判斷很硬，因為它對應的不是抽象理念，而是 WorkBuddy 對國內模型相容、穩定執行和長任務接續的實際效果。

第一個論點

長任務最常見的兩個崩點，文章說得很清楚：一種是 Agent 一次承擔太多工作，跑著跑著上下文耗盡，最後只留下半成品；另一種是它看到部分成果就過早宣佈完成，結果把未驗證的內容當成已完成交付。這不是「模型不夠會想」，而是執行鏈條沒有把任務拆開、驗收和交接做紮實。WorkBuddy 的回應是把任務拆成更細的步驟，把每一步的完成標準寫清楚，再讓 Agent 一次只做一件事。

Anthropic 的 long-running agents 經驗正好提供了對照：初始化 Agent 負責把工作拆成 200+ 條具體行為描述的功能清單，每條都標 pass/fail，禁止刪條目、降標準；Coding Agent 只負責執行當前項，靠統一啟動腳本、進度文件和 Git 歷史完成跨會話交接、恢復和回滾。這套設計的重點不是「更囉嗦」，而是把長任務從一次性賭命，改成可恢復、可審計、可繼續推進的流水線。沒有這層 Harness，Agent 一旦中途偏航，後面所有聰明都只是在錯誤方向上加速。

第二個論點

文章把模型抽象成無狀態函數，這個前提非常重要。模型本身不記得上一次呼叫，也不會自動知道當前環境、當前檔案、當前權限和當前進度。產品要做的是把系統提示詞、工具、會話歷史、工作區規則、任務狀態和記憶組織成一份「此刻該看到什麼」的上下文，再讓模型基於這份上下文決策。WorkBuddy 不是把所有資訊一股腦塞進去，而是區分寫入、選擇、檢索、壓縮和隔離，避免無關資訊把判斷帶偏。

更關鍵的是，權限和高風險動作必須在模型外部攔住。工具呼叫裡，模型只是生成請求，真正持有 API Key、真正發請求、真正修改資料的是 Agent 執行層，所以審批、參數校驗、Sandbox 和審計日誌不能交給 prompt 口頭約束。文章舉的例子很直接：刪除、發佈、支付這類動作必須確認授權；工具結果過長要截斷並明確告知未完整；錯誤返回不能只給堆疊，還要告訴模型可修正參數和下一步建議。也就是說，Harness 不是包一層皮，而是把「模型會犯錯」當成系統常態來設計。

第三個論點

如果只有 Tool Call，Agent 最多只是一个能點按鈕的模型。WorkBuddy 把 Skill 和 Plugin 拉進來，才真正把「動作」和「流程」分開。Tool 負責一個動作，Skill 負責一類任務的做法，Plugin 則把連接、流程、規則、Hooks 和模板打包成可安裝能力。這個分層很重要，因為現實任務不是「查一次介面就結束」，而是「按倉庫規範讀規則、跑測試、生成說明、處理失敗、再發佈」。

文章對 Skill 的定義很務實：先讀 AGENTS.md 或 WORKBUDDY.md，再看 git status，識別變更範圍，按需跑格式化、型別檢查和測試，只有驗證通過才生成 PR，發佈前還要確認授權。這個流程的價值在於，它把經驗從「模型記住了一個好習慣」變成「系統強制執行的一套方法」。一旦任務類型變化，Skill 還能按版本更新、評審、回滾。相比之下，把這些流程直接塞進長期記憶，等於讓模型把局部經驗當通用真理，最後只會讓行為越來越飄。

反方可能怎麼說

反對者會說，這套 Harness 設計太重了。Agent 本來就應該讓模型盡量自由地規劃和執行，過多的清單、規則、Skill、權限門檻和驗證步驟，會把系統做成一個臃腫的工作流引擎。尤其在簡單任務上，層層約束會增加延遲、維護成本和上下文占用，甚至讓模型失去靈活性。另一個常見觀點是，模型能力成長很快，今天需要的工程護欄，明天強模型就能自己補上。

這個反駁只對一半。簡單任務確實不該上重型 Harness，但生產級 Agent 處理的從來不是單次問答，而是跨工具、跨會話、跨權限邊界的任務。只要任務包含外部狀態、可撤銷操作、長鏈路驗證和多人協作，系統就必須把錯誤關在模型外面。模型變強只能降低出錯概率，不能取消審計、權限、恢復和驗收。WorkBuddy 的價值恰恰在於，它沒有把可靠性押在「模型會自覺」，而是把可靠性寫進了執行結構裡。

你能做什麼

如果你是工程師，就別先追求「讓模型更會想」，先把任務拆分、狀態保存、工具返回、失敗重試、權限審批和驗收標準做成硬約束；如果你是 PM，就把「能用」定義成可恢復、可驗證、可交接，而不是只看一次演示；如果你是 founder，就記住 Agent 產品的競爭點不在 prompt，而在誰能把 Harness 做成可復用、可擴展、可審計的系統能力。