从单条 SQL 到完整任务：Agent 带来的五个数据负载变化

本文发表于： &{ new Date(1788969600000).toLocaleDateString() }

过去，企业分析系统中的查询大多由人发起：用户打开固定报表、调整筛选条件，或根据阶段性发现继续下钻。固定报表本身也可能触发多条 SQL，分析师的自由探索同样可能包含多轮查询；但查询节奏和探索深度通常由人控制。

当需要多步查询、下钻和交叉验证的数据分析型 Agent 进入业务后，情况发生了新的变化。用户只需给出一个业务目标，Agent 便可能自动拆解问题、调用数据工具、读取中间结果，再决定下一步是否继续验证或展开新的分析分支。

例如，当业务人员提出“分析某区域销售额下滑的原因”时，Agent 可能先查看整体趋势，再按渠道、商品、门店等维度拆分；发现异常后，继续下钻到促销、库存或履约数据，最后进行交叉验证并形成结论。

因此，企业需要管理的已不只是单条 SQL 的性能，也包括一个完整任务在查询、资源消耗和执行过程中的整体表现。

负载形态：从人驱动探索到任务自主展开

与传统的人机交互式分析相比，多步数据分析型 Agent 的负载通常呈现出三项更值得关注的特征：

• 任务自动展开：查询不完全由用户逐次点击触发，后续动作可由中间结果动态决定。
• 请求可能更集中：一个任务中的独立分析分支可在短时间内并发执行，多个任务同时运行时则可能形成突发负载。
• 资源消耗更难预估：不同任务的下钻深度、重试次数、查询路径和扫描范围可能不同，难以只靠单条 SQL 或平均 QPS 预先判断整体影响。

在复杂归因、异常分析和交叉验证等任务中，Agent 可能在短时间内连续发起多轮串行或并行查询。

1. 并发：从单条查询响应到完整任务耗时

在多步 Agent 任务中，查询的并发通常来自两个层面。

一是单个任务中的并行分析。例如，在销售异常归因中，渠道、商品和门店维度之间可能相对独立，Agent 可以同时发起多条查询，以缩短等待时间。

二是多个任务同时运行。当不同业务人员或系统在同一时间发起多个分析任务时，数据库面对的就不再只是单条查询的快慢，而是多组任务在同一资源池中的排队、竞争与调度问题。

因此，QPS 和单条 SQL 的平均响应时间仍然重要，但不足以单独衡量 Agent 的任务体验。串行步骤中的等待与执行耗时会逐步累加；并行步骤中，最慢分支往往决定该阶段的完成时间。以销售归因任务为例，即使渠道、门店和商品三条查询很快返回，只要某条关键的促销或库存查询因资源排队而延迟，后续分析仍然需要等待。

此外，任务总耗时还应包括模型推理、工具调用、网络传输与重试，不能全部归因于数据库。

除了活跃连接数等辅助指标，企业应重点关注运行中查询数、排队查询数、排队时间、查询 P95/P99 延迟，以及任务端到端耗时和成功率。真正需要优化的，是在满足结果质量要求的前提下，任务能否稳定完成并在业务可接受的时间内返回。

MirrorData 是 MIP（镜舟企业级 AI 数据平台）的数据底座，面向高并发分析场景提供高性能查询能力，并支持企业通过相应的资源管理与调度策略，对不同优先级的查询负载进行治理。

2. 时效：数据新鲜度影响分析与行动

Agent 的任务通常遵循“观察、判断、行动或输出”的过程。上一轮查询得到的数据，可能直接影响下一轮分析方向。

当数据时效不足时，Agent 很有可能基于一份已经过时的数据状态，得出逻辑上看似合理、但已不适用于当前业务的结论。

例如，在销售异常归因中，Agent 可能发现某商品销量下降与库存减少同时出现，并进一步建议补货或跨仓调拨。但如果库存数据尚未反映最近完成的补货或调拨，Agent 看到的仍是旧状态，最终建议便可能失去时效性。

如果 Agent 不只是生成建议，还拥有创建工单、触发调拨或调用其他业务系统的权限，数据新鲜度只是风险控制的一部分。企业还需要通过最新状态回读、幂等校验、审批流程和执行控制，避免重复下发或错误执行。

不同任务对数据新鲜度的要求也不相同：

• 经营复盘、月报、周报和趋势分析等任务，通常可接受小时级更新或 T+1 数据。
• 实时预警、动态定价、库存调度和运营响应等任务，通常对数据延迟、一致性和状态准确性有更高要求。

另外要区分两个概念：

• 写入后的查询可见延迟：数据进入分析系统后，多快能够被查询到。
• 源端到 Agent 可查的端到端延迟：从业务系统发生变化，到数据被采集、传输、加工、刷新，并最终可供 Agent 使用的总耗时。

后者不仅取决于分析数据库，还与数据采集、流式传输、数据加工、同步策略和语义层更新有关。

对需要更低数据延迟的业务，企业需要评估数据平台在实时写入、查询可见性和并发读取上的承载能力，并从采集、传输、加工到查询的完整链路定义数据新鲜度目标。MirrorData 可作为这一数据链路中的分析承载层，来支持高频实时增量写入与写入后快速查询可见，帮助企业缩短实时数据进入分析任务的等待时间。

