AI 代理框架的設計光譜：從 LangGraph 的單行道到企業級巨獸

今天的任務是研究 Agentic Design Patterns 附錄 C：當前科技界最熱門的 AI 代理（AI Agents）到底怎麼被建造出來。這不僅僅是一堆程式碼的集合，而是一場設計哲學的抉擇——不同建築師會用截然不同的理念去設計同一棟大樓。在討論如何打造一個由幾十個 AI 組成的複雜團隊之前，我們得先了解單一 AI 的大腦怎麼運作。

基礎設施之爭：LangChain 的單行道對上 LangGraph 的迴圈

首先遇到的是基礎設施層面的對決：LangChain 對上 LangGraph。LangChain 的核心使用有向無環圖（DAG）架構——用最白話的方式說，它就是一條單行道。資料流動完全線性，任務從 A 點進去、走到 B 點、從 C 點出來，而「無環」意味著整個流程沒有迴圈，AI 不能走回頭路。

當任務明確、步驟固定時，這種高度可預測的設計非常適合。例如常見的 RAG（檢索增強生成）系統：去資料庫找一份文件，跟問題打包在一起丟給模型，模型吐出答案，就是一條筆直的流水線。

LangChain：得來速車道（DAG，單行道）
────────────────────────────────────
① 點餐 ──► ② 付錢 ──► ③ 拿漢堡 ──► 離開
   │
   └─ 突然想換玉米湯？這條車道沒有倒車機制，整條卡住

這個得來速的比喻很貼切——它追求流水線式的效率，但現實世界的複雜任務往往不是直線。這正是同一個開發團隊後來推出 LangGraph 的原因。

LangGraph 在原本的基礎上引入了節點與邊的概念，最大的變革在於徹底打破那條單行道：它允許迴圈（Loops）與狀態（State）管理。透過狀態管理，AI 就像有了一塊共享黑板——每執行完一個步驟，就把結果寫在黑板上，然後自行解釋這個結果。若發現走錯方向，或呼叫的外部工具失敗，因為有迴圈的機制，它可以退回上一步重試，或換一個方法。

LangGraph：廚師試喝湯（節點 + 邊 + 迴圈）
─────────────────────────────────────────
把食材放進鍋裡（節點）
   │
   ▼
舀一口試喝（評估當下狀態） ◄──────────────┐
   │                                      │
   ├─ 不夠鹹 ──► 加鹽（進入迴圈）──────────┘
   └─ 味道對了 ─► 端上桌

而且它可以在發現自己無法做決定時暫停整個迴圈，傳送通知給人類，等待人類在黑板上寫下新的指令後再繼續——這就是人機迴圈（Human-in-the-Loop）。當任務需要規劃與執行、複雜到不能只給 AI 一份固定的 SOP 時，就需要這種能自行試錯並修正的結構。開發者可以極度精細地控制這個「廚師大腦」裡的每一個思考迴路。

LangChain 與 LangGraph 的實作差異

以 LangGraph 定義狀態與節點的示意：

// Graph state：在節點之間傳遞並持續更新的狀態物件
type AgentState = {
  topic: string
  plan?: string
  result?: string
  attempts: number
  errors: string[]
}

// 節點：一個函式，接收狀態、回傳更新後的狀態
function planStep(state: AgentState): Partial<AgentState> {
  const plan = llm.invoke(`規劃如何處理：${state.topic}`)
  return { plan }
}

function retryWithFallback(state: AgentState): Partial<AgentState> {
  // 迴圈機制：失敗就重試，直到成功或耗盡次數
  if (state.attempts < 3) {
    return { attempts: state.attempts + 1 }
  }
  throw new Error('超過重試上限')
}

關鍵判斷很直接：如果應用程式有清晰、可預測、線性的步驟流程（A → B → C），選擇 LangChain；如果代理需要迴圈推理、反思結果、用不同方法重試，選擇 LangGraph。

團隊協作層次：Google ADK 的裝配線對上 CrewAI 的辦公室

