秉承 十二要素應用程式 的精神。本專案的原始碼公開在 https://github.com/circleghost/12-factor-agents ，歡迎你的回饋和貢獻。讓我們一起探索這個領域！

嗨，我是 Dex。我一直在探索 AI agents 已經一段時間了。

我已經試過市面上所有的 agent 框架，從隨插即用的 crew/langchains 到世界上「極簡主義」的 smolagents，再到「生產級」的 langraph、griptape 等等。

我與許多非常優秀的創辦人交談過，無論是 YC 內外的，他們都在用 AI 建造令人印象深刻的東西。他們大多數都在自己搭建技術棧。我在生產環境面向客戶的 agents 中沒有看到太多框架的身影。

我驚訝地發現，市面上大多數自稱為「AI Agents」的產品實際上並不那麼具有智能體特性。它們大多是確定性的程式碼，只是在恰當的地方點綴一些 LLM 步驟，讓體驗真正神奇。

Agents，至少是好的 agents，不會遵循「這是你的提示詞，這是一包工具，循環直到達成目標」的模式。相反，它們主要由軟體組成。

所以，我著手回答：

我們可以使用什麼原則來建構真正足夠好、能夠交付給生產客戶使用的 LLM 驅動軟體？

歡迎來到十二要素 agents。正如芝加哥自 Daley 以來的每一位市長都在該市主要機場一致地到處張貼的標語一樣，我們很高興你來到這裡。

特別感謝 @iantbutler01、@tnm、@hellovai、@stantonk、@balanceiskey、@AdjectiveAllison、@pfbyjy、@a-churchill 以及 SF MLOps 社群對本指南的早期回饋。

即使 LLMs 持續以指數方式變得更強大，仍然會有核心的工程技術能夠讓 LLM 驅動的軟體更可靠、更可擴展、更易於維護。

• 我們如何走到這裡：軟體簡史
• 要素 1：自然語言到工具呼叫
• 要素 2：擁有你的提示詞
• 要素 3：擁有你的上下文視窗
• 要素 4：工具只是結構化輸出
• 要素 5：統一執行狀態與業務狀態
• 要素 6：用簡單的 APIs 啟動/暫停/恢復
• 要素 7：透過工具呼叫聯繫人類
• 要素 8：擁有你的控制流程
• 要素 9：將錯誤壓縮到上下文視窗
• 要素 10：小型、專注的 Agents
• 要素 11：從任何地方觸發，在使用者所在的地方與他們相遇
• 要素 12：讓你的 agent 成為無狀態的 reducer

想深入了解我的 agent 之旅以及是什麼讓我們走到這裡，請查看軟體簡史 - 這裡是快速摘要：

我們將大量討論有向圖 (DGs) 和它們的無環朋友 DAGs。我首先要指出的是...嗯...軟體就是一個有向圖。我們過去用流程圖來表示程式是有原因的。

大約 20 年前，我們開始看到 DAG 編排器變得流行。我們說的是像 Airflow、Prefect 這樣的經典工具，一些前身，以及一些較新的工具如 (dagster、inggest、windmill)。這些都遵循相同的圖形模式，但增加了可觀測性、模組化、重試、管理等好處。

我不是第一個這樣說的人，但當我開始學習 agents 時，我最大的收穫是你可以拋棄 DAG。軟體工程師不用編碼每個步驟和邊緣情況，你可以給 agent 一個目標和一組轉換：

並讓 LLM 即時做決定來找出路徑

這裡的承諾是你寫更少的軟體，你只需要給 LLM 圖的「邊」，讓它來找出節點。你可以從錯誤中恢復，你可以寫更少的程式碼，你可能會發現 LLMs 為問題找到新穎的解決方案。

正如我們稍後會看到的，事實證明這並不完全奏效。

讓我們再深入一步 - 使用 agents 時，你有一個包含 3 個步驟的迴圈：

1. LLM 決定工作流程中的下一步，輸出結構化 json (「tool calling」)
2. 確定性程式碼執行工具呼叫
3. 結果被附加到上下文視窗
4. 重複直到下一步被確定為「完成」