3. 隔离：让探索性负载与核心业务共存

引入 Agent 后，企业原有的核心报表、高管看板、实时写入、ETL 管道和批量加工任务不会停止。Agent 带来的是一类具有探索性、动态性和不确定性的新增负载。

例如，在销售归因任务中，Agent 为验证某个假设，可能发起跨度较大、关联较多或扫描范围较广的查询。这样的探索并不一定是错误的，但如果与高优先级报表、实时写入或批量任务完全共享资源，就可能增加 CPU、内存、网络和调度资源的竞争。

反过来，在核心报表访问高峰或批量任务集中运行时，Agent 查询也可能被挤压，导致任务等待时间增加、体验下降，甚至因超时而中断。

因此，企业需要的不是简单禁止 Agent 访问数据，而是根据业务等级、资源预算和稳定性要求，为不同类型的负载设置清晰的资源边界。

常见的分级治理方式包括：

• 在共享集群中，通过资源组或类似机制，为不同负载分配优先级、并发额度和资源限制。
• 对高优先级报表、关键业务服务或高风险探索任务，采用独立计算资源提供更强的隔离。
• 为 Agent 查询设置合理的超时、并发和资源使用边界，减少异常查询对整体系统的影响。
• 根据业务高峰、任务优先级和资源利用率，动态调整调度策略。

在这一类混合负载场景中，MirrorData 可作为数据执行基础，支持企业通过资源组、资源限制或独立计算资源等方式，为不同优先级的查询设置更清晰的资源边界，降低探索性分析对核心报表和写入任务的影响。

4. 成本：重复查询和无效调用需要约束

Agent 在下钻、交叉验证和失败重试过程中，可能重复访问相似的数据范围。

以销售异常归因为例，Agent 可能多次查询同一时期、同一区域的销售基线，只是改变了分组维度、过滤条件或对比口径。其中一部分查询是必要的验证过程；另一部分则可能来自重复规划、低效重试，或不明确的停止条件。

因此，成本治理应在保证任务质量的前提下，减少不必要的扫描和无边界的重试。

其中一个容易被误解的问题是：SQL 文本差异。大模型针对同一个分析目标生成的 SQL，可能在字段顺序、别名、格式或条件写法上存在变化。仅依赖原始 SQL 文本进行精确匹配，往往难以充分复用计算结果。

对于可复用的计算，企业可以结合查询缓存、物化视图、预聚合和语义层等机制降低重复开销：

• 查询缓存：以 StarRocks 的 Query Cache 为例，可复用符合条件的局部聚合中间结果，减少重复扫描与计算；实际效果取决于查询结构及缓存适用条件。
• 物化视图：适合承载高频、规则相对稳定的指标或聚合计算，并通过满足条件的查询改写减少重复扫描。
• 预聚合与指标层：指标层统一业务口径；结合预聚合或物化视图，可减少高频指标反复从明细数据计算的开销。
• 任务级限制：可用于约束超时、并发、重试次数、循环次数或资源预算，避免单次任务无边界消耗资源。

在数据执行层，MirrorData 可以通过查询缓存、物化视图等适用的计算复用机制降低重复扫描。对于高度动态的 Agent 查询，实际复用效果仍取决于查询结构、数据更新频率和查询改写条件。

5. 观测：从监控单条 SQL 到追踪一次任务

在查询性能排查中，单条 SQL 通常是重要的分析单位。关注单条语句的 CPU 占用、扫描行数与执行计划，但在 Agent 场景下，已不足以单独解释一次任务的触发原因、执行过程与业务影响。

当数据团队发现一条高消耗或长耗时 SQL 时，单看执行计划通常不足以解释问题：

• 这条 SQL 来自哪个业务部门、哪个用户或哪个 Agent 实例？
• 它属于哪一个任务、哪一次工具调用或哪一个执行步骤？
• 前序步骤的目标和返回结果是什么，为什么会触发这一轮查询？
• 查询结果是否已经返回给 Agent、传递至后续步骤，或被最终输出显式引用？

这要求观测体系从单条 SQL 监控进一步扩展到“任务—工具调用—查询执行”的关联追踪。

在 MIP 平台架构中，数据底座层 MirrorData 负责承载数据查询与分析负载；智能数据层 MirrorPilot 面向 Agent 的任务执行与数据调用过程；平台控制层 MirrorControl 则围绕企业级权限、策略与审计要求，帮助建立更可控的数据使用边界。

在上述分层架构下，通过贯通任务标识、工具调用记录与数据库查询标识，企业可进一步建立任务级关联追踪，将数据访问、查询执行和资源消耗纳入同一条排查链路。

结语

Agent 给数据基础设施带来的变化是查询开始以任务为单位自动展开、动态演进，并与既有生产负载共享同一套数据资源。

企业不必一开始就为所有 Agent 场景建设复杂架构，但应先识别自身最优先的瓶颈：是并发排队、数据时效、资源竞争、重复计算，还是任务治理与审计能力不足。

镜舟可结合企业现有的 Agent 架构、数据链路与生产负载，协助梳理任务级性能瓶颈，评估隔离和限额方案，并共同确定验证指标与测试路径。欢迎点击此处或阅读原文预约交流。