Agent 設計模式

Workflow vs Agent：先搞清楚你要什麼

一個反直覺的觀點：最成功的 AI 實現，往往不是最複雜的那個。在動手搭 Agent 框架之前，先搞清楚你真正需要什麼。

核心洞察

"The most successful implementations weren't using complex frameworks or specialized libraries. Instead, they were building with simple, composable patterns."

這句話值得每個 AI 產品經理背下來。行業裏充斥着各種 Agent 框架（LangChain、AutoGen、CrewAI...），但生產環境反覆驗證的規律是：真正跑得好的系統，用的是最樸素的組合模式。

兩個核心概念

Workflow

LLM 和工具通過預定義的程式碼路徑編排。開發者在寫程式碼時就決定了執行順序：先做 A，再做 B，最後做 C。

關鍵詞：確定性、可預測、開發者控制流程

Agent

LLM 動態決定自己的執行流程和工具使用。模型在每一步自主判斷下一步做什麼、要不要調用工具、什麼時候結束。

關鍵詞：自主性、動態決策、模型控制流程

流程對比

Workflow：程式碼決定流程

輸入

步驟 A

步驟 B

輸出

Agent：模型決定流程

輸入

LLM 決策

工具 / 思考 / 再決策

輸出

差異對比

維度	Workflow	Agent
控制權	開發者（程式碼路徑固定）	模型（每步動態決定）
可預測性	高 -- 輸入確定則輸出路徑確定	低 -- 同樣輸入可能走不同路徑
適用場景	任務拆解明確、步驟固定	任務開放、需要靈活決策
成本	可控（調用次數固定）	不確定（循環次數未知）
調試難度	低（路徑確定，容易復現）	高（行為不確定，難以復現）
典型例子	文案生成管道、數據清洗流水綫	Cursor、Claude Code、Devin

什麼時候不要用 Agent

大多數情況下，你不需要 Agent

實踐證明：對於大多數應用場景，優化單次 LLM 調用配合檢索增強（RAG）就夠了。只有當簡單方案明確無法滿足需求時，才應考慮引入 Workflow 或 Agent 的複雜度。

常見的過度設計：用一個 Agent 框架來做本質上一個 Prompt 加一次搜索就能解決的問題。框架引入的延遲、成本、不確定性遠大於它帶來的收益。

核心原則：複雜度階梯

先找最簡方案，複雜度只在明確提升效果時才加

1 先試單次 LLM 調用：優化 Prompt、加 Few-shot、調 Temperature
2 不夠？加檢索增強（RAG）：讓 LLM 能存取外部知識
3 還不夠？用Workflow：把任務拆成多步，用程式碼控制流程
4 真的需要靈活決策？才上Agent：讓模型自主規劃執行

不是所有問題都需要 Agent，很多時候 Workflow 就夠了，甚至一個精調的 Prompt 就夠了。複雜度是成本，不是功能。只在明確帶來收益時才增加複雜度。