代理工程模式
這篇文章探討了如何從 Claude Code 和 OpenAI Codex 等編碼代理中獲得最佳結果的模式。請參閱我的介紹以了解有關此專案的更多資訊。
背景
本文探討了 Simon Willison 針對「代理工程模式」(Agentic Engineering Patterns)所提出的見解,旨在優化如 Claude Code 或 OpenAI Codex 等編碼代理工具的使用成效。隨著 AI 代理在軟體開發流程中的參與度日益提高,開發者社群開始歸納出一套能讓 AI 穩定產出高品質程式碼的實踐方法與架構。
社群觀點
在 Hacker News 的討論中,開發者們對於如何有效引導 AI 代理達成目標展現了高度共識,其中「自動化驗證」被視為成功的核心。多位評論者強調,軟體的可測試性直接決定了代理工程的成敗。例如,有開發者分享了利用 AI 優化 Linux 二進位檔案壓縮率的經驗,指出壓縮任務具備極佳的驗證閉環:從壓縮到解壓縮再比對原始檔案,這種明確的對錯標準讓 AI 能夠在多次迭代中不斷嘗試並修正。社群普遍認為,開發者不應過度微調 AI 的具體操作步驟,而應將精力投入於建構完善的測試框架。只要測試機制足夠強大,即便 AI 在過程中嘗試了錯誤的路徑,也能透過自動化回饋迅速導回正軌。
除了測試框架,社群也觀察到 AI 代理在處理任務時展現出與人類工程師不同的特質。有觀點指出,資深工程師在編碼時會在腦中進行邏輯模擬,而 AI 則容易在細微處出現人類難以想像的錯誤。為了彌補這一點,開發者建議讓 AI 承擔更多開放式的測試任務,例如撰寫單元測試或進行 Playwright 網頁自動化測試。過去由人工維護大規模網頁測試可能過於繁重,但在代理工程的模式下,這種「以量取勝」的驗證方式變得極具可行性。此外,維持跨對話的「記憶」也至關重要,透過 Markdown 檔案作為草稿紀錄,能讓 AI 在不同階段的實驗中學習前次的教訓,避免重複無效的嘗試。
然而,並非所有人都認為這些「模式」具有開創性。部分評論者質疑,目前的代理工程模式本質上只是將行之有年的軟體開發最佳實踐——如測試驅動開發或模組化設計——重新包裝,並套用到 AI 協作場景中。這種觀點認為,這類討論雖然有助於新手入門,但對於資深開發者而言,不過是將已知的工程常識轉化為給 AI 的指令。此外,也有人將此現象與 90 年代盛行的物件導向設計模式(OOP Patterns)相類比,思考未來是否會出現專門買賣「代理模式」的商業市場。
最後,討論也延伸到了開放網路對 AI 代理的重要性。有評論者指出,為了讓 AI 代理能更有效地在網路生態中導航與協作,結構化的開放協議如 JSON-LD、RSS 或 Schema.org 顯得比以往更加關鍵。一個具備良好語義標記的網站,能讓 AI 在無需 API 金鑰或複雜授權的情況下,自主理解網站的功能與術語,這不僅提升了代理的作業效率,也重新定義了機器可讀網頁在 AI 時代的價值。
延伸閱讀
- StrongDM 的 Dark Factory 原則:提供了一套更具實作性的 AI 代理協作準則。
- fesh 專案:一個利用 AI 代理優化 Linux 二進位檔案壓縮的實驗案例。
- unratified.org:展示了如何透過開放協議(如 agent-inbox.json 與 glossary.json)建立對 AI 代理友善的基礎設施。