各位，請準備好你們的代理程式，我將說服各位為何 Go 是它們的最佳語言。
我過去八年來一直專業地使用 Go。在此我想論述為何 Go 是使用 AI 代理程式的最佳程式語言。
我從事專業開發已超過十年，曾使用過 PHP、Go、JavaScript 和 Python。我的職業生涯大部分時間都在建構 Web 服務，而過去幾年我一直在開發 Bruin，這是一個主要以 Go 編寫的 CLI 工具。
Bruin 是一個開源的 ETL 工具，正如有些人可能知道的，資料生態系統熱愛（或曾經熱愛？）用 Python 建構工具。Python 有大量的可用函式庫，資料領域的專業人士熟悉 Python，因此更容易獲得貢獻，而且與 Go 相比，更容易找到 Python 開發者。當我們開始建構 Bruin 時，我們面臨一個決定：是要用 Go 還是 Python 來建構 CLI？
在做出決定之前，我們需要考慮幾個限制條件：
除了所有這些限制條件之外，還有一個更主觀的限制：我將在相當長一段時間內成為主要貢獻者，而且必須是我喜歡使用的語言。對於一個小型團隊在建構大型專案時，熱情和活力是最稀缺的資源之一，我認為我必須避免對我們使用的技術堆疊感到厭煩，這一點至關重要。
最終，我們決定採用 Go。它滿足了許多條件，雖然也有一些缺點，例如與 Python 相比，在某些資料相關任務上函式庫較少，但它滿足了最重要的一點：我真心喜歡使用 Go。這種喜愛讓我能在代理程式出現之前就貢獻了數千行程式碼，並支撐我們走過了很長一段時間。我曾一度害怕，選擇 Go 是一個策略上的錯誤，因為我們必須從頭開始建構很多東西；然而，我的直覺告訴我，Go 相較於 Python 在速度和開發者體驗（DX）上的優勢，長遠來看會帶來更大的優勢。
我完全沒想到代理程式會成為一個趨勢，但我相信當代理程式成為趨勢時，我們的直覺讓我們處於一個相當幸運的位置。我想談談 Go 在使用 AI 代理程式編寫軟體方面的一些優勢，以及為何我認為 Go 是當今代理程式的最佳語言。
代理程式會產生大量的程式碼。無論你是否認為它們在這方面很聰明，它們產生的程式碼都非常可信，而且通常看起來是正確的。這就是第一個挑戰的開始：我們如何確保它們產生的程式碼能夠正常運作？
確保這一點最簡單的方法之一就是使用編譯型語言。強型別、靜態型別，我總是搞混它們，但這使得 AI 代理程式能夠迭代它們產生的程式碼，直到在一定程度上是正確的。這並不意味著程式碼能做它應該做的事情，它只是意味著程式碼在使用錯誤的型別或參數方面，可以免除某些類型的錯誤。能夠編譯的程式碼保證了，就語言標準而言，所生成的程式碼在語法上是正確的。
雖然編譯型語言已經存在了很長時間，但像 Go 這樣的高階程式語言並不多。當然，還有 Rust，它的動態和目標用途與 Go 非常不同，我認為在 AI 代理程式方面，Go 勝過 Rust：
這更多是直覺想法，而非真實數據支持，我很樂意被糾正。
雖然有許多編譯型語言，但在易用性、社群、迭代速度和簡潔性方面，Go 絕對是頂尖的選擇。
也許這應該放在最前面？總之。Go 是一種非常簡單的語言。如果你對任何程式語言有一定程度的掌握，閱讀 Go 程式碼應該對你來說是輕而易舉的。你可以立即理解程式碼的作用並進行推理。這意味著，即使你的代理程式產生了大量的 Go 程式碼，你仍然能夠應付。
這裡的另一個優勢是理解設計選擇：雖然代理程式能夠生成非常好的程式碼，但它們有時會做出奇怪的設計決策並一頭栽進去。語言的簡潔性在這裡非常有助於弄清楚代理程式的發展方向。
話雖如此，我堅信我們在 12 個月內不會怎麼閱讀程式碼，因此也可以爭辯說可讀性或簡潔性在未來不會太重要，這可能是對的。即使如此，如果我以後想跳躍式地查看程式碼，我仍然希望能夠做到。
這是我熱愛 Go 的原因之一：它是一種有主見的語言，有清晰的指導方針和支援它的工具。它有一種標準化的方式來執行測試、格式化程式碼或建構二進位檔。Go，即使被許多人討厭，也有處理錯誤的特定方式。無論你是否喜歡，它肯定宣傳了一種做事的方式，讓編寫慣用的 Go 程式碼變得更容易，這樣多人和代理程式都可以進行協作。
以 JavaScript 為例：有數十億種做事的方式。每次我接觸一個 JS 專案時，我都必須發現他們使用的工具，了解它們如何運作，並在能夠有效率地工作之前嘗試熟悉它們。每個人對於如何格式化程式碼、如何分發套件，甚至如何在腳本中匯入函式庫，都有不同的看法。坦白說，我發現 JS 的狀態一團糟，但我離題了。
Go 避免了這些問題，這為 AI 生成的程式碼帶來了顯著的優勢：模型能夠根據它們在訓練資料中看到的所有程式碼來知道如何處理 Go。Go 程式碼通常非常相似，標準化的工具鏈讓代理程式能夠有效地使用它們。
要求代理程式格式化 JS 程式碼，它會匯入一個新工具並嘗試讓它運作。要求它對 Go 程式碼庫做同樣的事情，它只會執行 gofmt 就完成了。編寫單元測試或建構二進位檔也是如此。
我認為如果你編寫的軟體只在特定環境中運行，這點可能不會引起你的共鳴，但如果你編寫的是你無法控制其運行環境的 CLI 工具等，那麼 Go 就成為了完美的選擇。這一點與 AI 無關，但我認為它與 AI 代理程式之間存在有趣的互動。
Go 將跨平台支援視為一等公民，這意味著在每次變更時，在各種環境中運行我們所有的測試（無論是單元測試還是整合測試）都變得輕而易舉。
你猜對了：這意味著 AI 代理程式可以快速驗證它們的工作，並確保它們沒有破壞任何現有功能。顯然，如果你不編寫測試，這本身就不是一個優勢，但能夠輕鬆地在另一個作業系統上執行相同的命令並驗證程式碼，這點很重要。
像許多其他人一樣，我們一直在盡可能多地實驗背景代理程式。無論是透過 Slack 訊息觸發 Cursor 進行變更，還是將本地會話轉移到遠端會話，我們都在慢慢地將自己從對程式碼建構和運行環境的嚴格控制中解耦。
這是一個小點，但 Go 的跨平台優勢在這裡也閃耀著：相同的程式碼將產生可在 Linux、Windows 或 macOS 上以相同方式運行的二進位檔，並且處理 Go 程式碼的整個過程在各種環境中都是標準化的。這意味著我不關心不同的代理程式平台在哪裡運行，或者沙盒提供者是否能處理我們的開發依賴項；一切都正常運作。
這可能是隨著時間推移會消失的優勢之一，但根據我的經驗，截至 2026 年初，代理程式有 95% 的時間能夠一次性產生有效的 Go 程式碼。我對此沒有任何數據，儘管我在處理 Python 時比 Go 遇到更多困難。模型了解函式庫、模式和最佳實踐，一旦確定了方向，用 Go 建構一個功能幾乎是輕而易舉的。
我認為這部分原因不是 Go 有很多訓練資料；如果真是這樣，Python 肯定會贏。Go 通常只有一種做事方式，而 Python 有 20 種不同的方式來做同一件事。如果我們說訓練資料是 Go 對比 Python，Python 會贏，但在實踐中，這似乎更像是針對這個特定函式庫的訓練資料是 Go 對比 Python，而在此 Go 獲勝。
我敢打賭，隨著時間的推移，這種優勢將會消失，如果還沒有的話，因為模型越來越好，訓練資料包含了越來越多的其他語言（如 Rust）的範例，而且我確實缺乏證據來支持我的說法；因此，請將此視為一種感覺。
我相信程式語言正經歷一個奇怪的階段，過去我們關心的大部分事情似乎不再重要了。看來人類將越來越少地手動編寫程式碼，我們將需要能夠讓代理程式出色地完成這項工作的系統。
我認為純粹是運氣，Go 可能恰好處於可用性、效能和普及性的甜蜜點，這使其非常適合代理程式。它們編寫優美的 Go 程式碼，它們運行、編譯、測試、格式化並交付高效能的 Go 軟體，這些軟體可用於各種機器。所有這些好處今天對任何想建構新工具的人來說都是現成的：只需告訴 Claude Code 用 Go 為你建構一個 CLI，然後坐下來享受成果。
由於這些好處，Go 最近在 Bruin 賦予了我們巨大的力量，我們正在加倍投入。Go 會成為代理程式的程式語言嗎？我不知道。會不會有更適合代理程式的語言出現？我不知道。我只知道我很有生產力，我的團隊也很有生產力，我們能非常快速地交付體面的軟體。更重要的是，即使有了代理程式，我仍然非常享受使用 Go 的過程。