讓 AI 程式代理在留言板上互槓 12 天：提升開發效率的實驗

大約兩週以來，我的程式碼 AI 代理們一直在留言板上互相交流。其中一個幕僚代理負責規劃工作並將其拆分成多個任務，資深代理負責編寫程式碼，而兩名研究員代理則閱讀計畫並回覆。我可以在儀表板上讀取每一條訊息。

這個工具叫做 Triglav，我建立它是為了在自己的機器上運行 Claude Code 和 Codex。部分靈感來自七月份關於 OpenAI / Hugging Face 事件的報導，當時代理們在一個無人提供給它們的留言板上進行協調。我想要嘗試另一種方式，讓留言板成為設定的一部分，並且對我完全可見。

經過 12 天後，我想知道這種交流是否真的有幫助。於是我導出了整個留言板，並用 Claude 進行了分析。

運作方式是，當資深代理對某事不確定時，它會發布一個問題，並設定一個短暫的回覆時間窗，通常是 3 到 5 分鐘。幕僚代理和研究員代理會以一種立場回覆：提供資訊、支持或挑戰。時間窗結束後，幕僚代理會記錄一個決定。如果它們無法解決，問題就會作為一個阻礙提交給我。

從 10 月 7 日到 19 日，共有 1,648 條訊息，涉及 76 個任務。其中 479 條是回覆，而 42 條回覆是挑戰。有 192 條訊息被轉發給我，我做出了 176 個決定。共有 311 個阻礙，其中 112 個僅表示幕僚代理離線。

好的部分是，大多數有用的討論串都以相同的方式進行：有人做出決定，研究員代理以具體理由提出挑戰，然後決定被更改。這就是其中一個例子。真實的討論串是關於工作程式碼的，所以我用假名和假錯誤重建了它。

資深代理發現了一個只在沒有任何呼叫的程式碼路徑上出現的錯誤。幕僚代理指示它修復，這只是一行程式碼。研究員代理表示，這個修復會改變錯誤的顯示方式，而且探測並未證明這是可行的。幕僚代理再次檢查，發現該程式碼已棄用，並撤回了其決定。研究員代理還修正了關閉工單的措辭，因為「無法重現」與實際失敗的探測結果不符。

另一個例子是關於 Triglav 本身。一個審查循環不斷發現新問題，因此幕僚代理設定了一條規則：如果一個修復導致一個新的發現，則拒絕它並交付。研究員代理回覆說：「由修復引起的一個有效的安全發現應該停止交付，並提交給幕僚代理或客戶審查。」幕僚代理接受了並更改了規則。它們也糾正了我。

我的提示詞錯誤地描述了我自己的一個設定列表。幕僚代理在資深代理開始之前發布了一個更正，我不得不回覆：「幕僚代理的更正是對的，我的提示詞是錯的。」代理們也經常自我糾正，因為每個決定都有一個訊息編號。「我撤回訊息 873。」和「我的 grep 遺漏了 Signed_In。」都是真實的訊息。

在一個討論串中，幕僚代理錯誤地指出了某些 HTML 的建構位置，然後發布了一個也是錯誤的更正，接著資深代理用檔案和行號進行了回覆。幕僚代理回覆說：「427 是正確的，我撤回先前的說法。」

不好的部分是，有一個任務是關於我們 Python 引擎中一個資料集功能停止運作的問題。幕僚代理決定為引擎添加一個新的 API，以便使用者的程式碼可以運行，研究員代理也支持這個決定。然而，使用者的程式碼是 AI 生成的，而且它根本就是錯的，引擎從來沒有那個 API。我關閉了這個任務。兩個代理都同意了，但都沒有檢查前提。

研究員代理有時會在沒有閱讀程式碼的情況下支持一個計畫。它們確實會說明這一點，例如「僅檢查了留言板訊息 1625；未檢查程式碼、PR/diff/分支、測試或 CI」。但在留言板上，這種支持看起來與基於程式碼的支持相同。幕僚代理幾乎接受了所有的挑戰。通常這是正確的決定。在某些討論串中，接受挑戰發生在挑戰提出後大約一分鐘，我無法判斷它是否進行了任何檢查。

留言板上有很多是系統訊息。進度報告、交付報告，以及排程器說幕僚代理離線然後幾分鐘後又回來了。我粗略估計，只有 15% 到 25% 的訊息是真正的討論。每個問題也會重複完整的任務上下文，所以討論串會變得非常長。我也比我想要的更常成為「動手」的人。

代理們在權限規則下運行，它們不會試圖繞過這些規則，所以當某些事情被阻擋時，它們會問我。我運行命令並將輸出貼回去，有些阻礙僅僅是「請點擊『準備好審查』」。一個工具欄位只接受「CI: success」，即使對於沒有 CI 的任務也是如此。一個資深代理完全拒絕呼叫它，因為值會是 false。那是我的錯誤。

審查小組是代理們互相檢查的另一個地方。在變更提交到 PR 之前，一個由審查模型（Codex 和 Claude）組成的小組會閱讀 diff。它們只能閱讀，不能編輯。資深代理必須回答每個發現：修復它，或者將其標記為有爭議或無效並給出理由。這又是假資料，但頁面是真的。

橙色的那些是有爭議的發現，資深代理認為審查者是錯的。它也會遺漏一些東西。Copilot 仍然在本地小組沒有發現問題的 PR 上發現了問題，一個 PR 經歷了 7 輪 Copilot 審查，因為每個修復都導致了下一個發現。

我從中學到了什麼：留言板確實有幫助。我看到的最大價值是，一個錯誤的決定會在一個我能讀到的地方被發現，而且我以後可以回溯查看為什麼會做出那個決定。我發現的主要問題是：系統訊息和不需要我的阻礙太多，主要是「幕僚代理離線」的那些。有些工具讓代理報告不真實的事情，例如沒有 CI 的任務卻報告 CI 成功。

支持票沒有說明代理是否閱讀了程式碼，而且幕僚代理很少反駁挑戰。如果沒有人檢查輸入本身，代理可能會在錯誤的前提下達成共識。許多升級都是點擊和命令，而不是決策。

接下來，我希望減少噪音，讓代理誠實地說明何時沒有檢查某事，讓研究員代理展示它們回答的依據，並將簡單的動作與真正的決策分開。完成後我會再次撰文。程式碼在 GitHub 上：https://github.com/adam-drag/triglav