LangGraph 在客服流程上輸 18 倍——但這篇論文的射程比標題小很多
一篇標題寫著「Obsoletes」的 arxiv 論文。讀完發現：它打的不是 orchestrator 本身，是「single-model 跑 procedural workflow 還反射性包 LangGraph」這個動作。1,200 對話、effect size d=0.37-1.01，證據很硬——但射程比標題小很多。
最近看到一篇 arxiv 論文，標題很狂——In-Context Prompting Obsoletes Agent Orchestration for Procedural Tasks（Dennis et al., 2026-04）。
「Obsoletes」這字眼一出來我心裡先涼一截。因為我手上就有個跨 6 個 model 的協調 substrate 叫 mk-council，如果論文是對的，那是不是該拆掉？
讀完以後結論是：這篇論文沒打到我手上的東西，但它把「什麼時候反射性加 framework 是錯的」這件事講得非常清楚。值得分享。
論文在說什麼
三個域、1,200 段對話、同一個 Claude Sonnet 4.5。兩種架構打對台：
- A 組：用 LangGraph 把客服流程畫成 state graph，每到一個節點 framework 把該節點的 prompt template 注進去再 call LLM，分支點再多打一次 routing call
- B 組：把整張流程圖（所有節點 + 邊 + 條件）序列化塞進 system prompt，讓模型自己決定下一步
結果 B 組 15/15 指標全勝。更扎眼的是失敗率：
| 領域 | In-Context | LangGraph |
|---|---|---|
| 旅遊預訂（14 節點） | 11.5% | 24% |
| Zoom 技術支援（14 節點） | 0.5% | 9%（18 倍） |
| 保險理賠（55 節點） | 5% | 17% |
作者歸納三個原因：orchestration 碎片化推理（模型每次只看單一節點的 template，失去全局視野）、引入新失敗模式（routing 分類錯、邊條件衝突、template 跟 context 打架）、約束模型自然能力（frontier model 本來可以 holistic 推理，被綁成填空機）。
真正被打到的是「反射動作」
論文打的不是 orchestrator 本身，是「single-model 跑 procedural workflow 還反射性包 LangGraph」這個動作。
這個反射動作有多常見？非常常見。腦袋裡的劇本通常是：「以後 step 越來越多會難管」「state 要有地方放」「視覺化方便 debug」「同事看 graph 比看 prompt 容易」——聽起來都很正當。
但這篇論文等於說：不要這樣做。把整條 pipeline 步驟全寫進一個 long prompt 給 Sonnet 自己 self-orchestrate，失敗率比 LangGraph 路線低一個量級，而且 procedure 全在 system prompt 還能吃 prompt cache 紅利。
更狠的是它順手量化了「為什麼這樣做更好」：
- Reasoning 不碎片化：模型看到整張地圖，知道「現在在哪、要去哪」，consistency 從 4.32 拉到 4.96
- 沒有 routing call 引入的失敗：LangGraph 那 1.2–1.7× 多出來的 LLM call 全是潛在 error source
- 不是越多 framework 越穩，是越少越穩
接下來如果有人想做下列任何事，這篇是直接的反證素材：
- 把客服流程包進 LangGraph 管狀態
- 為了 multi-step LLM workflow 引進 CrewAI / Google ADK
- 為了「架構看起來先進」加一層 framework
- 把 single-model 工作流硬塞進 state machine
不要做。把 procedure 寫進 prompt 就好。
那為什麼 mk-council 還活著
論文 §5.3 自己列了四個 orchestration 仍有價值的場景，第一條就是「Multi-model pipelines」——不同步驟用不同 model（視覺模型 → code 模型的 handoff），這種 heterogeneous pipeline 作者明文說 out of scope。
mk-council 做的事剛好在這條 exemption 裡：它是 multi-model router（Claude / Codex / Gemini / Max / gemma4 之間 routing），每個 model 收到任務後內部都是 in-context self-orchestrate（沒有人在 Codex 外面再加一層 LangGraph）。論文打的是「single-model 包進 orchestrator」，不是「multi-model 之間有 router」。
而且我自己 mk-council 的設計規則裡有條 bypass clause：mk-council degraded 時 client 必須允許走 direct call，orchestrator 不能是 only path、只能是 default path——這個方向跟論文的精神一致。
收尾
論文標題的「Obsoletes」太強，作者自己 §5.3 退讓很多。真正成立的版本是：
對於 frontier model 跑 single-model 純對話的 procedural workflow，把流程寫進 prompt 比寫進 state graph 更好。
這個小範圍裡的證據很硬——1,200 對話、effect size d=0.37–1.01、兩個獨立 judge（Claude + GPT-4.1）都顯著支持。
下次反射性想加 orchestrator 時，先停一下，問自己一句：「我要解的是 multi-model 還是 single-model 問題？」
如果答案是 single-model，那 prompt 本身就是 orchestrator。
論文連結：arXiv:2604.27891
作者：Dennis, Diamond, Patil, Shabahang, Guo（i14 / University of Melbourne）
發表：2026-04