Dex by Exmergo

你好 PH，我是 Marco，Exmergo 的联合创始人。

我们决定把 Dex 开源，它是我们内部为面向 Agent 的分析工程打造的。

我们内部构建了大量产品和营销分析，作为一个小型的创始团队，我们重度依赖编程 Agent 来完成这些工作。

我们发现，普通的编程 Agent 显然非常擅长写 SQL，但在管理整个分析生命周期方面却非常糟糕。

每次会话都要重新学习 schema。

对存放凌乱非结构化数据的仓库（例如从 Firestore 到 BigQuery 的 CDC 流）没有任何策略。

PII 检测完全取决于 Agent 是否愿意谨慎处理敏感信息。

在账单出来之前，根本不知道一个查询要花多少钱（对于列中可能嵌套的巨大 JSON 来说简直是灾难）。

所以我们把缺失的部分补上了。先是一个成本守护（cost guard），然后是一个基于聚合而不是原始行进行剖析的 profiler。

接着是一个 snapshot（快照），这样下一次会话可以从上一次结束的地方继续。

仅仅在我们端到端使用它完成了几个分析项目之后，我们就决定把它开源。

而现在经过几周的早期用户反馈之后，它来到 Product Hunt 了！

https://github.com/exmergo/dex

下面是完整的流程。

安装：

npx skills add exmergo/dex

如果你在 Claude Code 中，也可以走插件路线。

将它指向一个仓库，并（可选地）指向一个 dbt 项目。如果你想完全不使用凭证来试用，可以将它指向一个本地的 DuckDB 文件。

/dex:explore 读取仓库内容。它会排序出重要的内容并进行有选择性的剖析，推断出 join 然后用真实的探针进行验证，并将一份草稿映射缓存到 .dex/。

它是只读的，并且在运行前会清除一个成本上限：BigQuery 按字节计，Snowflake 按仓库秒数计，Databricks 按 DBU 计，Redshift 按 RPU-小时计。

PII 会被标记，持续保持标记，永远不会在结果中出现。我们的 PII 标记相当激进，所以可以预期会有误报。你可以在 `.dex/config.yml` 的 `pii_overrides` 条目中手动覆盖被标记为 PII 的列。

/dex:transform 编写 dbt 工作。从 staging 到 marts，同时生成 tests 和 docs，在其之上构建 MetricFlow 语义模型。

每一个变更都以 diff 的形式呈现，并针对你的开发目标进行验证。每个转换计划都会生成一个可审计的 `.dex/plans/.json`，在运行 `transform apply` 之前不会对 dbt 项目做任何修改。

/dex:maintain 是我每天都在用的命令，老实说也是我们那些真正在做数据和分‍析工程的早期用户最喜欢的部分。

它会对比你的仓库和项目与上一次快照的差异，并告诉你哪里出了问题：一个列在模型不知情的情况下被重命名了，一次加载的数据量只到了平常的 5%，一个新加的 join 悄悄让一个事实表失去了唯一性。然后它会提议具体的修复。

在 dbt Labs 的 ADE-bench 上，75 个任务中，Dex 使用 Claude Sonnet 5 解决了 76%，成本大约比 Claude Fable 5 低 2.5 倍，这是根据我们开源的基准测试结果。每一次运行的原始结果都在仓库中。我们把它当作一个底线而不是一个奖杯来发布（不过我们正在优化性能，敬请期待）。

但通过率并不能告诉你你是否信任那个 diff，而 diff 才是真正重要的部分。

让我们与“技能包”（skill packs）区别开的一点是：Dex 同时也是一个 Python 包。三个命令底层的引擎以 exmergo-dex-core 的名字发布在 PyPI 上，带有一个真正的程序化 API，所以你可以从自己的代码中驱动同样的循环，而不必去调用 CLI 然后解析 JSON。https://pypi.org/project/exmergo-dex-core/

Apache 2.0 协议，免费，不需要账号。在运行任何东西之前，请先阅读仓库中的 SKILL.md 文件。它会接触你的仓库，你应该先清楚它具体会做什么。

我们目前支持以下数据仓库和数据库：Snowflake、Databricks、Google BigQuery、AWS Redshift、DuckDB、Postgres

路线图中：Trino、ClickHouse 以及微软的数据仓库。

还有一件我最希望从你这里得到的事。如果你运行 dbt，请告诉我 /dex:maintain 在哪里本来能帮到你，又在哪里会判断错误。

考虑到可能出现的各种问题，drift detection（漂移检测）既是最有价值的，也是最难做好的部分。

另外，请务必在 GitHub 上为任何 bug 或改进建议开一个 issue！