我实测了5个开源的分析智能体

说到分析智能体我见过的多数数据团队都想自己搭建而不是购买。他们希望拥有技术栈的完全控制权在自己的基础设施上运行并保持对驱动智能体的上下文的完全掌控。所以真正的问题不是我们应该买哪个智能体而是“我们应该基于哪个开源框架来搭建”为了回答这个问题我挑选了五个覆盖当前实际可用范围的项目LangChain、Wren AI、nao、LibreChat 和 Vercel 的 knowledge-agent-template。从外部看它们似乎可以互换但实际上差别很大。其中三个是你可以真正用来回答数据问题的工具另外两个不是。而在那三个可用的工具中它们之间的差异比任何并列比较所呈现的都要大。所以上周末我决定对每一个进行一次真实测试。同一个 BigQuery 表、同一个模型、同一个问题各运行3次。以下是我的发现。1、五个项目五个不同类别大多数人在这点上会搞错。这5个项目都出现在开源AI智能体列表中但它们根本不是同一种工具。LangChain是一个 LLM 智能体库。它提供构建模块由你来编写智能体。它的上下文取决于你放入提示词中的内容。Wren AI是一个语义上下文引擎。你使用一种叫做 MDL 的特定建模语言来定义表和指标。然后你自带编码智能体Codex、Claude Code、Cursor…来查询它。nao是一个完整的分析智能体。文件系统上下文层、聊天UI、MCP 服务器和 MCP App、评估框架全部内置。LibreChat是一个自托管的 LLM 聊天 UI。开箱即用可以连接 OpenAI、Anthropic 等。没有数据库工具。Vercel 的 knowledge-agent-template是一个用于构建文件系统搜索智能体的 Nuxt 模板。可以在配置的数据源GitHub 仓库、YouTube 字幕、自定义 API上执行grep、find、cat。2、我的评估框架因为这些工具属于不同类别所以对单个问题答案是否正确是不够的。一个需要你自己编写智能体的库从定义上就会在任何一次性准确性测试中失败但这并不意味着它是一个糟糕的库。因此我根据在选择构建分析智能体的框架时真正重要的维度来对每一个进行评分设置时间。从pip install或git clone到可以与数据仓库对话的可用聊天需要多长时间数据仓库连接。内置连接器还是需要你自己接入 BigQuery工具。SQL、schema、图表是否开箱即用还是需要你自己构建上下文层。业务含义存储在哪里在提示词中、建模语言中、markdown 文件中还是根本没有智能体 UI。是否自带聊天界面还是需要你自己构建真实问题的准确性。同一个 BigQuery 表、同一个模型、同一个问题各运行3次。对或错。长期可维护性。添加第25张表是什么样子当你的团队日常使用时如果智能体给出了错误答案分析师该怎么办对于准确性测试我选择了一个问题“上个月的流失率是多少”听起来很简单但实际上并非如此流失率需要一个自连接本月流失的许可证除以上个月的付费许可证而如果让 LLM 自己处理它会使用当前月作为分母最终会偏差几个百分点。数据来自我们的 Stripe MRR 表prod_silver.fct_stripe_mrr。我将每次运行的结果与直接从数据仓库计算的真实数字进行比较这个真实数字我不会分享。对或错才是重要的 3、LangChainLangChain 是一个用于构建 LLM 应用的 Python 库。开箱即用没有智能体。你需要从基本组件中组装一个聊天模型、自定义工具、系统提示词、一个create_agent调用。4、WrenWren 是不同的。它是一个语义上下文引擎而不是一个智能体。4.1 如何设置智能体、工具和数据仓库三行命令即可安装和连接pip install wren-engine[bigquery,main] npx skills add Canner/wren-engine --skill * wren profile add nao-bq --ui最后一行命令会在浏览器中打开一个本地 Web 表单你可以在其中输入你的 BigQuery 项目、数据集和凭证。点击保存后Wren 会将连接配置文件写入磁盘。不需要手写 yaml。mkdir ~/nao-wren cd ~/nao-wren wren context init4.2 智能体 UI没有 UI。你需要打开一个编码智能体Claude Code、Cursor、Codex、Windsurf、Cline你安装了哪个就用哪个。Wren 的 skills 并不是 Claude 专属的它们可以在任何支持 skills 格式的工具中使用。在项目内部你让编码智能体生成语义层Use the wren-generate-mdl skill to explore the prod_silver dataset and generate the MDL for fct_stripe_mrr. The data source is BigQuery.该 skill 会探索你的数据集将 MDL 文件写入models/ModelName/metadata.yml验证它们构建上下文并索引记忆。然后你就可以用自然语言提问了。wren-usageskill 会根据你的模型名称编写 SQL 并通过 Wren 引擎执行。整个设置大约需要20分钟但前提是你已经安装了一个编码智能体。4.3 测试结果然后我在编码智能体界面中直接提问。3次运行全部正确。每次都得到相同的答案通过相同的自连接。效果很好。需要指出的一点Wren 期望你通过编码智能体来驱动它。Skills 负责繁重的工作编写建模文件、查询引擎、处理 SQL 方言的怪癖。如果你跳过编码智能体从自己的 LLM 应用中调用 Wren你就需要重新实现这些工作。4.4 适用场景如果你满足以下两个条件Wren 就适合你。第一你接受上下文存储在专有的建模语言中。MDL 文件是 Wren 特有的它们不是 markdown不是 dbt YAML… 当智能体给出错误答案时修复需要通过语义模型进行。第二你希望编码智能体成为你的主要查询界面。Wren 没有聊天 UI。它被设计为由 Claude Code、Cursor、Codex、Windsurf、Cline 或你的团队已经在使用的任何编码智能体来驱动。如果你的分析师习惯于打开编码智能体并在其中输入自然语言问题体验会很顺畅。5、Naonao 是一个开源分析智能体具有文件系统上下文层、聊天 UI、MCP 服务器 MCP App以及内置的评估框架。5.1 如何设置智能体设置只需要两条命令pip install nao-core nao initnao init是交互式的。它会在终端中引导你完成所有步骤 nao project initialization ? Enter your project name: my-analytics-agent ? Set up database connections? Yes ? Select database type: Bigquery ? Connection name: bigquery-prod ? GCP Project ID: nao-production ? Default dataset (optional): prod_silver ? Authentication method: Service account JSON file path ? Path to service account JSON file: /path/to/bq-key.json ? Set up LLM configuration? Yes ? Select LLM provider: OpenAI ? Enter your OPENAI API key: ******** ✓ Created project my-analytics-agent ✓ Saved my-analytics-agent/nao_config.yaml nao debug - Testing connections... ✓ bigquery-prod (24 tables found) ✓ openai (126 models available)不需要预先编写 yaml。你回答提示nao 会为你编写配置然后立即运行nao debug来验证连接是否正常工作。大约3分钟。5.2 如何设置上下文只需要一条快速命令cd my-analytics-agent nao syncnao sync会从你的数据仓库拉取每一张表并将上下文作为markdown 文件写入你的项目。每张表生成四个文件列信息、预览行、从查询历史生成的使用方法注释、以及统计信息。databases/ typebigquery/ databasenao-production/ schemaprod_silver/ tablefct_stripe_mrr/ columns.md # column list with types preview.md # sample rows how_to_use.md # LLM-generated usage notes profiling.md # null counts, distinct values, top values tablefct_users/ ... ... (24 tables)我有24张表所以它生成了96个 markdown 文件。全部存放在一个 git 仓库中。团队中任何会读英语的人都可以编辑它们。这就是区别所在。上下文以 markdown 文件的形式存在于你的文件系统中。当你问上个月的流失率是多少时智能体会获取相关的columns.md、preview.md和how_to_use.md。它看到的是实际的列描述、示例行和使用说明而不是猜测。最棒的是如果你想让智能体下次更聪明只需打开how_to_use.md添加两句英文。不需要语义层不需要重新索引等等。5.3 智能体 UI只需运行nao chat。这会启动一个运行在5005端口的聊天 UI内置对话历史、图表渲染和 SQL 预览还有一个 MCP 服务器如果你想把智能体接入 Claude Code、Cursor 或 Slack。nao 还自带了skills——可重用的 markdown 流程智能体用它来为新表构建上下文、运行评估、编写 dbt 模型。Skill 格式不是 Claude 专属的它可以在 nao 聊天 UI、MCP 接口或任何编码智能体中使用。5.4 测试结果3次运行全部正确。分母正确上个月的付费许可证而不是当前月的。它还主动提供了许可证流失和 MRR 流失两个数据虽然没有被要求因为两者都是流失率是多少的有用答案。5.5 适用场景如果你想快速上手不需要先构建语义层无论你的技术栈其他部分是什么样的nao 是正确的选择。数据仓库连接、上下文生成和聊天 UI 都从前两条命令开始就全部配置好了。不需要学习建模语言也不需要在提问之前先集成某个平台。上下文以 markdown 的形式存在于你的仓库中所以团队中任何人都可以编辑它。新增表nao sync。新增指标定义打开how_to_use.md写一句话。有新分析师加入团队他们已经懂 markdown 了。上下文工程不再是一个工程项目而变成了团队实践。6、LibreChatLibreChat 之所以出现在这里是因为它代表了很多数据团队最终会考虑的一种真实模式拿一个自托管的聊天 UI通过 MCP 接入数据库工具然后称之为分析智能体。它值得测试因为这种架构听起来很合理。让我们看看实际运行时会发生什么。6.1 如何设置智能体官方路径是 Dockergit clone https://github.com/danny-avila/LibreChat.git cd LibreChat cp .env.example .env # add your OpenAI/Anthropic key docker compose up -d打开localhost:3080注册第一个用户你就有了一个团队专用的私有 ChatGPT。支持多模型OpenAI、Anthropic、Google、对话历史、上传文件的 RAG、智能体分配。开箱即用非常漂亮。6.2 如何设置上下文、工具和数据仓库LibreChat 原生没有数据库工具。你需要通过 MCP 添加。配置文件在librechat.yaml中你将其挂载到容器中mcpServers: bigquery: type: stdio command: npx args: - -y - ergut/mcp-bigquery-server - --project-id - your-gcp-project - --key-file - /app/gcloud-credentials.json重启后BigQuery 工具就会出现在聊天下拉菜单中。6.3 智能体 UI6.4 测试结果我问“上个月的流失率是多少”首先查询失败了。MCP 服务器不知道你的表在prod_silver中它需要我提供完全限定的表路径才能执行任何操作。在我提供了之后它返回了“上个月的流失率是 0.0%。”非常自信。还主动提出可以按客户数流失、MRR 流失、主动流失 vs 被动流失来细分。真实数字不是 0.0%。与 LangChain 相同的失败模式一个轻量级的 SQL 执行器给了模型运行查询的方式但没有任何关于数据含义的上下文。没有 schema 感知没有自连接提示。它猜测了猜错了。然后我换上了 nao 的 MCP在librechat.yaml中只需两行配置nao 已经连接了我们的 BigQuery 并同步了完整的上下文mcpServers: nao: type: streamable-http url: https://your-nao-instance/mcp headers: Authorization: Bearer your-nao-token我问了同样的问题。第一次就得到了正确答案。但这就是关键LibreChat 是聊天客户端。MCP 服务器才是智能体。做分析工作的是 nao而不是 LibreChat。答案的质量完全取决于你接入了哪个 MCP。6.5 适用场景如果你想要一个为团队定制的自托管 ChatGPT需要认证、多模型和对话历史并且你准备好选择合适的 MCP 服务器来支撑它那么 LibreChat 是正确的选择。UI 确实做得很好。只是不要以为接入一个 SQL MCP 就给了你一个分析智能体。它给你的是一个带 SQL 工具的聊天 UI。这是否足够完全取决于 MCP 背后是什么。7、Vercel knowledge-agent-templateVercel knowledge-agent-template是我最好奇的一个因为它的 README 听起来很棒“开源的文件系统和基于知识的智能体模板。可以在你的数据源中进行 grep、find 和 cat 操作。”7.1 如何设置智能体git clone https://github.com/vercel-labs/knowledge-agent-template.git cd knowledge-agent-template cp apps/app/.env.example apps/app/.env # set BETTER_AUTH_SECRET GitHub OAuth bun install bun run dev打开localhost:3000注册你就有一个聊天应用了。到目前为止一切顺利。7.2 工具箱里到底有什么我去找了 SQL 工具。以下是智能体工具包中实际包含的内容packages/sdk/src/tools/ shell.ts # createBashTool, createBashBatchTool packages/agent/src/tools/ web-search.ts web-search.perplexity.ts就这些。没有数据库连接器。没有 SQL 工具。没有任何方式可以将这个东西指向 BigQuery 并让它执行查询。README 中的grep, find, cat指的是智能体对配置的知识源使用的运行时沙箱工具GitHub 仓库、YouTube 字幕、缓存为文件的自定义 API 输出。要真正将其用于智能体分析你需要编写自定义数据源连接器或基于 SDK 编写自定义工具。这是真正的工程工作最终你在文件系统智能体模板上构建了一个分析智能体。7.3 测试结果我还是用默认数据源问了这个问题。回复是一个礼貌版本的*“我没有访问你的 BigQuery 的权限。我可以搜索配置的知识源GitHub 仓库、文档等。”*至少这是一个诚实的回答。7.4 能否连接 MCP 服务器来让它工作理论上可以。Vercel AI SDK v6 提供了experimental_createMCPClient。但这个模板没有任何 MCP 接入没有客户端实例化没有工具注册base.ts或其他任何地方都没有。你需要自己添加。这是需要编写的真实代码而且你是在将分析能力嫁接到一个并非为此构建的文件系统搜索模板上。7.5 适用场景这是一个完美设计的文件系统搜索智能体。如果你想要一个覆盖你的代码库、markdown 文件知识库或 YouTube 字幕的智能体它正是你想要的。它只是不是数据仓库智能体。对于智能体分析来说它是错误的类别你可以从包中任何地方都没有 SQL 工具、也没有 MCP 客户端这一点看出来。7.6 如何设置智能体、工具和数据仓库官方 SQL 快速入门会引导你完成。两个安装步骤pip install langchain langgraph pip install -U langchain[openai]然后在 Python 中你初始化聊天模型用tool装饰器定义你的工具一个用于列出表、一个用于获取 schema、一个用于执行查询、一个用于检查 SQL编写系统提示词然后将它们组合在一起from langchain.chat_models import init_chat_model from langchain.tools import tool from langchain.agents import create_agent model init_chat_model(gpt-4o) tool def sql_db_query(query: str) - str: Execute a SQL query. # ... your BigQuery client logic # ... three more tools: list_tables, schema, query_checker agent create_agent(model, tools, system_prompt...)如果你以前做过大约需要30分钟。而且你还需要额外的一步来接入 BigQuery因为没有内置连接器。7.7 如何设置上下文没有上下文层。智能体每次都通过INFORMATION_SCHEMA实时内省 schemaLLM 必须自己弄清楚语义。想让它知道上个月是什么意思把它塞进系统提示词。自连接也一样分析师可能问到的每个领域概念也一样。7.8 智能体 UI也没有聊天 UI。你需要自己 vibe-code 一个前端、Slack 集成、认证、历史记录。全部是自定义工作你决定做什么。以下是我一分钟生成的简单版本。7.9 测试结果3次运行中有1次完成。完成的那次返回了错误数字它使用MAX(month)来找上个月落在了一个未来数据行上并且完全跳过了自连接。另外两次达到了智能体递归限制因为一直在重新验证格式错误的 SQL。LangChain SQL 智能体并没有坏。它正在做库所承诺的事情把 schema 交给 LLM 让它自己弄明白。问题在于没有上下文的 LLM 不知道你的业务实际意味着什么。而 LangChain 原生不提供任何上下文。7.10 适用场景LangChain 绝对可以工作很多团队已经在它上面构建了出色的分析智能体。问题是你必须自己补齐缺失的部分一个真正的上下文层一个精心策划的 markdown 文件夹、一个提示词库、一个自定义检索系统或者在底层接入像 Wren AI 这样的语义层。所以如果你是一个正在构建产品的开发者对自己掌控上下文、评估和 UI 感到自在LangChain 是一个强大的基础。如果你是一个只想可靠回答问题的数据团队你会希望在上手之前这些层就已经配置好了。8、对比总结以下是它们在真正重要的维度上的表现。9、你的上下文存储在哪里这才是真正的问题。我最初测试时的简单问题是数据团队应该基于哪个开源框架来搭建测试进行到一半时我意识到这仍然是错误的框架。五个中有两个LibreChat 和 Vercel 模板根本不是分析工具。它们出现在同一个列表中是因为它们都是描述中带有AI智能体的开源项目。它们中没有一个是一样的工具。剩下的三个可以真正回答数据问题的LangChain、Wren AI 和 nao。它们之间真正的区别不在于功能或准确性。而在于它们在哪里存储使智能体有用的上下文。LangChain赌注在于上下文存储在提示词中。你为每个问题、每个应用构建它。框架给你循环。Wren AI赌注在于上下文存储在语义模型中。你用 MDL 定义你的业务含义编码智能体据此查询。nao赌注在于上下文存储在文件系统中。Git 仓库中的 markdown 文件。人类可编辑LLM 可读取可以与你已经维护的所有内容dbt 文档、业务词汇表、规则文件组合使用。这些赌注对于谁能编辑上下文、如何进行版本控制、以及分析师是否可以在不通过工程师的情况下修复错误答案有着完全不同的影响。我们在 nao 的赌注是文件系统形式会胜出。这是 AI 编码智能体Claude Code、Cursor理解代码库已经使用的同一种形式读取文件。nao 将同样的形式应用于数据上下文。原文链接我实测了5个开源的分析智能体 - 汇智网