了解單一大腦的運作方式後，我們把規模擴大一點。當需要一整群 AI 解決更大的問題時，若還手動規劃每個節點與迴圈，就太沒有效率了。這就進入團隊協作的層次，兩個對比極其強烈的框架：Google 的 ADK（代理開發套件） 與 CrewAI。

Google ADK：固執的工廠裝配線

資料描述 Google 的 ADK 為「高度固執（opinionated）」。日常生活中說人固執不是好話，但在軟體工程裡，固執是中性甚至偏正面的詞——意味著 Google 的工程師已經替我們決定了最佳實踐。ADK 把底層複雜的節點、邊、狀態傳遞全部隱藏起來，直接提供預先建構好的架構。

例如它提供循序代理（SequentialAgent）與平行代理（ParallelAgent），我們不需要煩惱這些 AI 底層怎麼溝通，軌道都鋪好了。這就像一條工廠自動化裝配線：把擁有特定技能的機器人放進對應的工作站，生產線就能穩定運轉。對需要高度穩定、可預期的企業級應用來說，這種固執能省下大量開發時間。

// Google ADK：用預先建構的代理型別組合，不必手動連接節點與邊
import { LlmAgent, SequentialAgent, ParallelAgent } from '@google/adk'

const researchAgent = new LlmAgent({
  name: 'research',
  model: 'gemini-2.5-flash',
  instruction: '搜尋資料並整理重點',
})

const writingAgent = new LlmAgent({
  name: 'writer',
  model: 'gemini-2.5-pro',
  instruction: '根據研究結果撰寫報告',
})

const team = new SequentialAgent({
  name: 'report_team',
  sub_agents: [researchAgent, writingAgent], // 依序執行，控制流由框架自動管理
})

CrewAI：定義角色、目標與背景故事

CrewAI 走的完全相反——它專注於模擬人類團隊。我們不再是冰冷的工廠廠長，而是辦公室的 CEO：不去畫流程圖，而是定義任務與參與者。CrewAI 要求為每個 AI 代理定義他的角色、目標，甚至背景故事。

這看起來像在玩龍與地下城的桌遊，但從大型語言模型的底層運作機制來看，這是嚴謹的系統工程。語言模型本質上是透過龐大的機率預測下一個字，如果不給它明確的限制，它給出的答案就會是最平均、最平庸的那個。設定背景故事，其實是在收縮機率分佈——例如告訴 AI「你是華爾街二十年風險控管經驗、說話嚴謹、總優先考慮最壞情況的資深分析師」，就是在嚴格收縮它的運算空間，改變行為模式與決策邏輯。當它與扮演樂觀行銷總監的 AI 溝通時，那種化學反應就出來了。

// CrewAI：定義代理的角色、目標與背景故事（TypeScript 示意）
const riskAnalyst = new Agent({
  role: '資深風險分析師',
  goal: '優先考慮最壞情況，評估每個方案的風險',
  backstory: '在華爾街有二十年風險控管經驗，說話嚴謹',
})

const marketingLead = new Agent({
  role: '行銷總監',
  goal: '放大方案的成長潛力與市場機會',
  backstory: '天生的樂觀主義者，擅長找出機會',
})

const crew = new Crew({
  agents: [riskAnalyst, marketingLead],
  process: Process.sequential,
})

專業領域框架：MetaGPT、LlamaIndex 與 AutoGen

前述框架偏向通才管理，但有些框架已針對特定領域把標準作業程序（SOP）固化下來。資料提到的三個框架是 MetaGPT、LlamaIndex 與微軟的 AutoGen，各有專攻。

MetaGPT 模仿一間軟體開發公司，內建產品經理、架構師、工程師等角色，且強制規定角色之間必須傳遞結構化的檔案——扮演產品經理的 AI 必須真的產出一份標準的 PRD（產品需求文件），架構師拿到這份文件後才能開始畫系統設計圖。這種強制性 SOP 讓它在生成複雜程式碼時穩定度極高。

