Model Interface for Agent Orchestration
Model Interface for Agent Orchestration 指一種產品形態：把 multi-agent / multi-model orchestration 包成單一 model endpoint。使用者看見的是一個 OpenAI-compatible API；底層則由供應商負責模型選擇、角色分配、agent communication pattern、驗證與成本封裝。
sakana-fugu 是目前 wiki 中明確符合這個形態的例子。它把自己稱為「Multi-Agent System as a Model」，主張不靠人手設計 team organization、roles 或 workflows，而是讓系統學習如何從模型池中動態組裝與協調 agents。
與傳統 agent framework 的差異
| 面向 | Agent framework / workflow engine | Model interface orchestration |
|---|---|---|
| 使用者看到的介面 | SDK、graph、tool loop、workflow definition | 單一 model / chat completions endpoint |
| 編排責任 | 開發者設計 roles、tools、handoff、memory、eval | 供應商在模型層封裝 routing / coordination |
| 可觀測性 | 可自行記錄 trace、tool calls、intermediate artifacts | 可能只看到最終回答與 token usage |
| 可控性 | 高，但維護成本也高 | 低到中；依 provider 是否允許 opt-out / policy 設定 |
| 適合情境 | 需要深度客製、內部工具、嚴格治理 | 想快速取得 multi-agent 性能、既有 OpenAI API 客戶端可直接接入 |
核心判斷
這個模式對 agent-framework-selection 的影響是：選型不再只是「要不要自建 agent framework」，還要問 orchestration 是否應該下沉到 model provider。
可以下沉的條件：
- 任務主要追求 hard reasoning / coding / research quality，而不是強依賴內部工具狀態。
- 可接受底層 routing 不透明，只要求最終輸出品質與 token cost。
- 資料、隱私、供應商與地區合規限制能被 provider 的 opt-out / policy 滿足。
- 既有系統已用 OpenAI-compatible API，接入成本低。
不適合下沉的條件：
- 需要完整 trace、工具呼叫紀錄與中間 artifacts 作為驗收證據。
- 需要強制特定 harness-engineering-for-ai-coding gate、sandbox 或內部權限流程。
- 敏感資料不能送到不透明 model pool，或 provider 無法保證不回訓。
- 任務需要可重播、可除錯、可版本化的 workflow，而不是黑盒「更強回答」。
與既有概念的關係
- 對 agent-teams-vs-dynamic-workflows：它把 agent teams / dynamic workflows 從應用層編排，推到 provider 層黑盒編排。
- 對 model-harness-fit：它讓 harness-fit 不只看單一模型，也要看 provider 的 orchestration policy 是否貼合任務分布。
- 對 agent-trace-observability：它可能提高輸出品質，但降低 intermediate trace 可見度；企業若需要審計，必須補外層 logging / eval gate。
- 對 agent-framework-selection：它提供「買一個 orchestrated model endpoint」這條第三路線，介於單一 frontier model 與自建 deep agent stack 之間。
Google Cloud 的生成式媒體指南提供相鄰但不同的對照：Gemini 可作為主要 agent，圖片、影片、音訊模型則作為可呼叫工具，由 ADK 在應用層把它們串起來。這不是把整個 orchestration 隱藏成單一 model endpoint，而是保留工具、評估、成本與素材 provenance 的控制面；因此 generative-media-agent-workflow 更接近可治理的 application-level orchestration。
OpenRouter / Stripe 案例：閘道也是成本控制面
BusinessNext 2026-08-20 報導 Stripe 宣布收購 OpenRouter；OpenRouter 被描述為連接多家供應商與數百個模型的中立 AI 模型閘道，依任務複雜度、價格、速度與穩定度把請求路由到合適模型。這補上本概念的一個實務變體：model interface 不只可以封裝 agent coordination，也可以把 model routing、推論成本管理與 token billing 放在同一個 control plane。
這個案例與 sakana-fugu 的差異在於，OpenRouter 的文章重點是跨供應商路由與經濟層，不是公開底層 agent team 如何協作。對 agentic-ai-cost-management 而言，閘道層可成為依任務分配模型、控制重試與觀察 token 消耗的邊界；但收購金額是《華爾街日報》報導、交易當時尚待成交條件，不能當作已確認的官方財務事實。