12-Factor Agents：當 Agent 開發遇上軟體工程的老派智慧

本文整理自 Dex Horthy 在 AI Engineer 大會的演講。

「你用框架很快做出一個 Agent，讓老闆很興奮，團隊加了六個人。但接下來你發現，70-80% 的完成度不夠用。想要突破這個天花板，你得鑽進七層深的呼叫堆疊，逆向工程這個 Prompt 到底是怎麼組出來的。」Dex Horthy 在台上描述的這個場景，讓現場不少人舉起了手——他們都經歷過。

Dex 是 HumanLayer 的創辦人。過去一年，他訪談了超過 100 位正在建構 AI Agent 的開發者、創辦人、工程師。他發現一個有趣的現象：真正在生產環境運作良好的 Agent，其實沒有那麼「agentic」。它們大多數是軟體，只是在關鍵節點用了 LLM。這些團隊都在做類似的事情，只是這些做法還沒有名字、還沒有被定義。於是 Dex 決定把這些模式整理出來，寫成了「12-Factor Agents」——致敬 Heroku 十年前定義雲端原生應用的那份經典文件。

LLM 是純函數，Tool Use 沒那麼神秘

Dex 開場就丟出一個觀點：LLM 最神奇的能力，跟迴圈、switch 語句、工具調用都沒關係。它最神奇的事情，就是把一句自然語言變成一段結構化的 JSON。這聽起來很簡單，但這正是整個 Agent 運作的核心。你不需要把它想得很玄，它就是一個函數：輸入 token，輸出 token。

這個觀點直接挑戰了「Tool Use」這個被神秘化的概念。Dex 引用了程式語言歷史上著名的「Go To Considered Harmful」論文，半開玩笑地說：「Tool Use 也是 harmful。」他不是說不該讓 Agent 跟外部世界互動，而是說我們不該把這件事想成某個神秘的外星實體在跟環境互動。實際發生的事情很單純：LLM 輸出一段 JSON，我們用確定性的程式碼去執行它，然後可能把結果餵回去。就這樣。

如果你有一個結構定義，讓 LLM 輸出符合這個結構的 JSON，你就可以把它丟進一個 switch 語句或迴圈裡處理。工具調用沒有什麼特別的，它就是 JSON 加程式碼。當你這樣理解之後，很多事情就變簡單了。你不需要依賴框架提供的魔法，你自己就能掌控整個流程。

掌控你的 Prompt、Control Flow 和 Context Window

12-Factor Agents 的核心精神是「擁有權」。你要擁有你的 Prompt，擁有你的控制流程，擁有你的 Context Window。這不是說框架不能用，而是說你最終得能看到、能修改、能最佳化每一個環節。

Dex 說，有些框架可以幫你快速產生一個很棒的 Prompt，那種你可能要上三個月 Prompt 學校才寫得出來的品質。但如果你想突破某個品質門檻，你最終會需要自己手寫每一個 token。因為 LLM 是純函數，決定輸出品質的唯一因素就是你輸入了什麼。除非你要自己重新訓練模型，不然你能控制的就是輸入的 token。

控制流程也是一樣。很多 Agent 框架會幫你管理迴圈、狀態、重試邏輯。這在初期很方便，但當你需要做更細緻的控制——比如在某個條件下中斷、切換策略、摘要歷史訊息——你會發現框架綁住了你的手腳。Dex 建議的做法是：把 Agent 想成一個簡單的迴圈。你有一個 Prompt 告訴 LLM 怎麼選擇下一步，有一個 switch 語句處理輸出的 JSON，有一個方式累積 Context Window，有一個條件決定什麼時候退出。就這樣。當你擁有這個迴圈，你就能做各種有趣的事：中斷、恢復、摘要、讓另一個 LLM 來判斷品質。

Context Window 的管理特別重要。Dex 觀察到一個常見的錯誤：當 Agent 呼叫 API 失敗，開發者會把錯誤訊息直接加到 Context 裡讓它重試。這聽起來合理，但很容易讓 Agent 陷入混亂——它看到一堆錯誤訊息，失去了方向。正確的做法是主動管理 Context：如果連續失敗後終於成功了，就清掉那些錯誤訊息；不要把整個 stack trace 丟進去，摘要成有用的資訊就好。你要思考的是：我想讓模型看到什麼，才能得到最好的結果？

Micro Agents：小而專注勝過大而全

Dex 分享了一個重要的發現：那個「給 LLM 一個目標，讓它自己找路」的夢想，在長流程中其實行不通。就算你用 Gemini 塞進兩百萬個 token，API 會回傳東西給你，但沒有人會說這樣得到的結果比精心控制的 Context 更可靠。Context 越長，模型越容易迷失。

真正運作良好的模式是 Micro Agents：你的主流程還是大部分確定性的 DAG（有向無環圖），只在特定節點放入小型的 Agent 迴圈，每個迴圈只處理 3-10 個步驟。HumanLayer 內部的部署機器人就是這樣運作的。大部分的 CI/CD 流程是確定性的程式碼，但當 PR 合併、測試通過後，會交給一個 Agent 來處理部署。這個 Agent 會提議「先部署前端」，人類可以說「不，先部署後端」，Agent 就調整計畫。一旦部署完成，控制權就回到確定性的程式碼，跑端對端測試。

這種設計的好處是：Context 可控、職責清楚、每個 Agent 只需要處理它擅長的事。Dex 引用了 NotebookLM 團隊的說法：找到模型能力的邊界——那個它不是每次都能做對的事——然後用工程手段讓它變得可靠。如果你能做到這點，你就創造了別人做不到的東西。

回歸軟體工程的本質

Dex 在結尾問了一個問題：「有人寫過 switch 語句嗎？寫過 while 迴圈嗎？」全場舉手。這就是他的重點：建構可靠的 Agent 不需要什麼神秘的 AI 背景，這就是軟體工程。LLM 是無狀態的函數，你管理狀態；控制流程是你的，不是框架的；Context Engineering——怎麼把對的資訊用對的方式送進模型——才是核心能力。

12-Factor Agents 在 GitHub 上發布後，一天內登上 Hacker News 首頁，兩個月內拿到四千多顆星。這說明很多開發者都有同樣的痛。他們不需要更多的框架魔法，他們需要的是清楚的原則、可控的架構、以及回歸工程本質的思維方式。

Agent 就是軟體。軟體工程的智慧——模組化、可測試、可觀察、掌控狀態——在這個新領域依然適用。差別只是，現在你的程式碼裡多了一個會輸出 JSON 的純函數，而你的工作是確保它看到對的東西、做對的事。