语义层
MotherDuck
业务上下文、语义模型生成、问答契约与可执行验证。关注如何保留人能检查和维护的定义。
3 条已收录资料 · 0 个设计案例。下列日期对应各篇材料，不代表产品当前能力清单。
近 30 天重点 0 条资料中优先展示，按原文日期
近 30 天暂无已收录的新资料，下面保留历史参考。
精选参考 3 条
AI 可以重写语义模型，业务问答契约应该保留在哪里
团队用 Agent 生成并验证 Malloy 模型；在其测试中，Markdown + SQL 更省 token。文章主张用问题与答案对保留业务意图和验收条件。
另有 1 家信源报道：X 线索
推荐理由：提供一个有价值的设计视角：把业务意图与生成代码分开维护，并为重新生成建立验收依据。
语义层MotherDuck
MotherDuck用Guides补齐Data Agent看不到的业务上下文
MotherDuck推出Guides，把指标定义、表关系、历史迁移和业务例外等说明作为可查询、可版本化的上下文保存在数仓中。Agent在执行查询或构建数据任务时，可以按需发现并加载这些说明，减少仅凭schema猜测业务语义造成的错误。
另有 1 家信源报道：X 线索·@motherduck
推荐理由：企业数据Agent的核心瓶颈正在从SQL生成转向上下文治理，Guides提供了一个接近‘数仓内技能文件’的实现样本。
数据Agent将制造机器查询洪峰，传统数仓面临新负载
MotherDuck认为，LLM最近半年才开始较稳定地生成SQL，数据Agent并没有错过窗口。新的挑战是Agent会在很短时间内发起大量探索和验证查询，而传统数仓主要围绕人工交互与定时任务设计，需要重新考虑并发、隔离和成本控制。
另有 1 家信源报道：X 线索·@motherduck
推荐理由：这条观点把讨论从‘Agent能否写SQL’推进到‘数据平台能否承受机器规模的查询行为’，对容量规划很有启发。