火山引擎 Data Agent：问数与深度研究为什么要分流

Fri, 02 Oct 2026 00:00:00 +0000

“昨天华东销售额是多少”和“新品复购下降后应该先改产品、人群还是触达策略”，看起来都在问数据，工作形态却完全不同。前者目标明确、数据域窄、答案可快速核对；后者需要拆解问题、组合多类证据并形成有条件的判断。

火山引擎的产品路线把智能问数和深度研究分开，核心不是增加 Agent 数量，而是让不同责任走不同链路。

问数链路追求短反馈

智能问数适合指标查询、归因切片和多轮追问。数据集、字段和业务场景需要预先约束，复杂指标最好在 ETL 或语义层中稳定下来。官方文档给单个 Agent 设有数据集与字段数量边界，也建议围绕单一业务场景和意图配置。

深度研究需要证据编排

开放问题要先形成研究子题，再决定查询哪些数据、检索哪些知识、调用哪些工具。最终交付不应只是一个数字，而要区分事实、解释、假设、建议和未决问题。

两条链共享底座，但验收不同

问数和研究都需要指标语义、身份权限、数据新鲜度与审计记录。不同的是验收：问数看定义和数值能否复现；深度研究还要检查来源覆盖、推理跳跃、反例和建议适用条件。

多 Agent 不等于把同一任务拆碎

若多个角色共享模糊目标、重复访问数据、最后由模型自由拼接，系统只会增加协调成本。合理分工应为每条链定义输入、输出、权限和失败去向，并由协调层决定何时从快速问数升级到研究任务。

试点时可以用同一批业务问题做分流测试：明确指标问题应在短链完成；跨域策略问题进入研究链；证据不足时必须请求补充或降级结论。多 Agent 的价值，来自可验证的责任分工，而不是界面上出现多少头像。

升级条件要写成规则

问数链不应因为回答困难就无限扩展。可以设置明确升级信号：问题包含多个业务域、需要外部资料、存在相互矛盾的指标、需要提出行动建议，或预计超过查询预算。协调层据此创建研究任务，并把已经确认的指标定义、查询结果和未决问题一起交接。

反过来，深度研究也不应把简单问题复杂化。若核心事实可由一次受治理查询回答，就直接返回并保留查询证据。短链负责效率，长链负责不确定性；两者之间的交接质量，决定多 Agent 系统是否真的节省时间。

运营指标也应分开：问数链关注首个可用答案时间、定义命中率和追问修正率；研究链关注证据覆盖、关键反例、建议采纳与后续结果。把两条链混成一个满意度分数，会掩盖各自真正的瓶颈。

还要观察协调成本：一次任务发生多少次路由、重复读取了多少上下文、交接是否丢失来源，以及人工需要在哪一步重新解释问题。若角色增加后这些成本持续上升，说明分工边界需要合并，而不是继续增加新 Agent。

参考：智能分析 Agent 产品文档

Data Agent 会规划，为什么任务仍然做不完

Wed, 09 Sep 2026 00:00:00 +0000

“新客转化下降，帮我找原因并给建议。”Agent 先查了渠道，再查地区，第三步遇到超时，于是从头重跑；或者生成十几步计划，却在拿到第一张结果表后忘了最初要验证的假设。它看起来会“思考”，任务仍然没有完成。

规划层的职责不是输出一段漂亮的待办清单，而是把复杂目标变成一个能保存状态、检查证据、恢复失败并在必要时交给人的执行过程。

图中每一步都应该有输入、产物、通过条件和失败去向。缺少其中任何一个，所谓“自主循环”很容易变成无界重试。

先分流任务，再决定是否需要规划

并非所有问题都值得启动 Agent 循环：

已有指标、单次只读查询、风险低的问题，可以直接走受约束的查询模板。
需要多个数据源、多个假设或代码分析的任务，才进入计划—执行—验证循环。
涉及写入、外发、敏感数据或高成本计算的任务，应在规划前标出审批节点。
目标、口径或数据覆盖不清时，先澄清，不要用规划掩盖需求缺口。

复杂度分流既节省成本，也缩小故障面。让每个问题都进入多 Agent 编排，通常只会增加延迟和排错难度。

一份可执行计划需要七个字段

每个步骤至少包含：

字段	作用
`step_id`	稳定引用，便于恢复和审计
`objective`	这一步要减少哪项不确定性
`inputs`	使用的数据、语义版本和前置产物
`tool_contract`	允许调用的工具、参数和权限
`output_contract`	预期结果的结构、版本和保存位置
`verification`	通过条件、容差和独立检查
`on_failure`	重试、改计划、降级、澄清或升级给人

“分析渠道影响”不是合格步骤，因为它没有说明使用什么数据、怎样判定完成。更好的目标是：“按渠道计算本月与基准期转化率，在相同口径和覆盖范围下标记绝对变化最大的三个渠道，并验证分母完整性。”

状态不能只存在对话里

长任务的事实状态应存放在 Harness，而不是靠模型记忆：任务目标、约束、当前计划版本、完成步骤、产物引用、失败次数、预算、审批和未解决问题。模型每轮只接收完成当前判断所需的切片。

一个实用状态机可以包含：PLANNING → READY → RUNNING → VERIFYING → COMPLETED，以及 WAITING_INPUT、WAITING_APPROVAL、REPLAN_REQUIRED、FAILED 和 CANCELLED。状态迁移由规则和工具结果触发，模型可以建议迁移，但不能随意把失败改成完成。

检查点应保存逻辑产物与版本，而不是完整复制所有敏感数据。恢复时先检查数据、语义、权限和批准是否仍有效；不能拿昨天的批准运行今天已经改变参数的动作。

规划、执行和验证要分工

常用模式是 Planner 提出下一步，Executor 通过受控工具运行，Verifier 检查结果与约束。它们可以是三个独立组件，也可以由同一模型在不同权限和上下文下完成。关键不在角色名称，而在控制面是否隔离：

Planner 不能持有生产凭证。
Executor 不自行扩张任务范围。
Verifier 使用独立规则、查询结果或测试，不只让模型评价自己的输出。
Harness 决定预算、重试和停止。

多 Agent 只有在专业上下文、工具权限或并行工作确实需要隔离时才有价值。把一个任务拆成许多拟人角色，却共享同一上下文、权限和评分器，只增加通信损耗。

多智能体 on DataAgentX