ktx — 数据代理的上下文层
为数据代理提供上下文层，让其准确查询分析型数据库，并自动获取公司经批准的指标定义与业务知识。
证据显示：README 明确声明只读连接、本地运行、无托管服务，且 telemetry 有隐私保护措施。但缺少用户确认机制（如执行前确认）和回滚机制的详细说明。依赖安全方面有锁文件和 CI 检查，但未提供依赖漏洞扫描证据。外部影响方面，只读设计是好的，但未说明对数据库的潜在影响。来源归属方面，有明确的维护者信息。扣分原因：用户确认和回滚机制证据不足。
证据显示：项目有 CI 工作流、测试脚本和多种测试，表明内部一致性较好。依赖可用性方面，有锁文件和明确的包管理器版本。失败消息方面，测试中检查了错误输出。扣分原因：静态审查无法验证实际运行时的可靠性。
证据显示：README 明确了目标用户和适用场景，也列出了不适用的情况。能力边界清晰，如只读、支持多种数据库。触发精度方面，CLI 命令和 MCP 工具有明确文档。环境适配方面，支持多种数据库和 LLM 后端。扣分原因：未提供详细的配置选项和限制。
证据显示：信息架构清晰，有项目布局和文档链接。安装说明简单明了。命名稳定性方面，有版本号和语义化发布。示例和 FAQ 提供了基本使用场景。已知限制在 README 中有提及。许可证为 Apache-2.0，完整。版本变更日志未直接提供，但语义化发布暗示有。维护责任明确为 Kaelio。扣分原因：缺少明确的变更日志文件。
证据显示：输出可用性方面，CLI 提供多种输出格式（如 JSON、plain）。边际价值方面，解决了数据代理的上下文问题。成本效益方面，无额外计费，使用自带 LLM。扣分原因：静态审查无法评估实际效果。
证据显示：README 中的声明有文档链接支持，但未提供独立验证。交叉来源验证不足，主要依赖单一来源。事实与推断分离方面，README 区分了功能描述和比较。扣分原因：缺乏第三方验证。
- 静态审查无法验证实际运行时的安全性和可靠性。
- 用户确认和回滚机制证据不足，需进一步审查。
- 依赖安全未提供漏洞扫描证据。
- 发布者身份未验证，需谨慎对待。
这个 Agent 能做什么，适合哪些场景？
ktx 是一个可执行上下文层，由 Kaelio 构建，旨在为 Claude Code、Codex 等 AI 代理提供仓库的准确上下文。它自动从 dbt、Looker、Metabase、Notion 等来源摄取知识，构建语义层，并通过 CLI 和 MCP 工具为代理提供指标定义和可连接的列。它支持多种数据库，如 PostgreSQL、Snowflake、BigQuery 和 ClickHouse，并且只读设计，不会向数据库写入数据。它提供了诸如 `ktx setup`、`ktx ingest` 和 `ktx mcp start` 等命令，用于设置、摄取上下文和启动 MCP 服务器。该工具是 Apache-2.0 许可，可由用户自行托管，无托管的托管服务。
ktx 摄取数据库模式、元数据、使用模式以及 dbt、Looker、MetricFlow 等语义层，结合 wiki 和 Notion 等业务知识。它通过上下文引擎构建本地 wiki 和语义层 YAML，检测可连接的列并自动解决扇出/陷阱。它提供 CLI 工具，如 ktx sl "revenue" 用于搜索语义源，ktx wiki "refund policy" 用于搜索 wiki 页面，以及 ktx mcp start 用于启动 MCP 服务器，供代理通过模型上下文协议查询。代理可以使用 MCP 获取经批准的指标和可连接的列，并编译成只读 SQL 运行在仓库上。它还提供 ktx status 命令用于检查项目就绪状态，包括 LLM 和嵌入提供者的配置。
- 数据工程师希望让 Claude Code 或 Codex 代理使用经批准的指标定义查询仓库，而不是每次推断逻辑。
- 拥有分散在 dbt、Looker、Metabase 和 Notion 中的业务知识的团队，希望将这些整合到一个可搜索的上下文中供代理使用。
- 分析工程师需要用语义层自动解决扇出和陷阱，并为指标提供可重用的 SQL。
- 数据平台团队希望为代理提供只读上下文，而不想暴露写入访问或管理托管服务。
- 个人开发者希望在本地使用自己的 LLM API 密钥（如 Claude 或 Codex 登录），无需额外托管费用即可获得数据代理的上下文。
这个 Agent 有哪些优点和局限？
- 自动构建语义层，没有人工维护负担，并解决了扇出/陷阱等常见问题。
- 从多种来源摄取并整合业务知识，包括 dbt、Looker、Metabase、Notion 和 Google Drive，从而提供全面的上下文。
- 提供 CLI 和 MCP 接口，适用于 Claude Code、Codex、Cursor 等代理，使其易于集成。
- 只读设计，不向数据库写入数据，确保安全性。
- 需要 SQL 数据仓库，不适用于非 SQL 数据源。
- 需要配置 LLM 提供者（如 Anthropic、Vertex AI 或本地代理登录），可能产生成本或依赖。
- 需要 Node.js 和 Python 环境，可能引入复杂度。
- 本地运行，没有托管服务，用户需要管理自己的基础设施。
- 项目较新，可能缺少成熟生态或长期支持。
如何安装或部署这个 Agent？
全局安装 npm 包：npm install -g @kaelio/ktx。需要 Node.js 和 Python（通过 uv 管理）用于开发。项目需要 SQL 数据仓库和 LLM 提供者（如 Anthropic API、Google Vertex AI 或本地 Claude Code / Codex 认证）。
如何使用这个 Agent？
在项目目录中运行 ktx setup，按照提示配置提供者、连接并构建上下文。然后运行 ktx status 验证就绪。如果显示需要，运行 ktx mcp start --project-dir ... 启动 MCP 服务器，然后打开代理客户端。代理可以使用 MCP 工具查询语义层和 wiki。
这个 Agent 与同类方案有什么区别？
与 git 提交信息提示词优化器不同，ktx 专注于提供数据代理的上下文。与 dbt 或 MetricFlow 等传统语义层相比，ktx 摄取这些语义层并添加 wiki 内容，提供统一的搜索表面。该 README 提到 ktx 摄取 dbt 或 MetricFlow 语义层，并将其与原始表检查和 wiki 内容相结合，而不是替代它们。
常见问题
ktx 会将我的数据发送到托管服务吗？
ktx 支持哪些 LLM 提供者？
ktx 如何保证我的数据库安全？
ktx 需要运行中的服务器吗？
ktx mcp start）。