LlamaIndex 就像一個盡責的圖書館員：問它任何歷史財報，它都能把資料整理得井井有條端到面前，但缺乏主動性，不會自行規劃新專案。AutoGen 則像一群被關在會議室裡的天才，創意十足但極度不可預測——如果沒有嚴謹的提示工程控制，就會演變成多代理系統最常見的災難：無止境的發散。它們可能為了一個網頁按鈕該用深藍色還是淺藍色爭論三個小時，消耗大量運算資源，最後什麼程式碼都沒產出。

企業級火力展示：從穩定、監控到老系統手術

當我們把實驗室裡運作良好的小工具搬進大型企業，變成需要二十四小時維持生命週期、處理海量流量的系統時，就需要更重型的解決方案。企業級考量的重點從「這個 AI 多聰明」變成「這個系統多穩定、可用性多高」。

失敗迴圈為什麼是企業的剛需

為什麼處理失敗迴圈在企業環境裡這麼重要？因為 AI 代理一旦失控，就直接造成成本損失。假設我們用 LangGraph 寫了一個自動上網找資料的 AI，它剛好遇到一個失效的網頁連結——如果系統沒有妥善的管理機制，這個 AI 可能在一秒鐘之內重試一千次，而這一千次 API 呼叫全部要付費。若發生在週末，星期一看到帳單就為時已晚。所以像 SuperAGI 這種能監控資源、自動中斷失控迴圈的機制，是企業應用的剛需。

Semantic Kernel：給老系統植入思考的腦袋

Semantic Kernel 透過外掛（Plugins）與規劃器（Planners）將語言模型與常規程式碼深度整合。很多大型企業已經有幾百萬行、穩定運行十幾年的舊系統，那個系統可能比年輕工程師的年紀還大，不可能為了導入 AI 就把整個訂單系統打掉重練。Semantic Kernel 的強大在於規劃器可以理解使用者的意圖，自動呼叫那些舊有的 C# 或 Python 函式來完成任務——把語言模型當作一個推理引擎，等於為老舊僵硬的系統植入一顆懂思考的頭腦，自動指揮舊系統的各種手腳。這符合企業對漸進式創新的保守需求。

// Semantic Kernel：語言模型作為推理引擎，呼叫既有函式（TypeScript 示意）
const orderService = kernel.addPlugin(new OrderPlugin()) // 既有訂單系統函式

// 規劃器理解使用者意圖，自動組合並呼叫既有函式
const result = await kernel.invokeAsync('查詢訂單 O-12345 的退款狀態', {
  plugins: [orderService],
})

AWS Bedrock Agents：輕量、與模型無關、原生 MCP

AWS 走的是另一條路：輕量、與任何模型無關，甚至原生整合了 MCP（模型上下文協定）。過去要讓 AI 讀取公司的 Slack 或在 Jira 建立任務，開發者必須針對每個外部工具手寫客製化的 API 串接程式碼；MCP 就像萬用轉接頭，只要外部工具支援 MCP，代理就能立刻無縫讀取或操作，大幅降低整合的摩擦力。MCP 的完整架構可參考這裡-MCP：讓 AI 從只會聊天到真正做事。

但輕量也有代價，這引出工程界永恆的權衡難題：自建還是購買（Build vs Buy）。AWS Bedrock Agents 只提供了核心代理邏輯與萬用轉接頭，至於外圍的監控儀表板、錯誤日誌追蹤、甚至防止 AI 燒錢的迴圈保護機制，全部要自己一磚一瓦蓋起來，與 SuperAGI 那種包山包海的完整平台形成對比——這是每個技術長都要面對的選擇。

對 UI/UX 的影響：代理框架的選擇如何決定使用者體驗

框架選擇表面上是後端工程決策，實際上會直接影響使用者與 AI 互動的體驗，可以從三個面向觀察。

