這兩年，AI Agent 變得很紅，但也正因為太紅，很多人其實是用一種很碎片化的方式在學它。

今天看 prompt，明天看 tool calling，後天又跳去看 memory、multi-agent、orchestration、runtime、Agent OS。每一塊你都好像看過，但它們彼此之間到底是什麼關係、各自在解哪一層的問題，很多文章其實沒有真的幫你串起來。

所以這篇文章不打算再往你腦中塞更多 buzzwords。
我想做的事情比較單純：把 AI Agent 重新排回一張地圖裡，讓你知道從 workflow、single-agent、multi-agent，到 system runtime，這條路到底是怎麼一路長出來的。

先別急著上 Agent：很多問題其實只是 Workflow

很多人一看到 LLM 會調工具、會跑多步驟，就直覺覺得這應該做成 agent。
但真正該先問的問題不是「能不能做成 agent」，而是：

這個流程能不能先被定義清楚？

如果可以，那 workflow 往往會是更穩、更便宜，也更容易 debug 的選擇。

像 prompt chaining、routing、evaluator-optimizer，這些看起來很聰明的模式，雖然都用了 LLM，但控制流其實還在你手上。你決定步驟怎麼串、輸入怎麼分流、什麼情況要回頭重做；模型只是完成局部任務，但不負責決定整個系統接下來往哪裡走。

只有當下一步無法在一開始就寫死，必須根據中途的 observation、工具結果或環境回饋動態決定時，agent 才真的有必要。

這也是第一個最重要的判斷：

能預先定義的流程，優先用 workflow；只有無法預先定義下一步時，才把控制權交給 agent。

Agent 的本質，其實就是把 ReAct 工程化

把所有包裝拿掉，agent 的本質其實沒有那麼神祕。

它就是把 ReAct 這件事工程化：模型先根據當前狀態思考接下來要做什麼，接著採取 action，從環境拿回 feedback，再根據新的 observation 決定下一步，直到任務完成或停止。

所以 agent 真正特別的地方，不是它「比較像人」，而是它不再只是一次性的輸入輸出，而是一個能根據環境回饋持續推進任務的動態控制迴圈。

問題不是只有「做一個 agent」，而是「系統怎麼撐住它」

一開始，大家想做的事情都很單純：讓模型不只是回答問題，而是真的能幫你做事。
於是我們開始替 LLM 接上工具、補上記憶、讓它能觀察環境並決定下一步。

但當任務變得更複雜之後，問題很快就不再只是「這個 agent 夠不夠聰明」，而是：

• 一個 agent 已經不夠用了
• 需要不同角色分工合作
• 需要交換資訊、協調流程、彼此檢查
• 需要狀態保存、流程恢復、權限管理、資源排程、錯誤追蹤

也就是說，AI Agent 這條路真正的演進，不是從「一個會做事的模型」變成「更多個會做事的模型」，而是從單點能力設計，一路走到整體系統設計。

而這也正是很多人卡住的地方：
你以為自己卡在模型，其實你卡在系統。

一條技術棧，四種不同層次的答案

當你把整條路重新排回來，就會發現 LangChain、LangGraph、AutoGen、AIOS 其實不是四個平行替代品，而是四個落在不同層次的設計答案。

1. LangChain：應用層的單 Agent 開發

如果你只是想把 model、prompt、tools、structured output、retrieval 這些元件快速串起來，做出一個可用的單 agent 或 LLM application，LangChain 幾乎就是最直覺的起點。

它最像的角色，是 app logic layer。
你可以拿它做 RAG、tool use、基本的 ReAct loop，快速把東西組起來。

2. LangGraph：當 Agent Logic 開始變成 Orchestration

當流程變長、狀態變多、控制流開始重要時，LangGraph 才真正登場。

它的價值不是「比較酷」，而是它把原本隱性的 agent loop 攤開成 graph：你可以明確定義 state、nodes、edges、conditional routing，讓流程變得可觀察、可恢復，也可插手。

如果 LangChain 比較像把元件組起來，LangGraph 更像是在編排整個執行流程。

3. AutoGen：把協作寫成結構化對話

如果說 LangGraph 比較像 graph first，那 AutoGen 最有代表性的視角，就是 conversation first。

它不是先把流程畫成圖，而是把多個 agent 視為在同一個任務裡輪流發言、共享上下文、互相回應的角色，透過結構化對話一步步把任務往前推進。

這一層的核心不是單一 agent 怎麼 loop，而是：

多個角色怎麼一起工作。

所以 AutoGen 更適合被理解成 collaboration layer。

4. AIOS：把 Agent 當成 Runtime Workload 來管理

再往下一層，問題就不再只是 agent 怎麼思考、怎麼協作，而是：

• 多個 agent 怎麼共享 LLM？
• memory / storage 怎麼管理？
• tools 怎麼避免互撞？
• 權限怎麼治理？
• 系統資源怎麼排程？

AIOS 的切入點就在這裡。
它不是另一個 agent framework，而是把 agent 視為需要被系統管理的 workload，從 runtime / system layer 去看整件事。

這時候你面對的，已經不是「怎麼再做一個 agent」，而是「怎麼管理一整個 agent system 的執行環境」。

Multi-Agent 真的比較厲害嗎？不一定

很多人走到 multi-agent，會被它的想像力吸引：分工、平行、角色化、互相審查，看起來很強。

而且它確實有合理的使用情境，例如：

• 不同 agent 負責不同專業
• 子任務彼此獨立，可以平行處理
• 高風險操作隔離在特定角色中
• 不同步驟用不同模型，做更細緻的成本控制

但 multi-agent 真正成立的前提，不是「看起來比較厲害」，而是任務本身真的有多角色、多專業、多並行的需求。

如果問題其實可以用單一 agent 加一條清楚的 workflow 解掉，那多加幾個 agent，很多時候只是在增加：

• 協調成本
• 訊息傳遞成本
• 系統複雜度
• 責任切分難度

也就是說，multi-agent 不是預設答案，而是一種在特定條件下才合理的設計選項。

你到底該用哪一個？

答案其實沒有那麼複雜：

• 流程清楚、可預先定義：先用 workflow
• 需要單 agent 的 tool use、RAG、基本 ReAct loop：從 LangChain 開始
• 流程開始變長、狀態開始變多、需要更明確控制：進入 LangGraph
• 任務真的需要多角色分工與協作：再看 AutoGen
• 系統真的大到碰到資源治理、記憶體與儲存管理、工具衝突與權限控制：才輪到 AIOS

所以真正重要的，不是先選框架，而是先判斷：

你現在遇到的，到底是哪一層的問題。

結語

很多人學 AI Agent，最後會越學越碎，不是因為不努力，而是因為從來沒有人先把這張地圖攤開給他看。

當你把 workflow、single-agent、multi-agent、runtime/system 這幾層重新接回來，很多原本看起來混亂的概念，其實就會突然變得很清楚。

這也是我想用這篇文章做的事：
不是再多教你一個框架，而是先幫你看懂 Agent Systems 的全局。

完整版在哪？

這篇是精華導讀版。
如果你想看 完整長文版本，包含：

• 更完整的系統脈絡
• LangChain / LangGraph / AutoGen / AIOS 的逐層展開
• 實戰程式碼與圖解
• 為什麼大多數人其實把 Agent Systems 的層次搞混了

完整版我放在 Medium：

👉【Medium 完整版】