多代理寫程式像分散式系統

Hacker News 一篇討論拿到 119 分、63 則留言。主張很直白：多代理寫程式，像分散式系統。說真的，這比很多 AI 宣傳文還貼近現場。

原因也很簡單。你一旦把工作切成 plan、design、code。再加 compile、lint、test。你就在協調多個獨立工作者。這時候，問題早就不是「模型會不會寫」。而是「每一步的狀態怎麼對齊」。

為什麼這個比喻很準

這篇 Hacker News 討論，從一個很務實的觀察開始。只要你加上階段和驗證點，系統就不再像單一聰明模型。它更像一個 protocol。每個階段產出一個 artifact。下一階段再吃進去。那就是共享狀態。

共享狀態不一定是資料庫。也可以是 markdown、diff、log、test result。講白了，這些東西就是工作記錄。它們不是裝飾品。它們是讓下一個 agent 知道前一步到底做了什麼。

這個比喻會紅，不是沒原因。LLM 的失誤很常見。它可能看錯 prompt。可能漏掉限制。也可能長任務做一半就飄掉。你不能把這件事當小瑕疵。你得把它當系統故障來設計。

• 常見階段：plan、design、code
• 常見檢查：compile、lint、test
• 流程形狀：DAG，加上 retry loop
• 討論中的一個估計：任務失敗率約 20%

20% 這個數字很刺眼。可是如果把 agent 當成 flaky node，就合理多了。你不會要求每個節點都永遠正常。你會問：哪個 boundary 能先驗證？哪個輸出不能直接往下傳？

檢查點比幻想可靠

這串討論裡，Michael Roth 的留言很有代表性。他講自己把工作拆成多階段。每一段都加 verification gate。deterministic checks 提供硬保證。agentic checks 提供軟判斷。這個分法很務實。

他還提到，自己是從 shell scripts 和 aider 開始做。後來才長成 MCP 和 CLI 的組合，還用 YAML 定義 stage 和 gate。這個路線很像很多台灣團隊的實作方式。先拼起來能跑。再慢慢整理成流程。

我覺得這才是 agentic coding 的真相。不是一個漂亮平台解決一切。是很多工具湊在一起。每個工具只負責一小段。然後靠檢查點把風險壓住。

“You can’t make the agent reliable on its own, but you can make the protocol reliable by checking at every boundary.”

這句話很實在。你沒辦法把 LLM 變成永遠正確。可是你可以把 protocol 做穩。每個 boundary 都檢查。壞輸出就卡在那裡。不要讓它污染後面三個步驟。

所以，別急著先加第二個 agent。先加 script、type check、lint、compile。這些東西很無聊。可是無聊的工具，才會產生穩定輸入。穩定輸入，才會讓下一個模型少亂猜。

跟真實 orchestration 系統比一比

討論很快就跑到 workflow engine。有人提到 Temporal。這個類比很有意思。因為它把兩件事拆開：基礎設施可靠，和語意可靠。這兩件事根本不是同一件。

Temporal 可以 retry activity，也可以保留 history。可是它不能保證每次呼叫 LLM 都吐出一樣的答案。這就是分水嶺。系統可以幫你把執行做穩。它不能幫你把意思做成 deterministic。

所以，multi-agent coding 真的比較像分散式系統。不是因為它很高級。是因為它真的有 retry、state、timeout、handoff。只是這些訊息不是封包。它們是自然語言、程式碼、規格和測試結果。

• Temporal 管 retry、history、workflow state
• OpenAI Codex 類工具負責產碼，但仍要外部檢查
• aider 很適合改碼，但還是得靠 repo 的 test 和 lint
• CI 和 scripts 負責抓 format、compile、dependency 問題

這種架構，已經很像 service mesh、job queue、eventual consistency。差別只在於，這裡的 message 不是 JSON。很多時候，它是人類語言。這也更麻煩。因為人類語言本來就會歧義。

所以流程越長，越不能靠直覺。你要把每個 stage 的輸出寫清楚。你要知道這一段是 spec，還是 plan，還是 patch。混在一起，只會讓下一個 agent 更容易發散。

競品和數據，差在哪裡

如果把這件事拆成產品面來看，差異就更明顯了。Temporal 是 workflow 平台。它管的是執行與狀態。Codex 類工具是生成器。它管的是產碼。aider 比較像互動式編輯器。它把模型拉進 repo 裡，讓你直接改檔。

這三者的角色不同。Temporal 偏流程。Codex 偏生成。aider 偏編輯。真正難的是把它們串起來。串起來之後，才會有 plan、generate、verify、review 這種可重跑流程。

如果拿常見指標來看，差異也很清楚。模型本身看的是 token 輸出品質。workflow 看的是成功率、重試次數、平均修復時間。CI 看的是 compile、test pass rate。這些指標不一樣。你不能只看一個。

• 模型層：token 品質、prompt 命中率
• 流程層：成功率、retry 次數、回滾成本
• 驗證層：compile pass、lint pass、test pass
• 協作層：review 時間、diff 大小、手動修正比例

我自己的看法很直接。很多團隊卡住，不是因為模型不夠強。是因為沒有把驗證前移。你把檢查放到最後，就會一直被大 diff 打臉。你把檢查放到每個 stage，問題就小很多。

這也是為什麼 agentic coding 不能只看 demo。Demo 常常很順。正式流程才會看到 retry、timeout、state drift。那些才是成本。

這波熱潮背後的脈絡

其實這不是突然冒出來的想法。軟體工程本來就一直在處理不可靠元件。以前是網路、磁碟、服務。現在多了一個 LLM。它會亂想。它會忘記。它會在長上下文裡走偏。這些都很像分散式系統的老問題。

差別只在於，現在你處理的不是機器節點，而是會說話的節點。這讓問題更難，也更有趣。因為你不只要處理 failure。你還要處理語意漂移。這也是為什麼很多團隊開始把 agent 當成 pipeline 元件，而不是神奇助理。

講白了，這一波工具的價值，不在於少寫幾行 code。它在於把工作拆細。把責任拆清楚。把每個輸出都變成可檢查的中間產物。這跟傳統軟體工程其實很像，只是現在多了一層自然語言。

如果你看台灣團隊的現況，很多人已經在做類似的事。先用 LLM 產 spec。再用 script 轉格式。再用 CI 擋錯。最後才讓人 review。這套做法不炫。可是很有效。

結尾：先把 handoff 做穩

我會給團隊一個很實際的建議。先挑一條最常失敗的流程。把它切成 3 段。每段都加一個 deterministic check。再把失敗紀錄寫下來。你很快就會看見，問題到底是模型、流程，還是規格本身。

如果你正在做 agentic coding，先別問「能不能讓模型一次寫完」。先問「哪個 handoff 最容易壞」。把那個地方修好，整個系統才會像系統。不是像一堆聊天紀錄。