Wren AI 开源版与商业版：Open Core 边界、功能对比与选型指南

Wren AI 开源版与商业版：Open Core 边界、功能对比与选型指南

【免费下载链接】WrenAIGenBI (Generative BI) for AI agents, an open-source, governed text-to-SQL through an open context layer that turns natural-language questions into trusted dashboards, charts, and SQL across 20+ data sources, such as BigQuery, Snowflake, PostgreSQL, ClickHouse, Amazon Redshift, Databricks and more.项目地址: https://gitcode.com/GitHub_Trending/wr/WrenAI

导读

本文基于 Wren AI 开源仓库的官方概念文档（docs/core/concepts/oss_vs_commercial.md），系统拆解Wren AI 开源版（Open Source）与商业版（Commercial / Wren AI Cloud 与自托管 Enterprise Plus）之间的能力边界、适用场景与选型逻辑。你将掌握：Wren AI 的 Open Core 模式如何在"引擎开源"与"团队层商业"之间划分界限；MDL 语义层、RLAC/CLAC 治理、CLI/SDK、MCP 服务器等能力分别落在开源还是商业一侧；以及一个人、一支数据团队、面向客户嵌入分析三类场景下该如何决策。文末还以仓库源码为据，说明开源引擎的实际落地形态与治理机制的实现深度。

说明：本文中"开源版"指本仓库中可自托管、Apache-2.0 许可的引擎与工具链；"商业版"指 Wren AI Cloud 托管服务与自托管 Enterprise Plus 部署。两版共享同一套引擎内核与 MDL 上下文，能力边界以仓库文档公开描述为准。

一句话理解：开源是完整引擎，商业是在其上叠加的"团队层"

Wren AI 开源版与商业版的关系可以用一句话概括（原文档原话）：

Wren AI open source is the full engine—— 免费、可自托管，由一名工程师或一个 AI Agent 通过 CLI 和 SDK 驱动。

Wren AI Commercial is the same engine built for a team—— 以托管云服务或自托管企业部署的形式运行，额外提供 Web UI、账户体系、托管式访问控制、集成与技术支持。

关键在于"同一台引擎"：商业版并不是另一套产品，而是同一引擎叠加了面向组织协作的层。这一点在仓库根 README.md 的 "Open core: OSS vs. Cloud / self-hosted" 一节中得到印证——开源的是"context engine"（MDL 语义层、受治理的 text-to-SQL、MCP 服务器、CLI 与 22+ 连接器），商业的是"在其之上"的团队与治理能力。

从仓库结构看，这个"开源内核"是真实可运行的实体：core/wren/（Python SDK 与 CLI，PyPI 包名wrenai）、core/wren-core/（基于 Apache DataFusion 的 Rust 语义引擎）、core/wren-core-py/（Python 绑定）、core/wren-core-wasm/（浏览器端 Wasm 构建）共同构成引擎主体，sdk/wren-langchain/与sdk/wren-pydantic/提供 Agent 框架集成。也就是说，开源版已经具备完整的 text-to-SQL → 图表 → 部署仪表盘（GenBI）闭环，商业版的价值在于多人与治理。

三种场景，快速定位你该选哪一边

原文档给出了三个典型选型场景，直接对应三种完全不同的使用方式：

场景一：单人 + 终端（选开源版）

Solo, in the terminal.One engineer or an AI agent, working through the CLI, SDK, and Git. Open source is all you need.

一名工程师（或一个 AI Agent）通过CLI、SDK 和 Git完成全部工作。这是开源版的典型战场：安装wrenaiCLI、运行wren context init搭建 MDL 项目、用wren query执行受治理的查询、通过wren ask包装问题、用wren skills get genbi生成并部署仪表盘。整个过程在终端和 Git 仓库内闭环，不需要任何 Web UI。

场景二：数据团队（商业版开始体现价值）

A data team.Several people need governed access with roles and SSO, and non-technical teammates want to ask questions in a browser, Slack, or Teams. This is where Commercial earns its place.

多个人需要角色与 SSO 支撑的治理式访问，非技术同事想在浏览器、Slack 或 Teams里直接提问——这正是商业版"团队层"的主场。开源版没有多用户体系，无法回答"谁被允许看哪些数据"这类组织级问题。

场景三：把分析嵌入你的产品（商业企业版）

Analytics for your customers.You put analytics inside your own product, and each customer must see only their own data. Commercial enterprise gives you per-user RLS/CLS and multi-tenant isolation.

