想自己做一個 AI Agent,該準備哪些工具?2026 開發者工具鏈全圖解

週五下午,一位朋友傳來他的 Agent demo 影片:使用者打一句話,Agent 自己查資料、呼叫了三個 API、回了一段條理分明的摘要。漂亮。我問他:「上線了嗎?」他沉默兩秒,回:「上線那版,昨天把客戶的訂單編號帶錯到退款流程去了,我們現在不知道是哪一步出的錯。」

這幾乎是每個自建 Agent 團隊都會踩到的同一個坑。Demo 是一條順風路,生產環境是一張網——任何一個節點失手,整條鏈就斷,而你常常連斷在哪都不知道。差別不在模型多聰明,在於你身後那條工具鏈夠不夠完整。

為什麼 2026 是「工具鏈」而不是「一個框架」

2023、2024 年大家問的是「用哪個框架做 Agent」。到了 2026,這個問題已經問錯了。框架只是最上面一層。一個真的能上線、能維運、出事能查的 Agent,背後是一條分工明確的堆疊——就像後端工程不會只有一個 Web framework,還要有資料庫、快取、日誌、監控、CI/CD。

Agent 的特別之處在於它「不確定」。同樣的輸入,模型可能給出不一樣的步驟;它會自己決定要不要呼叫工具、呼叫哪個。這種不確定性,讓傳統那套「寫好就跑、跑壞看 stack trace」的開發習慣整個失效。你需要新的一層層工具,專門對付「它為什麼這樣做」「它做對了沒」「它在線上又出什麼狀況」這些問題。

重點:把工具鏈拆成六層

我習慣把自建 Agent 的工具鏈拆成六層,由上而下:

• 框架層:決定 Agent 怎麼定義、怎麼呼叫工具、怎麼管多步驟流程。
• 檢索層(RAG):讓 Agent 讀得到你的私有資料,而不是只會背模型內建的知識。
• 執行沙箱層:Agent 要跑程式碼、執行指令時,給它一個關得住的籠子。
• 可觀測性層:把每一步推理、每一次工具呼叫記下來,讓你看得見它在想什麼。
• 評測與安全層:上線前用一套固定題庫量它的表現,順便做紅隊測試。
• 部署層:把這一坨東西穩定地、可擴展地放到線上。

不是每個專案都需要六層全開。但你至少要知道每一層存在,以及自己現在缺了哪一層。

逐層拆解:每層解決什麼、何時才需要

框架層:Pydantic AI 與 LangChain

框架幫你處理「怎麼把模型、工具、流程黏在一起」這件事。Pydantic AI 是這兩年很多 Python 工程師轉過去的選擇,因為它把輸出用 type schema 綁死——Agent 回什麼,你拿到的就是一個結構化、驗證過的物件,而不是一坨要自己 parse 的字串。對於後端出身、寫慣型別的人,上手很順。

LangChain 則是另一個極端:生態最大、整合最多,要接什麼幾乎都有現成的。代價是抽象層厚、版本變動快,小專案套上去常常是殺雞用牛刀。我的建議:流程單純、輸出要結構化,先試 Pydantic AI;要串一堆現成整合、團隊已經熟 LangChain,再用它。別因為「大家都用」就無腦選。

檢索層:RAGFlow

Agent 沒接 RAG,就只能靠模型訓練時記下的東西回答,碰到你公司的內部文件、最新的產品規格就會開始唬爛。RAGFlow 處理的是這條鏈裡最被低估的環節:文件切塊、解析、向量化、檢索。它對 PDF、表格、版面複雜的文件處理得比一般 RAG 套件細,這在台灣很多企業滿手 PDF 合約、規格書的場景特別有感。什麼時候需要?只要你的 Agent 要回答「公司內部才知道的事」,就需要。

執行沙箱層:Blaxel

