2026 開源 agent 堆疊拆成七層

O’Reilly 2026 指南把開源 agent 工具拆成七層，幫團隊用生產需求挑工具。

2026 年的開源 agent 世界，已經不是「選一個大框架」這麼簡單。Paolo Perrone 在 O’Reilly Radar 2026 年 7 月 14 日的文章，直接把工具拆成七層。這個切法很務實，因為 demo 好看，和上線穩定，根本是兩回事。

文章最狠的一點，是拿數字戳破幻覺。某個記憶框架在 LoCoMo 長對話記憶基準拿下好成績，卻可能比第二名重 340 倍。這種差距，足以改掉整個架構決策。

七層拆法，才是這篇真正的重點

Perrone 的核心觀點很直接。agent 堆疊已經分成七層：orchestration、memory、tool interface、browser 或 computer-use tools、coding agents、evals 與 observability、inference。這個拆法有用，因為每一層的瓶頸都不同。

你如果把所有問題都丟給同一個框架，最後常常會卡在奇怪的地方。像是延遲太高、稽核軌跡不完整、模型綁死單一供應商，或是 Python 與 TypeScript 團隊互相看不順眼。這些都不是 demo 會先告訴你的事。

文章也把 open source 和 open core 劃清楚。若多租戶權限、複寫、SSO、audit log 只在雲端版，repo 再漂亮也不代表你能安心上 production。這點很現實，也很像工程師每天在踩的坑。

• Latency budget 決定每輪能花多少時間和 Token。
• Audit trail 決定系統能不能被追查。
• Model portability 決定你會不會被單一模型綁住。
• Language stack 決定團隊能不能真的維護。

Orchestration 層最容易先爆

在 orchestration 層，文章把 LangGraph 放在 Python 生產環境的預設位置。原因不是聲量，而是它處理 state 的方式很適合上線系統。durable execution、checkpointing、time-travel debugging，這些功能都很像為事故報告而生。

如果你的系統要留痕，LangGraph 的設計就很對味。它的 PostgresSaver 也讓狀態落地更自然，對台灣很多已經有 Postgres 的團隊來說，導入成本不算離譜。

但它也不便宜。簡單的兩個 agent 流程，還是得先定 state schema、node、edge，再 compile。若你的需求只是順序呼叫三個工具，這套東西會顯得很重，像拿卡車送一個背包。

“The best way to zero in on the constraint your system will hit first under load: latency budget, audit trail, model portability, or language stack.”

Paolo Perrone, O’Reilly Radar, 2026-07-14

這句話很準。它把 agent 選型從「哪個功能最多」拉回「哪個瓶頸先炸」。工程上，這才是比較像樣的問題。

輕量工具贏在小問題

這篇文章沒有把所有工具都往同一個天平上放。CrewAI 的定位很清楚，就是低門檻。你定好 researcher、writer、reviewer 這種角色，它就能跑，對原型或內部試驗很快。

但快是有代價的。CrewAI 的 crash recovery 沒有做到 node 級別，錯誤處理也偏向 crew 層級。當你要做 postmortem，或要跟法遵、客服、SRE 對齊時，這種抽象就不夠細。

Pydantic AI 則走另一條路。它把輸出綁到 typed Pydantic model，對單回合 agent 很友善。驗證和序列化都乾淨，接下游服務時少很多髒活。

• LangGraph：適合需要 state 與重試的 Python 生產流程
• CrewAI：適合快速做角色式原型
• Pydantic AI：適合 typed 單 agent 輸出
• Mastra：適合 TypeScript 團隊和 Next.js 專案

TypeScript 團隊則常會看 Mastra。它把 agents、workflows、RAG、evals 包在一起，對已經在 Next.js 裡做產品的人很順。你不用先拉一個 Python sidecar，這點很實際。

我覺得這裡最有價值的，是文章沒有硬推單一解法。團隊語言棧已經是 TypeScript，就別為了追風去硬上 Python。反過來說，如果你要的是可追查、可回放、可重試，Python 生態還是比較成熟。

分數好看，不代表成本漂亮

這篇最值得記住的，是它對 benchmark 的態度。分數高，不代表總成本低。記憶框架在 LoCoMo 上拿好成績，卻可能重 340 倍，這種結果會直接影響伺服器成本和延遲。

同樣的邏輯也適用在其他層。browser tools 可能在簡單頁面很好用，但遇到 canvas-heavy 網站就開始出事。evals 如果只放在 Notion 裡，最後很容易變成大家都說自己有測，但誰也找不到測試紀錄。

inference 層更不用說。你一旦把所有流程綁在單一模型供應商上，後面換模型的代價會很高。這也是為什麼文章一直強調要先看失敗模式，而不是先看排行榜。

• 記憶層：看的是延遲和記憶成本。
• 瀏覽器層：看的是網站相容性。
• 評測層：看的是可重現性。
• 推論層：看的是模型切換彈性。

這波工具分化，跟 2024 不一樣了

幾年前，很多團隊還在找「一個框架解決全部」的答案。現在不太行了。agent 工具已經分工，大家各做各的強項，這反而比較像正常軟體工程。

對台灣團隊來說，這代表選型要更務實。金融、電商、客服、SaaS 的需求差很多。你要的是審計、重試、權限，還是快速出原型，答案會完全不同。

所以這篇文章的價值，不在於它幫你選出唯一冠軍。它做的是把問題切小，讓你先問自己：哪一層最先壞？哪一層最貴？哪一層最難追？這三題答不出來，選工具多半也會選歪。

先看瓶頸，再決定堆疊

如果你現在要做 agent，我會直接建議先畫出失敗路徑。你的系統是怕延遲，怕資料外洩，怕模型鎖死，還是怕維護成本爆掉。這些答案會比社群聲量更有用。

我的判斷很簡單。2026 年的開源 agent 市場，不會獎勵最花俏的 demo。它會獎勵能在 production 撐住的堆疊。先選層，再選工具，會少很多冤枉路。