你把自己的产品里嵌入分析能力，每个客户只能看到自己的数据。商业企业版提供按用户的 RLS（行级安全）/ CLS（列级安全）与多租户隔离。注意：开源版 MDL 中也可以定义访问控制（RLAC/CLAC，见下文），但其目标场景是数据源级别的治理；按真实用户身份进行逐行、逐列过滤并配合会话属性与审计日志，是商业版能力。

完整功能对比表（开源 vs 商业）

原文档的功能对比表是选型的核心依据，完整继承如下：

几个要点值得展开：

• CLI/SDK 与 GenBI dashboards 两侧都有：这是"开源是完整引擎"的最直接证据。Agent 驱动的仪表盘生成与部署（GenBI）在开源侧完全可用。
• MCP server 在开源侧标记为 ❌，但仓库中存在mcp_server.py：需要区分两种形态。仓库 core/wren/src/wren/mcp_server.py 是一个 FastMCP 服务器，暴露run_sql、dry_run、query_cube等查询与上下文工具——这是本地/自托管场景下给 Agent 用的 MCP 端点；而对比表中的 ❌ 指的是商业版提供的托管式 MCP server 与托管 REST API（即"我们帮你运行"的服务形态）。开源侧可以通过本地运行获得等效能力，但"完全托管"在商业侧。
• RLAC/CLAC 是两侧共享的治理基础：访问控制规则定义在 MDL 中，开源与商业都支持；商业版在其上增加的是按用户、按会话属性、带审计日志的执行层。下文结合源码说明这一点。
• Evaluation / AI Advisor / feedback tracing 仅商业：准确率追踪、AI 顾问与反馈链路属于商业运营层，开源侧依靠 Git 审阅与 CLI 工作流实现可审查性。

商业版具体"加了什么"：五个要点

原文档 "What Commercial adds" 部分给出了商业版的核心增量，完整继承并注释如下：

1. 自己运行（Runs itself）：托管云或自托管企业部署，无需任何人运维这套技术栈。
2. 为人而生，不只是为 Agent（Built for people, not just agents）：Web UI 加上 Slack、Teams 入口，非技术同事可以直接提问。
3. 真实的身份与访问（Real identity and access）：账户、角色、SSO、LDAP、SCIM 供应，访问控制与真实用户绑定——这是开源版 CLI 模式没有的组织能力。
4. 更多接入方式（More ways in）：托管 API 与 MCP 服务器、可自动刷新的仪表盘。
5. 信心（Confidence）：准确率追踪、反馈溯源，以及出问题时可以呼叫的团队（技术支持/SLA）。
6. 无需重建（No rebuild）：你的 MDL 与上下文原样迁移，无需改动——这是两版"同一引擎"最实际的收益：从开源起步，数据定义资产（models/、views/、cubes/、instructions.md、queries.yml、memory）天然可携带到商业版。

其中第 6 点值得强调：MDL 是 Git 友好的版本化定义（见 README.md），商业版与开源版共享同一份 MDL，因此开源项目升级到商业版是"叠加团队层"而非"迁移数据"。

源码佐证：开源引擎里的治理能力（RLAC/CLAC）是怎么实现的

对比表显示"Access control defined in MDL (RLAC/CLAC)"两侧均为 ✅。开源仓库中这部分有完整的源码实现，值得作为开源版"治理能力真实存在"的纵深证据：

• MDL 模式定义：core/wren-mdl/mdl.schema.json定义了columnLevelAccessControl（列级，第 40 行）与rowLevelAccessControls（行级，第 393 行）等访问控制字段，说明访问控制规则确实内建在 MDL 数据模型中，而非商业版的私有扩展。
• Rust 引擎实现：core/wren-core/core/src/logical_plan/analyze/access_control.rs是行级/列级访问控制的执行核心。其中：
  • collect_condition（access_control.rs#L55-L82）解析 RLAC 条件表达式，收集顶层裸列引用（视为外层模型的列）与会话属性（@name形式，可出现在子查询内）；
  • validate_rlac_rule（access_control.rs#L139）校验规则语法与引用的会话属性是否已定义；
  • build_filter_expression（access_control.rs#L175）把规则编译为实际过滤表达式注入查询计划；
  • RlacContextProvider（access_control.rs#L295）提供解析 RLAC 条件所需的上下文（模型表、表达式规划器等），并显式拒绝文件型表函数与表函数——RLAC 条件中不允许读取文件。