當你的 Agent 開始會「自己寫 code 然後執行」,危險就來了。它可能跑出無窮迴圈、可能讀到不該讀的檔案、可能呼叫到外部網路。Blaxel 這類執行沙箱,是給 Agent 一個隔離的環境去跑這些不可控的動作,跑壞了也炸不到你的主機。如果你的 Agent 只是查資料、呼叫固定 API,可以先不用;一旦它要動態執行程式碼,沙箱就不是選配,是必備。

可觀測性層:AgentOps 與 Langfuse

這是開頭那位朋友最缺的一層。Agent 多步驟跑下來,中間呼叫了什麼、每一步花多少 token、哪一步開始歪掉,沒有工具記錄你根本看不到。AgentOps 專注在 Agent 的執行軌跡——把每一個 step、每一次 tool call 串成一條可回放的時間線,debug 多步驟流程時是救命的。Langfuse 則更偏線上監控與分析,適合把生產環境的每一次對話、每一筆成本長期記下來追蹤。兩者定位略有重疊但側重不同,我會在另一篇講評測與安全的文章裡細談怎麼搭。

評測與安全層:Promptfoo

Agent 最可怕的不是當機,是「安靜地做錯」——它回了一段看起來很有道理、其實是錯的答案,沒有人發現。Promptfoo 讓你把一組測試案例固定下來,每次改了 prompt 或換了模型,就跑一遍,量化看回答品質有沒有退步,順便做紅隊測試挑出會被繞過的漏洞。這層的精神是把「我覺得變好了」變成「數字說它變好了」。想了解完整做法,可以接著看〈AI Agent 上線前,你一定要做的評測與安全把關〉。

部署層:Northflank

最後是把整套東西放上線。Agent 的部署比一般 Web service 麻煩:它要長時間執行、要跑背景任務、有時還要管沙箱容器。Northflank 這類平台幫你處理容器化、擴展、CI/CD,讓你不用自己從零搭 Kubernetes。小團隊用它可以省下一個 DevOps 的人力。

三種團隊,三種打法

台灣個人開發者:別想著六層一次到位。先用 Pydantic AI 把核心流程做出來,接上 Promptfoo 確保不會愈改愈爛,其他層等真的撞牆了再補。一個人能維護的工具數量有限,克制一點。

新創團隊:可觀測性要趁早。我看過太多團隊把 AgentOps、Langfuse 留到「之後再說」,結果出事時整個團隊在 log 海裡撈三天。早點接,等於買保險。部署層直接用 Northflank 這種託管平台,省下的時間拿去打磨產品。

企業:RAG 與安全是重中之重。你的資料敏感、合規要求高,RAGFlow 的私有部署能力、Promptfoo 的紅隊測試、沙箱的隔離,每一項都直接對應到風控部門會問的問題。建議找一個小場景先把六層走通一遍,再橫向複製。

實務做法:從哪一層開始

如果你今天才要動手,我的順序是:框架(Pydantic AI)→ 評測(Promptfoo)→ 可觀測性(AgentOps)→ 視需求補 RAG(RAGFlow)、沙箱(Blaxel)→ 最後部署(Northflank)。

注意這個順序:評測和可觀測性排在 RAG 前面。因為一個沒有評測、看不見內部的 Agent,加再多功能都只是把不可控的東西堆得更高。先讓它「可量、可看」,再讓它「更強」。如果你還沒做過任何 Agent,可以先讀入門的〈如何打造你自己的 AI Agent〉建立基本概念,再回來看這套工具鏈。

TheAI學院 總結與評語

2026 自建 Agent 的競爭,早就不在「誰的模型聰明」,而在「誰的工具鏈完整」。Demo 人人會做,能上線、出事查得到、改版不退步的,才是真本事。

「會做 Agent 的人很多,能讓 Agent 安全上線又維運得住的人很少——後者才是 2026 真正值錢的工程能力。」

給台灣讀者的具體建議:別被工具的數量嚇到,也別貪心一次裝齊。挑一個小到不能再小的任務,把框架、評測、可觀測性這三層先走通——這三層走通,你就已經贏過九成只會做 demo 的人。RAG、沙箱、部署,等你真的撞到那道牆,自然會知道該補哪一層。