这是一篇 Show HN（Hacker News 上展示新项目的帖子），介绍 ktx 这个面向 data agents 的开源 executable context layer（可执行上下文层）。它试图把 semantic layer（语义层，负责把业务定义转成可执行查询）和 wiki / knowledge base（记录业务口径、术语和团队经验的知识库）合并到一起。评论里提到它会从 dbt（数据转换与建模工具）、Looker（BI 工具）、Metabase（开源 BI 工具）和 Notion（文档协作工具）中自动摄取内容，也会分析历史 SQL 来反推业务规则。讨论还把它放到更大的产品谱系里比较：Wren、Cube 这类偏语义层引擎，OpenViking（面向 agent 的上下文/记忆基础设施）和 Glean（企业搜索）这类偏知识检索工具，而 ktx ცდილ把两边都做进来。
评论者一开始把 ktx 理解成一种“更有用的文档系统”，但讨论很快指向它实际上想同时覆盖两类能力：一类是 semantic layer（把业务指标编译成正确 SQL），另一类是存放业务知识、术语和流程的 wiki / company brain。维护者明确说，ktx 不是只做文档索引，而是要给 data agents 提供可执行的上下文，让它们可以用声明式请求替代手写查询逻辑。有人拿它和 Wren 2.0、OpenVikings 对比，回复则强调 Wren 更偏手写模型+执行引擎，而 ktx 更偏自动从现有数据栈抽取并维护上下文。
围绕“谁来写 wiki / business rules”这一点，回复给出的核心答案是：大部分内容并不需要人工从零编写，而是由 `ktx ingest` 从现有数据栈中拉取原始数据后自动生成。它还可以从历史 SQL、Looker 或 Metabase 仪表板中反向推断规则，并允许接入 agent 提交额外 memories，持续补充最新上下文。这个思路的隐含前提是，过去为文档和规则付出的成本回报很低，但对 data agents 来说，预先沉淀可复用的业务定义已经直接影响成败。
有人质疑为什么不用 graph-based approach，作者回应说当前采用的是 file-first：知识实体以 markdown/yaml 纯文本形式存储，但彼此通过链接连接起来。这样 agent 可以先用 lexical search 和 semantic search，再用 RRF（Reciprocal Rank Fusion）融合结果找到入口，随后沿着链接逐步补齐上下文。对于业务语境会随时间变化的问题，系统依赖 ingestion reconciliation 和 git versioning；自动摄取阶段先做去重和合并，复杂冲突留给人来裁决。另有补充说明开发过程中还做了 link detection 和 text-to-SQL benchmarks，用来比较不同方案。
讨论里也反复出现“如何证明它真的有效”这个问题，作者说正在准备 Spider 2 提交，希望尽快给出基准结果。这个方向说明他们并不是只看概念，而是试图用标准 text-to-SQL 评测来衡量准确率和鲁棒性。另一条重要观点是 context management 的重点在于少用 token、但把关键事实拿全：先做分层检索，先取事实、必要时再展开全文。还有人强调，把 token 花在 ingestion 阶段、生成可复用的 canonical definition，通常比让 agent 每次重新探索一遍更划算。
semantic layer（语义层）: 把业务指标、维度和规则映射成可执行查询的抽象层，常用于统一口径并生成正确 SQL。
RRF（Reciprocal Rank Fusion）: 一种融合多路检索结果的排序方法，常用于把 lexical search 和 semantic search 的结果合并。
Spider 2: 用于评估 text-to-SQL 能力的 benchmark，常被用来检验系统把自然语言转成 SQL 的准确性。
MDL: Wren 使用的 Model Definition Language，用来手写语义模型并驱动 SQL 生成。
fan/chasm traps: 数据建模中的连接陷阱，容易在多表 join 时造成重复计数或漏计。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。