24小时热榜

嗨，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或在分析仓库上构建自定义代理的人的反馈。他们在哪些方面失败了？您尝试了什么来使答案更可靠？

邮件内容如下： garnix即将关闭 大家好， 我们想通知大家，garnix将与Shopify合并。 我们很遗憾地宣布，作为这一过渡的一部分，garnix的托管服务将于2026年7月15日关闭。但我们将开源garnix的代码库，链接在这里（https://github.com/garnix-io/garnix-ci）；我们希望这能帮助您顺利迁移到使用自己的实例或共享实例。如果您有兴趣运营一个公共社区实例，请与我们联系——我们很乐意与您交流。 我们还将在7月15日删除所有用户数据，包括构建工件。请确保在此之前下载您想保留的内容。 感谢大家多年来使用garnix，并给予我们的反馈和支持。虽然我们对在Shopify的下一步感到兴奋，但我们也会怀念与这个社区的合作。从一开始，您们在我们的Open Collective阶段慷慨捐赠和提供的深思熟虑的反馈都让我们倍感珍惜。 注意：发布时GitHub链接无法访问。我想它很快就会恢复。

嗨，我是来自Elodin的Dan，我们正在开发一个开源的实时飞行软件仿真系统。 对于AI大奖赛的参赛者来说，第一轮虚拟资格赛的等待实在是漫长而煎熬。 如果你正在参赛，可以查看我们的仿真工具，以帮助你度过这个阶段。该工具是根据公布的比赛约束和消息格式构建的，能够与真实的Betaflight系统兼容运行。我们发现，Betaflight在实时运行时至少需要每秒1000个传感器样本。 此次比赛促使我们引入了一项新功能，可以直接在仿真循环中生成摄像头传感器。通常，人们会连接到Unreal或类似的游戏引擎来创建摄像头传感器，这种方法效果很好，但非常繁重。对于本次挑战的简单需求，直接在循环中生成样本非常方便且易于使用。我们很高兴听到你对此的反馈！虽然目前的外观并不华丽，但它使用了Rust Bevy游戏引擎，这应该能让我们迅速提升视觉效果。 我们应该能够轻松地将我们的实现转移到发布的比赛仿真系统上。希望你喜欢，祝你好运！