有個週日要來上課的學員來信，描述了一個我覺得很值得拿出來講的狀況。
學員的狀況
他在 M5 Max 上自己搭了「龍蝦」（一套本地多 agent 編排框架），一口氣建了七個 agent：秘書、寫信、報告、審核、研究、財務、主持。本地模型用的是 Nemotron 3 Super 120B。
結果表現很不好，常常 healthcheck 失敗、timeout 被踢掉，他完全不知道怎麼除錯。
我猜問題出在哪
看完他分享的架構，我猜大概有四個地方在拖後腿。
第一，這個開源模型的能力，我估大概相當於 Sonnet 3.5 的水準。讓它去做路由、調度這種要判斷的活，有點吃力。
第二，他的架構幾乎沒有 harness，只有純語言規則。整套系統靠「跟 LLM 講道理」在運作，沒有可以強制執行的骨架。
第三，上下文管理不佳。七個 agent 的上下文沒有適當整合，很容易就爆掉。
第四，整個 pipeline 過度倚賴 LLM。每一步都丟給模型決定，每次跑出來都混亂不固定，幻覺風險根本控制不住，出錯也難除錯。
我給他的建議
第一，harness 為重。先把事情簡單化，回到 Claude Code 或 Codex，把基本的 memory files 跟 hooks 設定好。骨架穩了，模型才有得發揮。
第二，分清楚哪些任務給誰。任務分派跟高複雜度的判斷，交給能力好的閉源模型；本地模型改去做低風險、重複性的活，或處理敏感資料。至於那些高確定性的任務——輸入固定、輸出固定——直接寫腳本就好，根本不用走 LLM。
第三，工具不是越多越好。龍蝦也好、LLM 也好，都不是萬靈丹。對現階段的他來說，pipeline 的可解釋、可追溯才是最重要的事。一個你看不懂、查不出哪裡錯的系統，agent 再多也是負擔。
一個我注意到的現象
我觀察到，裝龍蝦的使用者裡，好像很多人不一定清楚龍蝦到底怎麼運作。
這件事其實可以拿來收尾反思一下。大家都在追最潮的多 agent 框架，七個 agent 聽起來很厲害，但底下的基本功——harness、上下文管理、任務分派——沒先打好，框架愈大只會崩得愈快。
工具會一直換，潮的東西也一直換。但這幾樣基本功不會變。先把地基蓋穩，再去蓋七層樓。