https://yennj12.js.org/yennj12_blog_V4/tags/autogen/Recent content in AutoGen on YennJ12 Engineering BlogHugo -- gohugo.ioen-usSun, 21 Jun 2026 23:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase14-part3-frameworks-zh/Sun, 21 Jun 2026 23:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase14-part3-frameworks-zh/大多數工程師的選擇：「先裝一個框架，之後再說。」 有經驗的工程師的選擇：「先定義 Agent 的交互模式，再選能支撐它的框架。」 框架給你速度，但也給你它的限制；抽象層降低入門門檻，但隱藏了你最需要控制的細節。 正確的問題不是「哪個框架最好」，而是「這個框架的抽象層，跟我的問題邊界對不對齊」。 面試情境 你的團隊正在構建一個客服自動化系統，需要協調「意圖分類 Agent」、「知識庫查詢 Agent」、「回應生成 Agent」與「品質審核 Agent」四個角色。面試官問：「你會選 AutoGen、CrewAI 還是 LangGraph？為什麼？如果規模到每日 50 萬次對話，架構需要如何演進？」 一、核心問題：框架選型的本質是什麼 Agent 框架的選型問題，表面上是技術選擇，本質上是控制權與抽象層的交換。 每個框架都做了一組隱性決策： 執行模型：對話驅動 vs. 圖驅動 vs. 任務佇列驅動 狀態管理：記憶體內 vs. 持久化 vs. 外部化 Agent 通訊：廣播 vs. 點對點 vs. 中介者模式 錯誤恢復：重試策略、fallback 路徑、人工介入點 選錯框架的代價不是「換框架」這麼簡單。當你的 Agent 邏輯與框架的執行模型深度耦合後，重構成本等同於重寫。 框架的三個本質問題 問題 1：誰決定下一步由誰執行？ ├── 框架決定 → 高度結構化，靈活性低 ├── LLM 決定 → 靈活但不可預測 └── 工程師的程式碼決定 → 可控但需要更多開發工作 問題 2：狀態存在哪裡？ ├── 對話歷史 (messages list) → 簡單，但 token 成本高 ├── 結構化狀態物件 → 可查詢，但需要 schema 設計 └── 外部資料庫 → 持久化，但增加延遲 問題 3：出錯時怎麼辦？ ├── 讓 LLM 自己決定 → 彈性，但不可靠 ├── 框架的重試機制 → 簡單，但缺乏語意 └── 工程師的顯式錯誤處理 → 精確，但需要更多程式碼 理解這三個問題的答案，才能判斷一個框架是否適合你的用例。