initial_event = {"message": "..."}
context = [initial_event]
while True:
  next_step = await llm.determine_next_step(context)
  context.append(next_step)

  if (next_step.intent === "done"):
    return next_step.final_answer

  result = await execute_step(next_step)
  context.append(result)

我們的初始上下文只是開始事件 (可能是使用者訊息，可能是 cron 觸發，可能是 webhook 等)，我們要求 llm 選擇下一步 (工具) 或決定我們已經完成。

這是一個多步驟的例子：

歸根究底，這種方法並不像我們希望的那樣有效。

在建構 HumanLayer 時，我與至少 100 位 SaaS 建構者 (主要是技術創辦人) 交談過，他們希望讓現有產品更具智能體特性。這個旅程通常是這樣的：

1. 決定你想建構一個 agent
2. 產品設計、UX 對應、要解決什麼問題
3. 想要快速行動，所以抓取 $FRAMEWORK 並開始建構
4. 達到 70-80% 的品質標準
5. 意識到 80% 對於大多數面向客戶的功能來說是不夠的
6. 意識到要超越 80% 需要逆向工程框架、提示詞、流程等
7. 從頭開始

在挖掘了數百個 AI 函式庫並與數十位創辦人合作後，我的直覺是這樣的：

1. 有一些核心的東西讓 agents 變得優秀
2. 全力投入一個框架並建構本質上是全新重寫的東西可能會適得其反
3. 有一些核心原則讓 agents 變得優秀，如果你引入一個框架，你會得到大部分/全部這些原則
4. 但是，我見過的讓建構者將高品質 AI 軟體交付給客戶的最快方式是從 agent 建構中取用小型、模組化的概念，並將它們融入到現有產品中
5. 這些來自 agents 的模組化概念可以由大多數熟練的軟體工程師定義和應用，即使他們沒有 AI 背景

我見過的讓建構者將優秀 AI 軟體交付給客戶的最快方式是從 agent 建構中取用小型、模組化的概念，並將它們融入到現有產品中

• 我們如何走到這裡：軟體簡史
• 要素 1：自然語言到工具呼叫
• 要素 2：擁有你的提示詞
• 要素 3：擁有你的上下文視窗
• 要素 4：工具只是結構化輸出
• 要素 5：統一執行狀態與業務狀態
• 要素 6：用簡單的 APIs 啟動/暫停/恢復
• 要素 7：透過工具呼叫聯繫人類
• 要素 8：擁有你的控制流程
• 要素 9：將錯誤壓縮到上下文視窗
• 要素 10：小型、專注的 Agents
• 要素 11：從任何地方觸發，在使用者所在的地方與他們相遇
• 要素 12：讓你的 agent 成為無狀態的 reducer

• 要素 13：預取所有你可能需要的上下文

• 在這裡為本指南做出貢獻
• 我在 2025 年 3 月的 Tool Use podcast 節目中談論了很多這些內容
• 我在 The Outer Loop 寫一些關於這些內容的文章
• 我與 @hellovai 一起舉辦關於最大化 LLM 效能的網路研討會
• 我們在 got-agents/agents 下使用這種方法建構 OSS agents
• 我們忽略了自己所有的建議，建構了一個在 kubernetes 中執行分散式 agents 的框架
• 本指南的其他連結：
  • 12 Factor Apps
  • 建構有效的 Agents (Anthropic)
  • Prompts are Functions
  • 函式庫模式：為什麼框架是邪惡的
  • 錯誤的抽象
  • Mailcrew Agent
  • Mailcrew 示範影片
  • Chainlit 示範
  • TypeScript for LLMs
  • Schema Aligned Parsing
  • Function Calling vs Structured Outputs vs JSON Mode
  • BAML on GitHub
  • OpenAI JSON vs Function Calling
  • Outer Loop Agents
  • Airflow
  • Prefect
  • Dagster
  • Inngest
  • Windmill
  • The AI Agent Index (MIT)
  • NotebookLM on Finding Model Capability Boundaries

感謝所有為十二要素 agents 做出貢獻的人！

所有內容和圖像均根據 CC BY-SA 4.0 授權 授權

程式碼根據 Apache 2.0 授權 授權