Kaelio 在 GitHub 发布了开源项目 ktx。项目采用 Apache 2.0 许可，npm 包名是 @kaelio/ktx。
它给自己的定位很窄：不是通用 BI，也不是新的数据仓库，而是面向数据/分析 agent 的本地可执行上下文层。
这个定位有意思。
现在很多团队已经让 Claude Code、Codex、Cursor、OpenCode 这类 agent 去写 SQL、查数、解释指标。问题是，agent 很会执行，但不一定懂规矩。它可能反复探索同一批表，临时猜 join，甚至把“活跃用户”“收入”“留存”这些口径重新发明一遍。
ktx 试图补的，就是这一段空白：在 agent 查数前，先把企业的数据仓库结构、指标定义、BI 资产和团队知识整理成可调用的上下文。
我的判断是，ktx 的价值不在于又造一个语义层。它更像是在通用 agent 和传统语义层之间，加了一层“可执行的数据常识”。
ktx 真正想解决的是 agent 乱猜口径
从项目说明看，ktx 支持连接 PostgreSQL、Snowflake、BigQuery、ClickHouse、MySQL、SQL Server、SQLite 等数据仓库。
它也能摄取 dbt、MetricFlow、LookML、Looker、Metabase、Notion 和团队 wiki 等上下文来源。处理完之后，ktx 会生成语义层和本地 wiki，并通过 CLI 与 MCP 提供给 agent 使用。
这套机制瞄准的是一个很具体的问题：企业数据知识往往不在一个地方。
指标定义可能在 dbt 或 MetricFlow 里。BI 口径可能在 Looker、Metabase 里。业务解释可能散在 Notion、团队 wiki 和历史文档里。agent 如果只拿到 schema，很容易看见表名，却看不见规矩。
| 对象 | 它擅长什么 | 给 agent 用时的短板 | ktx 的切入点 |
|---|---|---|---|
| 通用 AI agent | 写 SQL、调用工具、解释结果 | 容易重复探索、乱猜 join、口径漂移 | 提供整理过的数据上下文 |
| 传统语义层 | 统一指标、维度和模型 | 依赖人工维护，难吸收分散知识 | 摄取已有语义资产并生成可执行上下文 |
| BI / wiki | 保存业务解释和团队经验 | 分散、重复、可能互相冲突 | 去重、整理，并把矛盾交给人工 review |
所以 ktx 不是要替代 dbt、MetricFlow 或 LookML。更准确地说，它想把这些资产拿来喂给 agent。
这里也要压住一个说法。项目里提到 self-improving，但不能理解成“全自动整理企业口径，人工不用管”。材料明确提到，ktx 会把来源之间的矛盾标记出来，交给人工 review。
这反而比较现实。
企业指标不是字典合并。一个收入口径，背后可能牵涉财务确认、销售归因、退款处理和时区规则。让模型自动拍板，省下的是几小时整理，换来的可能是几个月扯皮。
谁该试，谁没必要急
最该看 ktx 的，是两类团队。
一类是已经有 SQL 仓库、dbt、BI 和内部 wiki 的数据平台团队。他们的问题不是没有数据，而是数据知识太散。对这类团队，ktx 可以作为 agent 查数前的“上下文准备层”试点。
另一类是正在把 AI agent 接进数据分析工作流的工程团队。他们已经遇到 SQL 能跑、结果却不可信的问题。ktx 的意义是减少 agent 从零猜表、猜指标、猜业务定义的次数。
动作上，可以先别急着迁移语义层。
更稳的做法是选一个高频分析域，比如营收、用户增长或产品漏斗，把现有 dbt、BI、wiki 接进 ktx。再看 agent 生成 SQL 时，是否少问重复问题，是否少用错误表，是否更愿意引用官方口径。
项目提供了 ktx setup、ktx ingest、ktx sl、ktx wiki、ktx mcp start 等命令。团队可以把 ktx.yaml、semantic-layer/、wiki/ 纳入协作，把 .ktx/ 这类本地状态和密钥留在机器上。
但它不适合所有场景。
如果团队没有 SQL 仓库，或者只是临时跑一条查询，psql、notebook 或现有 BI 工具就够了。ktx 的成本在前置整理，收益来自重复使用。问得越多，口径越复杂，它才越有存在感。
换句话说，小团队可以观望。数据资产已经成规模、agent 已经开始查仓库的团队，才有试点价值。
本地运行是加分项，但安全边界仍在 LLM 配置
ktx 不提供托管服务。它本地运行，本地 MCP daemon 按需启动。项目说明也写到，数据库连接是只读的，ktx 不写入仓库。
这对企业安全审查是加分项。至少它没有要求团队把数据集中同步到一个新的 SaaS 平台。
但这不等于“数据绝对不出门”。
ktx 需要用户自己的 LLM API key，或 Claude Pro/Max 订阅。它支持 Anthropic API、Google Vertex AI、AI Gateway，也可以通过 Claude Agent SDK 使用本地 Claude Code session。
真正要问的是：schema、样例数据、查询结果、业务文档会不会被送到 LLM provider？送哪些？日志怎么留？权限怎么控？这些取决于企业自己的配置，而不是 ktx 单方面能保证。
所以采购或安全团队不该只看“本地运行”四个字。更该看三件事：LLM provider 的数据策略、提示内容是否包含敏感字段、MCP 工具权限是否能被审计。
目前还看不清的是采用效果。原材料没有客户数量、企业部署规模，也没有错误率改善数据。因此，ktx 现在更适合被看作方向明确的开源项目，不宜直接当成已经验证的企业标准件。
接下来观察 ktx，别只看 GitHub 星标。
更该看这几个变量：
- 复杂仓库里，join graph 是否稳定，是否会把偶然字段关系当成可靠连接。
- 冲突 review 能否进入数据团队日常，而不是变成另一堆待处理文档。
- MCP 接入 Claude Code、Codex、Cursor、OpenCode 后，是否真的减少错误 SQL 和返工。
- 当 LLM provider、权限和审计要求不同，企业配置成本会不会高过收益。
主线还是那一句：agent 查数不难，难的是查得像公司里一个懂规矩的人。