自建 AI Agent 一定要六层工具全用吗?

不用。最低限度是框架层(例如 Pydantic AI)加上评测(Promptfoo)与可观测性(AgentOps),确保它可量化、看得见。RAG、沙箱、部署等到真的有需求再补上,避免一开始就背太多工具。

Pydantic AI 和 LangChain 该选哪个?

流程单纯、输出要结构化、团队习惯写型别,优先试 Pydantic AI,它把输出用 schema 绑死较好维护。要串大量现成整合或团队已熟 LangChain,再用 LangChain,但要承担它抽象层厚、版本变动快的成本。

什么情况下 Agent 才需要执行沙箱?

当 Agent 会「自己产生程式码并执行」或执行不可控的系统指令时,就需要 Blaxel 这类沙箱做隔离。如果它只是查资料、呼叫固定 API,风险较低,可以先不用。

可观测性工具值得在专案早期就导入吗?

值得。多步骤 Agent 出错时,没有 AgentOps、Langfuse 这类工具记录执行轨迹,你很难知道是哪一步出问题。早点接等于买保险,事后补通常代价更大。

想自己做一个 AI Agent,该准备哪些工具? 开发者工具链全图解

Demo 跑得漂亮、上线就翻车,问题九成出在工具链缺了一层。这篇把 2026 自建 AI Agent 的开发堆叠拆成六层:框架、RAG、沙箱、可观测性、评测、部署,逐层说明各自解决什么问题、什么时候才需要它。

周五下午,一位朋友传来他的 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、沙箱、部署,等你真的撞到那道墙,自然会知道该补哪一层。