> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 我实测了5个开源的分析智能体
- URL: https://www.hubwiz.com/blog/i-battletested-5-open-source-analytics-agents/
- Published: 2026-05-29T15:25:22.000Z
- Updated: 2026-10-13T15:35:18.000Z
- Description: LangChain、Wren AI、nao、LibreChat 和 Vercel 的 knowledge agent。在同一个 BigQuery 表、同一个模型、同一个查询上进行测试。
- Author: admin
- Tags: AGENT, #Import 2026-10-14 14:41

说到分析智能体，我见过的多数数据团队都想自己搭建，而不是购买。

他们希望拥有技术栈的完全控制权，在自己的基础设施上运行，并保持对驱动智能体的上下文的完全掌控。所以真正的问题不是"我们应该买哪个智能体？"，而是 **"我们应该基于哪个开源框架来搭建？"**

为了回答这个问题，我挑选了五个覆盖当前实际可用范围的项目：**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、LangChain

[LangChain](https://docs.langchain.com/oss/python/langchain/?ref=hubwiz.com) 是一个用于构建 LLM 应用的 Python 库。开箱即用没有智能体。你需要从基本组件中组装一个：聊天模型、自定义工具、系统提示词、一个 `create_agent` 调用。

## 4、Wren

[Wren ](https://github.com/Canner/wren-engine?ref=hubwiz.com)是不同的。它是一个语义上下文引擎，而不是一个智能体。

### 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 init

```

### 4.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-usage` skill 会根据你的模型名称编写 SQL 并通过 Wren 引擎执行。

整个设置大约需要20分钟，但前提是你已经安装了一个编码智能体。

![Wren AI](https://www.hubwiz.com/blog/content/images/2026/05/https-3A-2F-2Fsubstack-post-media.s3.amazonaws.com-2Fpublic-2Fimages-2F76292ee6-13e4-468d-8155-ae6f055daf2d_2908x1514.png)

### 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、Nao

[nao](https://getnao.io/?ref=hubwiz.com) 是一个[开源分析智能体](https://github.com/getnao/nao?ref=hubwiz.com)，具有文件系统上下文层、聊天 UI、MCP 服务器 + MCP App，以及内置的评估框架。

### 5.1 如何设置智能体

[设置](https://docs.getnao.io/nao-agent/quickstart?ref=hubwiz.com)只需要两条命令：

```
pip install nao-core
nao init

```

`nao 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 sync

```

`nao sync` 会从你的数据仓库拉取每一张表，并将上下文作为 **markdown 文件**写入你的项目。每张表生成四个文件：列信息、预览行、从查询历史生成的"使用方法"注释、以及统计信息。

```
databases/
  type=bigquery/
    database=nao-production/
      schema=prod_silver/
        table=fct_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
        table=fct_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 预览：

![nao chat UI](https://www.hubwiz.com/blog/content/images/2026/05/https-3A-2F-2Fsubstack-post-media.s3.amazonaws.com-2Fpublic-2Fimages-2Fafd8773f-aa96-43e3-964c-e349fee6badc_2892x1656.png)

还有一个 [MCP 服务器](https://docs.getnao.io/nao-agent/connectors/mcp?ref=hubwiz.com)，如果你想把智能体接入 Claude Code、Cursor 或 Slack。nao 还自带了[skills](https://docs.getnao.io/nao-agent/context-engineering/skills?ref=hubwiz.com)——可重用的 markdown 流程，智能体用它来为新表构建上下文、运行评估、编写 dbt 模型。Skill 格式不是 Claude 专属的；它可以在 nao 聊天 UI、MCP 接口或任何编码智能体中使用。

### 5.4 测试结果

3次运行全部正确。分母正确（上个月的付费许可证，而不是当前月的）。它还主动提供了许可证流失和 MRR 流失两个数据，虽然没有被要求，因为两者都是"流失率是多少"的有用答案。

### 5.5 适用场景

如果你想快速上手，不需要先构建语义层，无论你的技术栈其他部分是什么样的，nao 是正确的选择。数据仓库连接、上下文生成和聊天 UI 都从前两条命令开始就全部配置好了。不需要学习建模语言，也不需要在提问之前先集成某个平台。

上下文以 markdown 的形式存在于你的仓库中，所以团队中任何人都可以编辑它。新增表？`nao sync`。新增指标定义？打开 `how_to_use.md` 写一句话。有新分析师加入团队？他们已经懂 markdown 了。上下文工程不再是一个工程项目，而变成了团队实践。

## **6、LibreChat**

[LibreChat ](https://www.librechat.ai/?ref=hubwiz.com)之所以出现在这里，是因为它代表了很多数据团队最终会考虑的一种真实模式：拿一个自托管的聊天 UI，通过 MCP 接入数据库工具，然后称之为分析智能体。它值得测试，因为这种架构听起来很合理。让我们看看实际运行时会发生什么。

### 6.1 如何设置智能体

官方路径是 Docker：

```
git 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 智能体 UI

![LibreChat UI](https://www.hubwiz.com/blog/content/images/2026/05/https-3A-2F-2Fsubstack-post-media.s3.amazonaws.com-2Fpublic-2Fimages-2F322b96c2-0d28-455b-b10c-d8ec0487d9e5_2902x1732.png)

### 6.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-template**

[Vercel knowledge-agent-template](https://github.com/vercel-labs/knowledge-agent-template?ref=hubwiz.com)是我最好奇的一个，因为它的 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 快速入门](https://docs.langchain.com/oss/python/langchain/sql-agent?ref=hubwiz.com)会引导你完成。两个安装步骤：

```
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` 实时内省 schema，LLM 必须自己弄清楚语义。想让它知道"上个月"是什么意思？[把它塞进系统提示词](http://blog/context-impact-analytics-agent?ref=hubwiz.com)。自连接也一样，分析师可能问到的每个领域概念也一样。

### 7.8 智能体 UI

也没有聊天 UI。你需要自己 vibe-code 一个：前端、Slack 集成、认证、历史记录。全部是自定义工作，你决定做什么。

以下是我一分钟生成的简单版本。

![LangChain UI](https://www.hubwiz.com/blog/content/images/2026/05/https-3A-2F-2Fsubstack-post-media.s3.amazonaws.com-2Fpublic-2Fimages-2Fb54f5ebe-6e37-4659-9382-d79993091885_2906x1736.png)

### 7.9 测试结果

3次运行中有1次完成。完成的那次返回了错误数字，它使用 `MAX(month)` 来找"上个月"，落在了一个未来数据行上，并且完全跳过了自连接。另外两次达到了智能体递归限制，因为一直在重新验证格式错误的 SQL。

LangChain SQL 智能体并没有坏。它正在做库所承诺的事情：把 schema 交给 LLM 让它自己弄明白。问题在于，没有上下文的 LLM 不知道你的业务实际意味着什么。而 LangChain 原生不提供任何上下文。

### 7.10 适用场景

LangChain 绝对可以工作，很多团队已经在它上面构建了出色的分析智能体。问题是你必须自己补齐缺失的部分：一个真正的上下文层（一个精心策划的 markdown 文件夹、一个提示词库、一个自定义检索系统），或者在底层接入像 Wren AI 这样的语义层。

所以如果你是一个正在构建产品的开发者，对自己掌控上下文、评估和 UI 感到自在，LangChain 是一个强大的基础。如果你是一个只想可靠回答问题的数据团队，你会希望在上手之前这些层就已经配置好了。

## 8、对比总结

以下是它们在真正重要的维度上的表现。

![对比表](https://www.hubwiz.com/blog/content/images/2026/05/https-3A-2F-2Fsubstack-post-media.s3.amazonaws.com-2Fpublic-2Fimages-2F06b6dad0-9be7-40de-8295-be0a68c6daf8_1708x790.png)

## **9、你的上下文存储在哪里？这才是真正的问题。**

我最初测试时的简单问题是：数据团队应该基于哪个开源框架来搭建？

测试进行到一半时，我意识到这仍然是错误的框架。五个中有两个（LibreChat 和 Vercel 模板）根本不是分析工具。它们出现在同一个列表中是因为它们都是描述中带有"AI智能体"的开源项目。它们中没有一个是一样的工具。

剩下的三个可以真正回答数据问题的：LangChain、Wren AI 和 nao。它们之间真正的区别不在于功能或准确性。而在于它们在哪里存储使智能体有用的上下文。

- **LangChain** 赌注在于上下文存储**在提示词中**。你为每个问题、每个应用构建它。框架给你循环。
- **Wren AI** 赌注在于上下文存储**在语义模型中**。你用 MDL 定义你的业务含义，编码智能体据此查询。
- **nao** 赌注在于上下文存储**在文件系统中**。Git 仓库中的 markdown 文件。人类可编辑，LLM 可读取，可以与你已经维护的所有内容（dbt 文档、业务词汇表、规则文件）组合使用。

这些赌注对于谁能编辑上下文、如何进行版本控制、以及分析师是否可以在不通过工程师的情况下修复错误答案，有着完全不同的影响。

我们在 nao 的赌注是文件系统形式会胜出。这是 AI 编码智能体（Claude Code、Cursor）理解代码库已经使用的同一种形式：读取文件。nao 将同样的形式应用于数据上下文。

---

原文链接: [I battletested 5 open source analytics agents](https://thenewaiorder.substack.com/p/i-battletested-5-open-source-analytics)

汇智网翻译整理，转载请标明出处

> **这是「Agent / MCP」专题的一部分。**完整地图见：[Agent / MCP / 自动化完全指南](https://www.hubwiz.com/blog/agent-stack/)