Agent 越可靠，可能是因為它少做一點事
我常把 agent 的可靠性問題想成模型能力問題，但 Meta 這個案例提醒我，真正的瓶頸可能是系統邊界。他們用約 1,300 行的 thin orchestrator，路由 20 多個 workflow 與 14 個專業 subagents，重點不是程式碼少，而是把 routing 與 reasoning 分開。
早期的 single agent 同時掌握三個 repository、三種語言與六個階段，production 中容易因上下文過載而 hallucinate。人工手寫 prompt 時成功率約 70 至 80%，不手寫只剩 10 至 20%。換句話說，流程知識原本藏在人類補 prompt 的行為裡。
重構後，router 只執行固定 protocol：讀 instructions、檢查重複、收集欄位、通過 reliability gate，再委派與回收。specialist agent 使用隔離上下文，只載入當下需要的 runtime knowledge。欄位 onboarding 從人工三至四天降到一小時內，約三分之二的變更也不再需要重大人工介入。
我會用四個問題檢查自己的 agent 設計：哪些步驟是 deterministic protocol，不該交給 LLM？每個 agent 是否只看到最小必要上下文？失敗能否在委派前被 gate 住？新增 workflow 是修改 prompt，還是套用可測試的 template？
這也說明 multi agent 不等於拆出更多聊天機器人。真正的模組化，是讓 orchestrator 保持無知，讓 specialist 對單一責任負責，再用協定與評估指標接起來。做 RAG 或 agent workflow 時，下一步不一定是換更大的模型，也可能是先隔離知識，並刪掉根本不需要模型參與的決策。
作者：陳思維