nao
getnao/nao加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
2024 年某天凌晨 2 点，某公司数据团队的负责人被一条钉钉消息吵醒——业务部门的同事又发来了一个 Excel 截图，问为什么"DAU 数字和上周对不上"。这不是他们第一次被这种问题打断。实际上，每天有将近 40% 的数据团队时间被消耗在回答重复的"查数"请求上：什么指标？怎么定义？哪个时间段？哪个数据源？
传统的解决方案有两难：要么给业务开 BI 工具（成本高、学习曲线陡峭），要么让数据团队充当"人肉 API"（效率低、响应慢）。有没有一种方式，能让业务用户直接用自然语言提问，同时保证答案的准确性？
nao 正是为了解决这个痛点而诞生的。它是 2025 年 12 月底才开源的分析型 AI Agent 框架，核心理念是：让任何人都能用自然语言与你的数据仓库对话，而数据团队可以完全掌控答案的质量和准确性。
nao 由 nao Labs 主导开发，项目仓库于 2025 年 12 月 30 日上线 GitHub。尽管开源时间很短，但凭借精准的定位和完整的实现，迅速获得了 1273 颗 Star 和 173 个 Fork，目前有 104 个 open issue，说明社区活跃度相当高。
从项目topics 可以看出它覆盖的范围：agentic-analytics、analytics-engineering、bigquery、business-intelligence、chat-with-your-data 等，几乎涵盖了现代数据栈的各个关键环节。项目自称 "#1 Open-Source Analytics Agent"，口气不小，但从功能完整度来看，这个定位并不夸张。
nao 的技术栈采用了 Bun Monorepo 结构，整个项目分为三个核心模块：
第一层：nao-core（Python CLI）
这是数据工程师使用的工具包。通过 pip 安装 nao-core 后，可以用一系列命令行操作来构建和管理分析 Agent 的"上下文"（context）。核心流程是：nao init 初始化项目 → nao sy 同步上下文 → nao debug 验证配置。上下文本质上是一个文件系统结构的项目，包含数据源配置、元数据、业务规则（RULES.md）和工具定义。
nao-core 的依赖非常丰富：Ibis Framework（统一多数据源查询，支持 Postgres/BigQuery/Snowflake/DuckDB 等十余种后端）、FastAPI（提供 Python sidecar 服务）、Pydantic（数据验证）、SQLGlot（SQL 解析）。这种设计让 CLI 具备了对接任意数据仓库的能力。
第二层：@nao/backend（TypeScript/Bun + Fastify + tRPC） 这是整个系统的 API 层，基于 Fastify 构建，并通过 tRPC 提供类型安全的 API。Backend 负责处理用户请求、管理会话历史、与 LLM API 通信、执行查询并返回结果。数据库使用 PostgreSQL 16 存储聊天历史。
第三层：@nao/frontend（React + Vite） Web 聊天界面，用户在这里用自然语言提问、查看可视化图表、提交反馈。界面支持 Markdown 渲染和图表展示。
nao 最有特色的设计是上下文工程（Context Engineering）。不同于普通的 Text-to-SQL 工具，nao 强调"上下文"的概念：数据工程师需要在 nao init 创建的项目中，手动维护一套结构化的知识体系——数据模型定义、关键指标的业务口径、日期过滤规则、分析流程规范。这些内容以 Markdown 文件的形式存在项目中，nao 会把这些上下文信息注入给 LLM，大幅提升回答准确性。
上下文测试框架是另一个亮点。nao debug 命令可以模拟 Agent 的推理过程，让数据工程师在上线前就能发现 Agent 的错误。通过持续运行测试集，还可以追踪 Agent 质量随时间的变化——这是一个被很多同类工具忽视的需求。
Skills 系统是 nao 提供的插件化扩展能力。当前官方发布了 6 个技能：setup-context（初始化配置）、write-context-rules（生成业务规则文档）、create-context-tests（创建测试用例）、deploy-context（部署上线）、audit-context（审计上下文质量）、add-semantic-layer（添加语义层）。这些技能以标准 SKILL.md 格式编写，兼容 Claude Code、Codex、Claude Agent SDK 等主流 Agent 开发框架。
nao 提供了完整的 Docker Compose 部署方案。docker-compose.yml 包含 PostgreSQL 和应用容器两个服务，理论上 docker compose up -d 就能启动。但实际使用还需要配置：
OPENAI_API_KEY 或 ANTHROPIC_API_KEY（两者至少有一个）默认配置下，nao 会加载内置的示例数据，适合快速体验。如果要连接真实数据仓库，需要通过 nao-core CLI 重新初始化项目并配置数据库连接。
支持的数据库：PostgreSQL、BigQuery、Snowflake、DuckDB、ClickHouse、Databricks、MySQL、MS SQL、Athena、Trino、Redshift……基本上覆盖了所有主流数仓和数据库。这得益于 Ibis Framework 的抽象能力——nao 本身不直接写 SQL，而是通过 Ibis 生成目标数据源的方言。
数据工程师路径：需要安装 Python 3.10+、熟悉自己的数据仓库结构。通过 pip install nao-core 和 nao init 即可开始配置。这条路有一定学习成本，但回报是能够完全掌控 Agent 的质量。
业务用户路径：直接使用已部署好的 Web UI，不需要任何技术背景。但前提是数据团队已经完成了上下文配置——这部分工作对普通用户是不可见的。
nao 并非完美。它的局限性主要体现在：
1. LLM 依赖不可避免：无论选择 GPT-4o 还是 Claude-3.5，API 费用是持续成本。开源不等于免费，数据量大时成本不可忽视。
2. 上下文维护成本：上下文的质量直接决定答案质量，但这需要数据工程师持续投入。对于团队规模小、数据资产复杂的公司，这个维护成本可能成为瓶颈。
3. 安全边界：nao 生成的 SQL 是直接执行的，没有额外的查询白名单或权限隔离。如果数据库用户权限过大，可能存在数据泄露风险。
4. 复杂的跨表关联场景：对于需要多表 JOIN、窗口函数的复杂分析，即使提供了详细的上下文，LLM 的推理准确性仍然不稳定。
nao 代表的趋势是数据分析民主化的进一步深化。从 BI 工具到 Text-to-SQL，再到 Context-Aware Agent，这个演进路径正在逐渐打通"业务提问→系统理解→准确回答"的完整链路。
nao 的开源意义在于：它让每个公司都能拥有自己的"数据分析 Copilot"，不需要依赖昂贵的商业方案，也不必把数据交给第三方处理。2025 年底才开源的它还很年轻，但架构设计和功能完整性已经相当成熟，值得关注。
项目信息