AI代理編碼的三種風格

一個合理的“AI代理”定義，至少在代理編碼的語境下，可以是：一個具備LLM能力的軟體程序，在啟動時接收指令以完成任務，自主執行（無需人類互動），並具有非確定性行為——代理會根據情況調整，但希望不偏離指令。這些軟體程序可以並行啟動以加快速度或完成更多工。

然而，在實踐中，“代理”一詞常被濫用，可能只是指一個ChatGPT對話，使用者提示“你扮演專業稅務代理，幫我填寫報稅表”。Pieter Levels在2025年夏季表達了類似感受：“現在聽到人們談論‘AI代理’通常是個危險訊號，我知道他們是非技術人員，只讀AI新聞而不實際發貨。”

到2026年夏季，情況是否發生了變化？在作者的編碼實踐中，他探索了幾種符合上述定義的代理編碼方式，而非掛羊頭賣狗肉。以下是三種嘗試：

風格1：啟動多個命令列介面 作者曾這樣做：開啟SSH會話到伺服器，啟動Codex CLI，透過提示要求GPT完成任務。再開啟第二個SSH會話，啟動Codex CLI，分配另一個任務，以此類推。這種方法簡單有效，甚至可以同時使用不同AI提供商的CLI，分散令牌消耗。

風格2：以無頭模式執行AI CLI 作者用這種方法為200多個不同網頁編寫爬蟲。基本邏輯是：一個JSON檔案包含引數，一個Bash指令碼（指令碼A）以無頭模式啟動LLM，指令碼A包含帶有佔位符的提示，用於指導LLM編寫特定網站的爬蟲。另一個指令碼B從JSON中選取20個網站，為每個執行指令碼A。作者執行指令碼B，檢查結果，然後繼續處理下一批20個網站，直到完成全部200個。指令碼A還要求LLM為每個爬蟲編寫單元測試，儘管測試並不總是透過，但提高了爬蟲的可靠性。這種方法比風格1複雜，但幾乎做到了“啟動指令碼B，一小時內得到200個爬蟲”。

風格3：讓一個LLM自行建立和管理子代理 風格2依賴Bash和Unix，維護困難。許多解決方案（如Cursor、Codex、Google Antigravity、Claude Code）允許LLM自行啟動代理。但作者認為目前還不成熟：距離實際工作更遠，錯誤更難捕捉，中斷和恢復不直接，且受限於特定解決方案。因此作者堅持使用風格2（簡單情況下用風格1）。

我們真的需要代理嗎？ 大多時候不需要。Ethan Mollick透過一個提示和四次跟進建立了完整的即時Web應用，作者的女兒也開發了完整的電商平臺，沒有使用花哨技術。LLM在搜尋資訊時也會自行啟動代理。作者認為大多數複雜任務都不需要代理，因為LLM本身就能勝任，如果代理有用，LLM會在後臺自行管理。

多代理相互干擾的問題 多個代理同時寫入程式碼庫會相互干擾。解決方法是讓每個代理在不同的git分支上工作，然後合併。但合併可能失敗且繁瑣。作者在風格2中透過為每個爬蟲做充分的準備工作（確保完全隔離）避免了衝突，並在提示中加入硬性限制，禁止代理觸碰範圍外的檔案。

下一步 從幾十個爬蟲擴充套件到數百個，並執行它們。目標是熟練掌握這種“自制”多代理設定，以便在其他地方複用。

關於作者 作者是一名學者和獨立Web應用開發者，建立了nocode functions工具。