• Python 侧治理校验：core/wren/src/wren/policy.py提供 SQL 策略校验：只读语句（仅接受 SELECT 族）始终开启；严格模式（Strict mode）可验证解析后的 SQL AST 只引用 MDL manifest 中定义的表、并禁用被拒绝的函数，同时以黑名单方式拦截read_csv、read_parquet、glob、iceberg_scan等数据/文件读取器，防止路径遍历、SSRF 与外联（policy.py 注释中明确这些读取器会"defeats strict-mode governance (RLAC/CLAC)"）。

从源码结构可以推断：开源引擎已经具备在 MDL 中声明行级/列级访问控制规则、并在查询规划期强制实施的完整机制；商业版在其上增加的是与真实用户身份、会话属性、审计日志绑定的组织级执行与多租户隔离。这与对比表"开源 ✅ 规则定义、商业 ✅ + 按用户 RLS/CLS"的划分完全吻合。

开源侧的真实工作流：CLI、SDK 与 Agent

为了让"开源是完整引擎"落到实处，这里给出仓库 README 与core/wren/README.md中记载的开源侧核心工作流，供单人/Agent 场景直接上手：

pip install wrenai # 核心（内置 DuckDB） pip install 'wrenai[postgres,memory]' # 按需追加数据源与 memory 扩展

npx skills add Canner/WrenAI # 为 Claude Code、Cursor、Cline、Codex 等 Agent 安装发现桩

之后在项目目录对 Agent 说一句 "Use Wren to set up my Postgres database."，Agent 就会依次执行wren skills get onboarding、创建连接 profile、搭建 MDL 项目并跑通首个查询。日常使用命令（README.md）：

wren skills get onboarding # 工作流指南：搭建项目 + 首个查询（Generate） wren skills get enrich-context # 工作流指南：补充业务上下文（Know） wren skills get genbi # 工作流指南：构建并部署仪表盘（Deploy） wren query --sql '...' # 经由 MDL 语义层执行查询 wren ask "<question>" --guided # 为较弱的 Agent 包装问题 wren ask "<question>" --direct # 为较强的 Agent 包装问题

项目初始化（core/wren/README.md）：

wren context init # 生成 wren_project.yml、models/、views/ wren profile add my-db --ui # 浏览器表单配置连接（需 wrenai[ui]） wren context build # 将 YAML 编译为 target/mdl.json

这套流程覆盖"连接数据源 → 建立语义层 → 受治理查询 → 生成并部署仪表盘（GenBI，可部署到自己的 Vercel / Cloudflare Pages 账户，见 docs/core/guides/genbi.md）"的完整闭环——再次印证开源版并非"阉割版"，而是完整引擎的终端/Agent 形态。

结论与决策框架

回到原文档的最终立场——"Open source stays first-class either way"（无论选哪边，开源都是头等公民）：

• 选开源版：单人开发者或 AI Agent、工作在 CLI/SDK/Git 中、数据治理通过 MDL（RLAC/CLAC）与代码审阅完成、不需要多用户界面。
• 选商业版：多角色数据团队、需要 SSO/LDAP/SCIM 与账户体系、非技术同事要在浏览器/Slack/Teams 提问、需要托管 API/MCP、按用户的 RLS/CLS、多租户隔离、审计日志与厂商支持。
• 两者共用：同一引擎内核、同一 MDL 上下文资产，从开源平滑升级到商业版不需要重建任何语义模型——先用开源把引擎跑起来，团队规模与治理需求上来后再叠加商业"团队层"，是文档暗示的最稳妥路径。

延伸阅读（仓库内）

• README.md —— 根文档，含 Open Core 边界说明（"Open core: OSS vs. Cloud / self-hosted" 一节）与快速上手
• docs/core/concepts/oss_vs_commercial.md —— 本文依据的原文档
• docs/core/guides/genbi.md —— GenBI 仪表盘生成与部署指南
• core/wren/README.md ——wrenaiCLI 与 Python SDK 说明
• core/wren-mdl/mdl.schema.json —— MDL 数据模型（含行级/列级访问控制字段）
• core/wren-core/core/src/logical_plan/analyze/access_control.rs —— RLAC/CLAC 的 Rust 引擎实现
• core/wren/src/wren/policy.py —— SQL 只读校验与严格模式实现

【免费下载链接】WrenAIGenBI (Generative BI) for AI agents, an open-source, governed text-to-SQL through an open context layer that turns natural-language questions into trusted dashboards, charts, and SQL across 20+ data sources, such as BigQuery, Snowflake, PostgreSQL, ClickHouse, Amazon Redshift, Databricks and more.项目地址: https://gitcode.com/GitHub_Trending/wr/WrenAI