第一，框架的「能見度」決定使用者能看到多少代理行為。 LangChain 的線性流程適合把「步驟清單」呈現給使用者——目前執行到第幾步、還有幾步；LangGraph 的迴圈結構則需要把「重試與反思」也視覺化，否則使用者會看到代理在同一件事上反覆嘗試卻不明白原因。CrewAI 的角色扮演框架則適合用「任務看板」呈現——哪個角色負責什麼、現在進行到哪個任務。UI 設計應該對應框架的抽象層級，而不是一律用聊天視窗呈現。

第二，人機迴圈的介面是關鍵節點。 LangGraph 支援暫停迴圈等待人類在黑板上寫下指令，這類 HITL 節點若沒有好的介面，就會變成卡死的工作流。完整的授權與介入介面設計，可參考這裡-AI 為什麼需要人類救場：Human-in-the-Loop 架構探討。

第三，企業級框架的選擇影響「信任感」的呈現。 選擇 Semantic Kernel 改造老系統時，使用者需要看到「AI 正在呼叫哪個既有系統的哪個函式」；選擇 AWS Bedrock Agents 這類輕量框架時，因為監控設施要自己建，介面更要主動呈現代理的每一次工具呼叫與結果，才能補足信任感。

前後端技術怎麼實作

對應上述 UI/UX 影響，前後端有一條清晰的分工線。

後端：以框架的原生事件為單位串流輸出

不管選擇哪個框架，後端都應該把代理的執行軌跡轉成結構化事件推送給前端，而不是等整個流程結束才回傳一個結果：

type AgentEvent =
  | { type: 'step'; step: number; total: number; label: string }        // LangChain 線性步驟
  | { type: 'retry'; reason: string; attempt: number }                  // LangGraph 迴圈重試
  | { type: 'tool_call'; tool: string; input: string; output: string }  // 工具呼叫
  | { type: 'hitl_wait'; reason: string }                               // 等待人類介入
  | { type: 'done'; result: string }

前端：依事件型別渲染對應的介面元件

• step → 進度條與步驟清單
• retry → 顯示重試原因與次數，避免使用者以為代理卡住
• tool_call → 工具呼叫紀錄面板，讓使用者知道代理「正在做什麼、用了什麼工具」
• hitl_wait → 彈出人類介入面板，呈現當下狀態與選項
• done → 呈現最終結果

這個分工讓框架的執行軌跡變成使用者看得懂的流程，也讓「代理到底在忙什麼」不再是一個黑箱。

總結

整個 AI 代理框架生態圈其實是一條光譜。在最左邊，是提供細緻控制權的基礎工具，像是 LangGraph——適合需要精確控制 AI 每一個思考步驟的場景。在最右邊，是幫我們把架構、角色、甚至 SOP 都固化下來的平台，像是 CrewAI 或 MetaGPT——犧牲底層控制權，換來開箱即用與開發速度。而在光譜的另一端，是像 Semantic Kernel 這樣專注與既有 IT 基礎設施深度融合的企業級方案。

選擇框架不該看哪個框架在 GitHub 上的星星比較多，而是要問自己：目前面臨的具體商業問題是什麼？ 是找資料（LlamaIndex）、要突破性創意（AutoGen）、穩定開發軟體（MetaGPT），還是要穩定與監控（SuperAGI）、整合老系統（Semantic Kernel）、輕量靈活（AWS Bedrock Agents）？

深入思考：既然 MetaGPT 這樣的框架已經強大到能讓 AI 扮演軟體工程師、根據需求文件寫出高品質程式碼，那麼在不久的將來，是不是會有這些聰明的 AI 代理，自行運用光譜上的框架，開始為自己設計下一代更強大的 AI 代理框架？當代理開始建造代理、虛擬員工開始自己設計下一代虛擬員工時，人類在這條流水線上的位置又會在哪裡？這是一個值得深思的問題。

參考資料

• Agentic Design Patterns - Appendix C: Quick Overview of Agentic Frameworks
• LangChain
• LangGraph
• Google ADK
• CrewAI
• MetaGPT
• LlamaIndex
• Microsoft AutoGen
• Haystack
• SuperAGI
• Semantic Kernel
• AWS Bedrock Agents