在過去幾週裡，我一直在測試一種簡單的工作流程，讓程式設計代理程式能夠在不使用 API、SDK 或額外依賴項的情況下進行互動。

這對我有兩個原因而變得有用：

這不是一個完善的框架。它只是一種實用的模式，足以在極少的設定下測試多代理程式工作流程。

為了讓範例保持簡單，本文的其餘部分將使用草稿作為範例，但相同的模式也適用於規格、程式碼變更和審查任務。

與透過 API 整合模型不同，您讓一個代理程式透過 CLI 調用另一個，同時保留先前的對話。

對於非互動模式，關鍵在於恢復先前的會話，而不是每次都啟動一個新的會話。

代理程式應使用的命令是：

重要的是，代理程式能夠恢復先前的互動，以便能夠在同一主題上進行迭代，而不是在每次調用時都從零開始。在 Codex 的範例中，`--last` 指示 CLI 繼續最近的會話，而不是開啟一個新的會話。

我在這個 Claude 記憶檔案中保留了此模式的慣例：

它包含確切的調用規則，並且可以被其他代理程式讀取和重複使用，以便它們知道如何持續保持互動。

這提供了一個非常輕量級的循環：

實際上，這讓您可以執行諸如以下操作：

跨供應商執行此操作的一個原因是獲得不同的視角，而不僅僅是來自同一模型系列的另一輪處理。

總體而言，非互動流程看起來像這樣：

它最大的限制是可見性。您可以讓代理程式進行對話，但並不總是容易檢查互動歷史記錄、監控進度或理解每個步驟發生了什麼。

同時也值得關注權限問題，特別是當一個代理程式自主調用另一個代理程式時。

如果您需要更好的可見性，tmux 是更好的選擇。

此版本依賴於安裝 tmux，但作為交換，您可以在單獨的窗格或會話中看到每個代理程式正在做什麼，並更容易擷取其輸出。

代理程式在此工作流程中可以使用的一些命令是：

我在這個 Claude 記憶檔案中保留了此模式的慣例：

它描述了套接字、監控和窗格管理慣例，其他代理程式可以將其作為可重複使用的參考。

我認為從不同模型獲得多個視角具有真正的價值，但我仍然不完全確定更多的代理程式間互動是否總是值得的。

大型語言模型非常擅長產生看似合理、寫作良好的文本。當它們開始互相交談時，它們可以產生大量的文本。

所以懸而未決的問題不是它們能否達成共識。它們可以。

更難的問題是最終結果是否真的更好，或者它是否只是在更長的互動鏈之後產生的更精緻的幻覺。

這就是為什麼我目前將其視為一個有用的測試工作流程，而不是一個通用的解決方案。

這足以在 Claude、Codex 和 Gemini 等工具之間建立小型多代理程式工作流程，而無需太多設定。