系列：「邊做邊補：用一個 AI 代理 mesh 專案，補齊 AI 工程師該有的能力」— 第 14 天
紀錄日期：2026-09-21
能力區：第 9 區 評估（兼第 6 區 Coding Agent、第 12 區 多 Agent 協作）｜類型：做

本機工作草稿，尚未貼到網站。這次練習選型與故障注入，不因測試數量調高能力分數，也不宣稱已驗證真實免費額度。

專案裡哪件事逼我用到

要讓Spectyn輪流使用多家免費LLM API，我得選一個gateway。README常寫OpenAI相容、automatic fallback、很多免費token，但這些詞沒有回答：串流中斷會不會假成功？工具參數會不會被丟？免費池耗盡會不會跑去付費模型？

這次先固定五個專案的commit，再建立能看見錯誤的實驗。

把證據分成三層

第一層是來源分析：授權、設定、路由、儲存、預設監聽與驗證方式。free-api-gateway缺LICENSE，是選型上的未解條件；OmniRoute不同啟動方式的API key與監聽預設不同，要明確設定，不能假設本機啟動就只開在本機。

第二層是執行真實模組或HTTP handler，用合成上游控制429、401、正常回覆、工具片段與中斷。這可以重現協定行為，但不代表真實模型品質或真實免費額度。

第三層才是Spectyn CLI端到端接線。FreeLLMAPI和free-llm-router做到這層；9router、OmniRoute及free-api-gateway本輪仍是targeted模組或handler測試。報告明確標出差別。

我怎麼避免假通過

每個fallback測試都記錄實際上游呼叫順序，不只看最後答案。第一家必須真的收到請求並回429，第二家才收到後續請求，才算切換。

工具串流測試重組分段的id、函式名和arguments，再比對完整JSON與中文內容；下一輪也檢查tool_call_id和結果。只搜尋輸出是否含tool_calls字樣太弱，這項判準在審查後加強。

中斷測試要求上游只被呼叫一次，已輸出的前綴不重複，error後不再有內容事件。HTTP200是SSE連線建立狀態，不能拿來當整次任務成功。

測試自己也出錯過：最初多個情境共用gateway狀態，清除cooldown沒有重置全部評分與選路條件，後面的401與429情境根本沒走到預定第一家。後來改成每個情境新程序、新記憶體DB。401還會觸發健康檢查GET，而最初fixture只接受POST；這個測試環境缺口也修正了。舊結果保留並標為被取代。

最有價值的RED在自己的產品

FreeLLMAPI收到不完整上游串流後送error＋DONE，gateway側錯誤有浮現；Spectyn卻把部分文字包成done、exit0。

本輪FreeLLMAPI本機15項判準14通過、1失敗。不能用多數通過把最後那個失敗平均掉：對自我開發迴圈而言，假成功會使後續測試、紀錄與升級做錯決定。

測試數量不是排名

FreeLLMAPI相關既有測試46＋67通過；9router43通過、2失敗另4個probe通過；OmniRoute54通過、1失敗另14項安全政策通過。這些選取範圍不同，不應合成一個分數。

free-api-gateway有11個探針，但部分判準是在重現stream工具丟失或計數問題，不能把腳本exit0寫成11個功能正常。free-llm-router的10項判準6通過、4失敗，也不能因最簡單CLI接線成功就忽略它的stream與quota缺陷。

真實本機模型補測還有另一種差別：Ollama成功被呼叫，卻未遵守精確輸出格式。這筆是執行成功、格式驗收失敗；不是網路失敗，也不是模型整體能力結論。

這次留下的工程決策

先用FreeLLMAPI作可替換模型sidecar；任務、工具、權限、記憶與eval仍由Spectyn管理。修正Spectyn串流失敗判定後，再測真實免費provider與共享額度。

auto不等於free-only；免費池要明列允許的provider/model。相同帳戶多key可能共用額度，gateway的本機計數也未必知道其他設備的消耗。兩層重試還可能放大嘗試次數。這些都應變成下一階段的驗收條件，而不是先寫進產品宣傳。

原始資料與設定模板位於docs/specs/demo-monday-mesh/reports/evidence/m5/2026-09-21-free-gateways/。RC-071仍是draft-candidate；本輪沒有產品修正、部署或正式採用。透過可重現的失敗先找出邊界，才知道下一個小任務該修什麼。

本輪來源

• FreeLLMAPI
• free-llm-router
• free-api-gateway
• 9router
• OmniRoute