NAO

nao 官方标题是「为上下文工程而生的分析代理」，翻成大白话：它不卖「更聪明的模型」，卖的是把上下文工程做扎实的那套工具。做法很像给 agent 建一个文件系统——数据库、文档、查询、代码仓库、语义定义几个目录，把表结构、字段说明、业务定义、示例查询、dbt 模型都放进去，agent 回答问题前先读这些，再去仓库里跑 SQL。它是 100% 开源的，可以自托管。

核心能力

• 上下文即文件系统：官方称用 nao init 生成目录，数据、元数据、规则、文档、工具、MCP 都能放，不设上限。
• 同步现有上下文：nao sync 从数据库、代码仓库、Notion 等来源自动拉取并整理。
• 可靠性测试：nao test 用「问题到 SQL」的单元测试给出通过率、回答率、平均耗时与 token 消耗。
• 对话式分析：nao chat 用自然语言提问，agent 依次探索表结构与指标、执行 SQL、生成图表。
• 发布给他人：可部署带界面的聊天入口，支持自带模型 key，只付 token 费用。
• 多入口提问：官方称通过 nao MCP，可在 Slack、Teams、WhatsApp、Telegram、Claude、Codex、Cursor 里提问。
• 自托管：全部留在自己的基础设施里，用自有 key，官方把这一点作为数据安全卖点。
• 数据源覆盖：示例配置里出现 BigQuery、dbt 仓库与 Notion 页面。

适合谁

• 数据团队与分析工程师：想让业务方自助查数，又不想每次临时写 SQL。
• 已在用 dbt 与 Looker 的团队：把现有模型与指标定义直接变成 agent 的上下文。
• 对数据出境敏感的行业：需要自托管、自有 key、数据不出内网。
• 想让 agent 进 Slack 的产品与运营：官方给了 MCP 多入口路径。
• 只想要「开箱即用商业智能」的人不适合：它要求你先整理上下文，前期是工程活。

使用建议

• 先跑初始化再谈效果：上下文目录空着，模型再强也答不准；先把核心表的字段说明与业务定义补齐。
• 用测试命令建回归集：把业务最常问的十几个问题写成测试，改一次上下文就跑一遍，避免越调越差。
• 权限在仓库层收口：给 agent 的数据库账号只读、只暴露必要表，官方配置支持按表包含与排除。
• 成本看 token：官方测试输出会报总 token，复杂问题消耗高，先限量再放开。
• 开源不等于零运维：自托管要自己管升级、密钥与备份；商用前核对许可证与官方安全说明，规则可能调整。