這幾年 coding agent 忽然變多：有的嵌在編輯器，有的跑在瀏覽器，有的是你自己用 API 硬幹出來的。山姆鍋玩過幾種之後，愈來愈相信一件小事：
人最好只認定一個對口。
其餘的東西可以很能幹——搜尋、跑測、開分身——但它們比較像工具或部下，不該人人手握「改倉庫／動環境」的同一把萬能鑰匙，更不該讓使用者自己當總機，把同一句話複製貼上五個視窗。
目錄
對口在解決什麼問題
Coding agent 一多，混亂通常不是模型不夠聰明，而是責任邊界糊掉：
- 誰有權改檔、跑指令、碰密鑰？
- 出了事要回顧哪一段對話、哪一條工具呼叫？
- 子代理失敗時，誰負責換人、誰負責跟你交代？
若每個視窗都能直接改環境，短期很快樂，長期你會得到一堆互相覆蓋的 diff，外加「我記得有個 agent 說過沒問題」。
所以山姆鍋偏好的形狀很老派：
- 唯一對口：你下指示、拿結果，只認一位。
- 對口代為編排：它決定要不要叫專門的幫手；幫手不必（也不該）跟你建立平行關係。
- 副作用走窄門：改檔、執行、讀輸出，經明確的工具／宿主契約，而不是「模型想到就
eval」。
這跟十多年前山姆鍋玩代理人、參與者模式時在意的事情其實同類：誰能跟誰說話、訊息從哪進、副作用從哪出。換皮成 LLM，問題沒消失。
觀察迴圈比再堆 API 重要
另一個常被忽略的點：coding agent 值不值得用，常常取決於它能不能看見自己幹過的事。
改完檔卻看不到 console、重載了卻沒有穩定的「再看一次」——再多檔案 API 也只是加速製造謎題。山姆鍋寧可先把「改 → 重載 → 讀輸出／錯誤」這條迴圈做穩，再考慮要不要讓 agent 擁有更像 Linux 的世界。
權限亦然：對口可以很強，但不代表密鑰該躺在它的聊天紀錄或前端 storage。模型需要打外部 API 時，比較穩的是宿主保管、按需代用或具名取出——細節各家不同，原則是：明文不要變成 prompt 的一部分。
一個實際案例：遊樂場裡的總管
山姆鍋在本站 /playgrounds/ 做實驗時，把上述想法落成一個角色，產品文案叫總管（Steward）。
重點不是名字好聽，而是約束：
- 遊樂場裡可以有很多 Agent 形態的單頁小程式，但只有被設成總管的那一位拿得到完整的宿主 API（
env.HOST），用來代你管理沙盒、改檔、重載之類的事。 - 總管本身仍是普通的 SAM：有 UI、也可以有後端形的
functions.js／常駐的controller.js。它不是遊樂場外面另賣的產品。 - 你跟總管說話；它再去動場地。你不必同時認養五個都叫「助理」的神。
若你從來不想用 AI，總管可以不理會——遊樂場照樣能寫小工具、小遊戲。總管只是山姆鍋驗證「單一對口」時隨手抓得到的實例，不是這篇文章要推銷的主角。場地不收費，資料也主要在你自己的瀏覽器裡。
換個宿主，原則還在嗎？
可以這樣自問：
- 我能不能畫出「人 → 唯一對口 →（可選）子代理／工具」？
- 對口若消失，子代理會不會變成沒人管的幽靈程序？
- 工具權限是跟著對口收斂，還是散落在每個對話窗？
答得清楚，你在 Cursor、自架 agent、或別的沙盒裡，比較不容易一開始就堆出五個全能管家。答不清楚，換再強的模型也只是加速熵增。
結語
山姆鍋沒有要宣布「唯一正確的 agent 架構」。只是想分享：自己踩過「好多代理、好少章法」之後，愈來愈把一個對口當成預設，而不是進階選項。
你若有完全相反的用法——例如刻意讓多個對口互相制衡——也很歡迎在下面留言區辯一下；山姆鍋樂見正反都出聲。