一篇技术文章提出了一种面向灾难恢复场景的分析工作流，其核心思路是将AI代理的能力限定在生成受约束的SQL或Python代码，由DuckDB从Parquet文件中计算可复现的事实数据，AI代理仅负责解读计算结果。该文章由Peihao Yuan撰写，重点讨论了这一架构中的确定性分工问题。
文章指出，当前业界对AI在数据分析中的角色存在一种常见误解，即认为AI将取代查询引擎。但该工作流的实践表明，AI改变的是数据接口层，而非查询引擎本身。AI代理负责将自然语言意图转化为受约束的查询代码，而DuckDB等嵌入式引擎则承担确定性计算职责，确保相同输入始终产生相同输出，这对于灾难恢复场景下的审计与复现至关重要。
在技术实现上，该工作流利用Parquet列式存储格式作为数据基础，DuckDB直接在Parquet文件上执行查询，无需额外的数据加载或转换步骤。AI代理生成的SQL或Python代码受到约束条件的限制，以避免生成不可复现或非确定性的操作。代理在接收到DuckDB返回的计算结果后，负责对结果进行解释和呈现，但不参与事实数据的生成过程。
文章进一步阐述了“确定性分工”的概念，即将系统划分为确定性计算层和非确定性生成层。确定性层由DuckDB构成，保证分析结果的可复现性；非确定性层由AI代理构成，负责意图理解和结果解读。这种分工使得整个分析流程具备可重放性，即在相同数据快照和相同查询代码下，分析结果可以完全复现，满足灾难恢复场景对审计追溯的要求。
针对架构选型，文章提出了四个判断信号，用于决定何时嵌入式引擎已经足够、何时需要引入托管湖仓架构。这些信号涉及数据规模、并发访问需求、治理与权限管理复杂度以及运维成本等因素。文章认为，对于中小规模数据和有限并发场景，DuckDB加AI代理的组合可以满足需求；而当数据量增长、多团队协作或合规要求提升时，托管湖仓方案更具合理性。
该工作流的提出反映了企业数据分析架构的一种演进方向：AI并非替代底层计算引擎，而是作为自然语言与结构化查询之间的接口层，降低数据分析的使用门槛，同时保留底层引擎的确定性和可审计性。对于关注AI应用落地与数据基础设施的企业而言，这一分工模式提供了可参考的架构思路。
该文观点仅代表作者本人，企服科学平台仅提供信息存储空间服务。
