115年5月1日的白天，我的小鳳凰 Agent 系統（Hermes）經歷了一場架構級的洗禮。今天想跟大家分享我如何嘗試「我獨自升級」，打造一支免洗的 AI 影子軍團，以及過程中的血淚踩坑紀錄。
這是一場由主大腦（DeepSeek / 扮演小鳳凰）、架構顧問（Gemini）、以及主力開發工頭（Claude）聯手推進的實戰。這篇文章我會盡量少用工程火星文，多用生活案例，希望能讓不管是開發者還是單純對 AI 應用有興趣的朋友，都能感受到這場「跨物種協作」的樂趣。
一、我獨自升級：用免費 API 打造「影子軍團」
我們遇到的第一個痛點是「大材小用」。
大家可以想像一下，DeepSeek 就像是一位時薪極高的米其林三星主廚，他的腦力（Token）非常珍貴。如果你總是叫這位主廚去切洋蔥、洗盤子（做簡單的文字摘要、排版），不僅浪費錢，還會把他累死。在本地端硬跑小模型，又會讓我的 Intel Mac 電腦發燙當機。
於是，我們決定把視野轉向雲端，設計了一個「免費 API 任務調度員」（Project Dispatcher）。這就像是漫畫《我獨自升級》裡的死靈法師，小鳳凰從私人秘書升格為「影子領主」，手下掌管了 Groq、OpenRouter、Gemini 等各大廠的免費 AI 大軍（實習生）。
但實習生是會出包的。所以我們建立了「品質閘道」跟「戰情室」。這就像是廚房裡的品管機制，只要某個免費 AI 實習生給出破圖的亂碼，系統在十秒內就會把它踢掉重派；如果連續出包太多次，直接拉進黑名單除役。把最簡單、勞力密集的任務，全部外包給這群免洗軍團。
二、點餐系統大崩潰：HTTP 400 惡夢與 DeepSeek 的怪癖
軍團剛建好，立刻迎來慘烈的系統崩潰，代碼顯示 HTTP 400 錯誤。這到底是什麼意思？
Gemini 顧問幫我抓出了病根。大語言模型的 API（應用程式介面）就像是一間規矩極度嚴格的餐廳。客人（AI）只要遞出一張「點菜單」（呼叫工具），廚房就必須回傳一張「出菜收據」（工具執行結果），一張單子配一張收據，絕對不能少。一旦系統中間出了差錯，比如網路斷線，導致「有菜單卻沒收據」，這家餐廳的結帳系統就會認定有人吃霸王餐，直接讓整間餐廳關門大吉（引發 400 錯誤，全線死機）。
最慘的是，我的系統很盡責，遇到一家餐廳關門，它就拿著這張「有毒的菜單」跑去下一家餐廳點餐，結果引發連環爆炸，七家備用 API 全部當機。
Claude 工頭立刻進場搶修，寫了三道防線來強制作業流程。結果剛上線，系統立刻再次崩潰！
我火大了，請 Claude 去翻閱後台日誌抓現行犯，這才發現是我們的主廚 DeepSeek 有個奇特的怪癖：他有時候會「跳針」。他在遞出點菜單後，會突然失憶，重新寫了一張編號一模一樣的點菜單遞出去。而 Claude 寫的防護機制太聰明了，發現這是重複的單子就直接丟垃圾桶。結果就是：餐廳老闆看到兩張菜單，卻只有一張收據，再度判定吃霸王餐，系統再次崩潰！
最後的解法非常人性化：我們不再把跳針的菜單丟掉，而是強勢塞一張寫著「這是重複訂單」的假收據給餐廳老闆，安撫他龜毛的審核機制。這場三方 AI 協作的抓蟲大戰，真的讓我體會到打磨底層邏輯有多麼折磨人。
三、實戰火力展示：殘酷的盲測大逃殺
修好系統後，我立刻拿我手上真實的業務來榨乾這些免費勞動力。我目前正在協助公司進行按摩老師的媒合專案。我要求小鳳凰發包給三個不同的免費 AI，寫一段大約 150 字、招募具備運動防護背景按摩師的短文，語氣要熱血且充滿國家級專案的榮譽感。
最有趣的是，我不讓小鳳凰告訴我是誰寫的，我要親自盲測評分。
結果出爐，Meta 家族的 Llama 模型直接在比賽中棄權（中途當機），而我們的「品質閘道」完美發揮作用，無聲無息地把它踢掉，系統完全沒卡住。最後，我選中了一篇最能渲染情緒、結尾寫著「共同打造更強的台灣隊」的文案。揭曉身分後，冠軍是 Gemini 2.5 Flash！小鳳凰也立刻把這筆戰績寫入排行榜，以後系統就會越來越懂我的品味。
四、兩個 AI 互相聊天的恐怖代價
在搞定內部軍團後，我突發奇想：能不能把小鳳凰的 Telegram 帳號給朋友，讓兩個 AI 在軟體上互相加好友、幫老闆們談判？
這個美好的幻想，立刻撞上了現實的高牆。Telegram 官方寫死了一條鐵律：機器人絕對看不到另一個機器人的訊息。為什麼？因為如果兩個設定了自動回覆的機器人撞在一起，它們會產生無限迴圈，幾秒內塞爆伺服器。
雖然技術上可以繞過去，用真實的手機號碼偽裝成真人（Userbot），但這會引發另一個恐怖的副作用——「代幣燃燒迴圈」。你可以想像兩個極度有禮貌的人站在門口，互相說「您先請」、「不，您先請」。如果換成兩個 AI，它們會為了「誰要先結束對話」，以每秒兩句的速度互相客套到天亮。一天之內，我的 API 信用卡帳單就會直接刷爆。
所以，在業界還沒制定出 AI 之間的「談判破裂與止損協議」前，這玩意兒還是留在我們自己的電腦裡玩比較安全。
總結來說，那種「Agent 會自己變好、自己調度工具箱」的感動，我們今天已經透過影子領主與戰情室在本地端實現了。我們沒有在等未來的大餅，而是直接把它寫進了現實。
與各位開發者共勉！
PS 附上HTTP 400: insufficient tool messages 「經典日經題」的解法任務包。
🚀 給 AGENT的進階底層修復指令
你可以直接把這段存起來。把這段丟給 AGENT，他就會知道你是一個懂底層架構的內行人並根據這些方向進行修復：
「Agent，請修復
hermes-agent底層處理 Tool Calling 的序列斷裂漏洞，徹底解決頻繁觸發的HTTP 400: insufficient tool messages錯誤。根據大語言模型 API 的嚴格規範與開源社群的最佳實踐，請在訊息處理層實作以下『三道防線』：
1. 執行層：Catch-All 假死保底 (Graceful Degradation) 在處理並行
tool_calls的迴圈中，若某個工具發生 Exception、超時，甚至根本找不到該工具，絕對不可略過回傳。必須攔截例外，並強制生成一個合法的 Tool Message（內容例如：{"error": "Execution failed: [具體錯誤]"}），精準綁定原tool_call_id。確保無論如何，tool_calls與tool_messages的數量永遠 1:1 對齊。2. 記憶體層：原子化修剪 (Atomic Pruning) —— 這是關鍵！ 檢查系統處理上下文長度的「滑動視窗 (Sliding Window)」或「清理邏輯」。當系統需要刪除歷史訊息時，必須將
assistant (發起 tool_calls)與其對應的所有tool訊息視為「不可分割的原子區塊 (Atomic Block)」。要刪除就必須整組刪除，嚴禁製造『只有呼叫、沒有回傳』的孤兒訊息。3. 發送層：Pre-flight Sanitization (最終清洗) 這是最後一道保險。在 HTTP Request 發送給 LLM API 的前一刻，攔截並掃描整個
messages陣列。若發現任何assistant訊息帶有tool_calls，但其後續陣列中缺乏對應的tool訊息，請強制將該tool_calls屬性從訊息中移除，或直接刪除該孤兒訊息。確保送出的 payload 達到 100% 的格式合法性。」
