一句话看懂：InfoQ CN 介绍了 2026 年 11 月的一次容灾演练分析实践：用 AI 智能体生成受约束的查询、由 DuckDB 在对象存储上做确定性计算，再由智能体解释结果。它讨论的不是“查询引擎过时”，而是引擎被收进智能体工作流。
事件核心：发生了什么
该实践发生在一次真实的容灾隔离演练中：一个区域被有意隔离，流量预期转移到幸存区域。分析团队将 30 秒粒度的服务指标以 Parquet 格式存入兼容 S3 的对象存储，用 DuckDB 做聚合，并由 AI 智能体生成只读 SQL，经白名单校验后在沙箱执行。返回的结构化“事实包”再由智能体归类、给出证据。文章强调，结论所需的基线、稳态窗口和 SLO 判定都由确定性代码完成，大模型只负责解释。
为什么重要
它给出一套可复用的分工原则：精确计算交给 SQL 引擎，依赖上下文的推理交给大模型。这能避免把大模型当查询引擎——让模型直接读数十万行数据去算错误数和百分位，既慢又容易出错。对行业而言，这意味着湖仓和 SQL 不会被“跳过”，而是更多以嵌入式组件的形式出现在 AI 智能体工作流里；是否需要托管湖仓，取决于负载规模，而非是否有 AI。
对用户/开发者/创作者的影响
开发者可以关注这种“智能体 + 嵌入式 DuckDB + 对象存储”的轻量组合：无需先搭共享湖仓，就能完成可复现的分析，并通过白名单和沙箱控制风险。运维与数据团队则应把可复现性当作硬性要求，保留输入、配置、确定性事实和智能体元数据，便于重放和评估。对普通用户来说，这类架构可能让故障分析报告更快生成，但关键数字仍应来自可验证的计算。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
一是这种嵌入式方案在数据量继续增长后，是否会转向 Spark、Trino 或托管湖仓；二是智能体生成查询的校验与沙箱机制能否产品化；三是规则引擎与大模型判断之间的边界，是否会形成更明确的标准。目前公开信息显示，这仍是一个原型实践，并非已发布产品。
来源：InfoQ CN
