どうも、和製ホーリックスです。距離上次更新又整整過了一個月，雖然有點晚，不過還是在這邊跟各位說一聲新年快樂:D
事實上這陣子以來，在下還是一直不斷強化在「MP-Ukagaka」的能力。因為透過Gemini的建議，進而產生了許多有趣的想法…例如AJAX端點從傳統的admin-ajax.php架構全面遷移到現代的「WordPress REST API」，透過WordPress 6.9+核心內建的「WordPress Abilities API」，賦予フリーレン直接與WordPress互動的能力，或者在與フリーレン互動對話模式中，加入「伺服器發送事件串流(SSE Streaming)」，改善長回覆與思考型模型的等待體驗等等。
まあ、但真要問在下SSE Streaming是什麼，老實說在下也不知道，總之感覺很酷就弄了XD
記得在以前的文章中，在下曾經介紹過「Cursor」這個Vibe Coding的好物，不過自從Google的「Antigravity」問世以來，Cursor這玩意基本上已經被在下冷凍了。原因無他，Pro會員一個月的使用Limit很快就被在下用完了，不加錢什麼都不能作，沒有物超所值的感覺。
相反的Antigravity當中的Claude Opus4.6雖然使用額度有限，但至少Gemini 3.1 Pro或Gemini 3 Flash的使用上限是很高的，就算達到上限，休息幾小時就恢復了，沒有斷炊之虞，所以就果斷跳坑了。
不過最近讓在下沉迷的，則是CLI介面的AI工具，如Gemini CLI、Claude Code、以及Codex CLI。
基本上過去在下對CLI工具(Command Line Interface)還蠻避之唯恐不及的，畢竟它是一個以文字為基礎的作業系統互動方式，使用者必須在終端機如命令提示字元CMD或PowerShell中輸入具體指令，然後需要記憶各種命令語法。這讓在下想到高中計算機概論的QBasic，那是一段痛苦的回憶Orz
不過最近在下在強化MP-Ukagaka的過程中，由於專案越來越肥，代碼複雜度也跟著上升。每當遇到問題，在下的作業流程是這樣的：
開 Antigravity 確認Claude Code、Codex CLI或Gemini CLI給的修改計畫(看不懂就是了)
開Claude Code，把修改計劃書丟進去問它會怎麼實作
開Codex CLI，把Claude Code的實作內容丟給它確認是否有意見
開Gemini CLI，把Claude Code的實作內容丟也給它確認是否有意見
回到Claude Code，再把Codex CLI與Gemini CLI回饋的內容給它，確立實作方式
就如在下在實裝前述的SSE Streaming時，將遇到出現400 Bad Request的Debuglog分別餵給3位AI分析邏輯錯誤原因，然後將歸納的結論請Claude寫修改計畫，在Codex與Gemini確認無意見後，由Gemini修改代碼，然後Claude跟Codex再檢查代碼是否有疏失，綜合起來就完成了一次完美的重構。
這種做法聽說在業界被稱為多模型交叉驗證(Cross-model Verification)，讓不同模型互相review，能大幅降低單一模型的「幻覺」，提升代碼品質。實際體驗雖然有效，但操作上極度沒效率…(-＿-)
三個終端機視窗切來切去，手動複製貼上，一來一回就是好幾分鐘。
因此在下心想：有沒有一種方式，能讓三個 AI 在同一個介面裡一起討論，而且在下也能即時參與？
上網搜了一圈，GitHub上確實已有不少類似的專案，什麼daemon架構、tmux分割視窗、MCP server、桌面應用…諸如此類看起來功能很強的玩意，感覺都離在下很遠，而且有些可能光是安裝就要搞半天…在下的需求非常簡單：輸入一個問題，三個AI同時回答，並且互相review對方的回答，然後於下一次發言時，根據其他AI的回答內容再表示自己的看法，說穿了就一個CLI聊天室而已(笑
索性問了一下Gemini，它說技術上要讓獨立運作的三個CLI工具在背景互相溝通，會遇到標準輸入/輸出（stdin/stdout）互相阻塞的問題，因此業界的最佳實踐是捨棄CLI工具，改用API驅動的多代理人(Multi-Agent)框架，但在下而言那些都太深奧了。
所以在下選了一條最硬派的路——弄一個Python腳本來當「總機」。
它的運作方式其實很暴力。首先用Python的subprocess模組在背景同時啟動三個CLI，然後攔截在下輸入的訊息並派發給三個AI，再把它們的輸出擷取回來統整顯示。坦白說，這種做法非常容易撞牆。畢竟每個CLI工具的輸出格式、等待時間、提示符號都不一樣，解析它們的輸出基本上是一場惡夢。
PHP在這些年的自主學習下，雖然不會寫但多少看得懂一點，但Python對在下而言完全是未知領域。
まあ、套一句之前在下寫過的，AI的問題就用AI來解決，經過這2天的努力，終於被在下生出來了XD
踩坑紀錄：Windows上的各種地獄
以下是個人在Windows環境上踩過的坑。或許日後有人也會遇到同樣的問題，所以寫在這裡：
坑 1：Claude Code每次都彈出黑色CMD視窗
在Windows上，透過npm全域安裝的CLI工具(如Claude Code)，實際上是一個.cmd批次檔。
用subprocess呼叫.cmd檔時，Windows會自動開一個cmd.exe的Claude Code視窗，即使加了CREATE_NO_WINDOW旗標也擋不住，在下在這邊卡很久。
解法：繞過.cmd，找到真正的.js入口檔，直接用node cli.js執行。
坑 2：shutil.which()找到了錯誤的檔案
Python的shutil.which()在Windows上會優先搜尋當前目錄。而在下的工作目錄裡剛好有一個自己作的claude.bat快速啟動捷徑，結果shutil.which(“claude”)先找到的是這個垃圾檔案，而不是npm全域安裝的正確路徑。
解法：完全拋棄shutil.which()，改為直接從 %APPDATA%\npm\定位npm全域目錄。
坑 3：AI操作工具需要確認但沒人按確認
當AI收到修改檔案指示後，由於在嘗試寫入檔案時，CLI會跳出確認提示，需要使用者按下同意，但在背景執行模式下根本沒人能按，於是就卡住在那邊直到任務超時。
解法：加入自動批准旗標，Claude用–permission-mode bypassPermissions，Codex用–dangerously-bypass-approvals-and-sandbox，Gemini用–yolo。
坑 4：Gemini的–sandbox none根本不存在
Gemini自己搜尋了文件，確認Gemini的自動批准參數是–sandbox none，結果–sandbox是boolean旗標，none被當成多餘的positional argument跟-p打架，導致Gemini完全無輸出。
解法：改用–yolo（對，這真的是官方參數名稱）。
對了，上面採坑的詳細就不用再追問了，其實在下也不懂XD
那藉由claude.ai的神威，最終的介面長這樣，而Gemini將它命名為「Multi-AI Relay Hub」，很酷。
那這個代碼的特點如下，前提是要安裝Python 3.10+跟Node.js，並且在作業資料夾中手動執行每個CLI至少一次，以便接受任何互動式提示、授權協議或登入請求，然後在PowerSell中執行relay.py即可。
零依賴：純Python標準庫，不需要pip install任何東西
即開即用：cd到專案目錄，跑一行指令就啟動
三個AI能讀寫檔案：討論完後可以直接指定其中一個AI動手改代碼
互相Review：三個AI互相看得到對方的回答，進而歸納意見
まあ、缺點也是有的，就是等待AI回覆的時間可能沒那麼快就是了（ ＾ω＾）
以上、冴えな男が3つのAI CLIを1つのターミナルで喋らせる方となります。雖然目前在下還沒開始實際運用這個工具，不過如果閣下也有類似的需求，不妨下載回去修改成你要的(出事不負責)。
ではでは。
LEAVE A COMMENT