最新

与 VillageSQL 相关的代理技能。这些技能在 Claude Code、Gemini CLI、agy、Codex、Cursor、Amp 和 Kiro 中运行。

嗨，HN，我们正在开源ktx。这是一个可执行的上下文层，使代理在您的数据堆栈上更加可靠。 我们在为数十家公司构建生产级数据代理的过程中，积累了经验后开发了它。如果您也尝试过构建这些代理，或者仅仅是在您的数据仓库上使用Claude Code或Codex，您会知道准确性是首要问题。代理在生成有效的SQL方面表现出色，但并不总是生成正确的SQL。 以下是一些“代理出错”的例子： - 过时的列 + 隐藏的业务规则：在准备董事会报告时，一位财务分析师向Claude Code询问“按客户细分的ARR”，它从多个表（订阅、计划、账户）中推导出ARR，然后按accounts.industry分组。但CC并不知道这个行业列在几个月前已被弃用，或者过去的董事会报告在ARR计算中排除了暂停的订阅。 - 连接扇出：一家零售商的数据分析师使用公司内部代理为季度业务回顾准备产品收入报告。该代理将订单与订单项连接，然后按order_items.product_id对orders.total_amount_cents进行求和。SQL运行良好，但每个订单的收入在每个行项目中重复一次，如果大多数订单只有一个项目，大多数人会忽略这一点。 - 缺失的归因逻辑：一位市场分析师询问Codex“哪些活动带来了最多的收入？”Codex将marketing_touches与用户和订单连接，并按utm_campaign分组。但由于每个订单在购买前可能有多个接触点，同一订单可能会被归因于首次接触、最后接触、每次接触或用户购买前点击的每个活动。如果代理选择了与团队归因逻辑不匹配的方法，他们将做出次优决策。 为了解决这个问题，我们最初通过技能和维基风格的知识库为代理提供了更多上下文。这确实提供了一些有用的额外上下文，但仍然依赖于它在没有错误假设的情况下编写SQL。 我们探索的下一个解决方案是实现经典的语义层。这解决了可执行部分，但由于它们是为传统BI工具而设计的，因此构建和维护起来非常麻烦。而且作为独立工具，它们缺乏来自内部文档等非结构化数据源的所有有用上下文。 因此，我们构建了ktx，并将其分为两个部分： 1. 业务上下文存储在自动摄取和自动填充的Markdown维基页面中。 2. 可查询的定义存储在YAML文件中，定义了表、行粒度、连接、度量、维度、过滤器和过滤器组。 这样，当代理需要一个度量时，它会向ktx请求度量、维度、过滤器和过滤器组，而不是自己编写整个查询。ktx的规划器选择连接路径，使用粒度和关系元数据，捕捉连接扇出和连接缺口等问题，并编译仓库SQL，同时利用它所能访问的额外非结构化知识。 ktx是Apache 2.0许可。它可以从大多数仓库（BigQuery、Snowflake、Postgres等）、建模工具（dbt、MetricFlow、LookML）、BI工具（Looker、Metabase）、文档工具如Notion以及用户交互的修正中摄取数据。 手动安装： ``` npm install -g @kaelio/ktx ktx setup ``` 或者将以下提示提供给您的代理： ``` Run npx skills add Kaelio/ktx --skill ktx and use ktx skill to install and configure ktx ``` 我们特别希望听到那些尝试使用Claude Code、Codex或在分析仓库上构建自定义代理的人的反馈。他们在哪些方面失败了？您尝试了什么来使答案更可靠？

人工智能很快将在数学问题解决方面超过几乎所有人类数学家。那么，也许是时候让数学教师和学生停止担心和测试困难的数学问题解决能力了？