“昨天华东销售额是多少”和“新品复购下降后应该先改产品、人群还是触达策略”，看起来都在问数据，工作形态却完全不同。前者目标明确、数据域窄、答案可快速核对；后者需要拆解问题、组合多类证据并形成有条件的判断。
火山引擎的产品路线把智能问数和深度研究分开，核心不是增加 Agent 数量，而是让不同责任走不同链路。
问数链路追求短反馈
智能问数适合指标查询、归因切片和多轮追问。数据集、字段和业务场景需要预先约束，复杂指标最好在 ETL 或语义层中稳定下来。官方文档给单个 Agent 设有数据集与字段数量边界，也建议围绕单一业务场景和意图配置。
深度研究需要证据编排
开放问题要先形成研究子题，再决定查询哪些数据、检索哪些知识、调用哪些工具。最终交付不应只是一个数字，而要区分事实、解释、假设、建议和未决问题。
两条链共享底座，但验收不同
问数和研究都需要指标语义、身份权限、数据新鲜度与审计记录。不同的是验收：问数看定义和数值能否复现；深度研究还要检查来源覆盖、推理跳跃、反例和建议适用条件。
多 Agent 不等于把同一任务拆碎
若多个角色共享模糊目标、重复访问数据、最后由模型自由拼接，系统只会增加协调成本。合理分工应为每条链定义输入、输出、权限和失败去向，并由协调层决定何时从快速问数升级到研究任务。
试点时可以用同一批业务问题做分流测试：明确指标问题应在短链完成；跨域策略问题进入研究链；证据不足时必须请求补充或降级结论。多 Agent 的价值，来自可验证的责任分工，而不是界面上出现多少头像。
升级条件要写成规则
问数链不应因为回答困难就无限扩展。可以设置明确升级信号：问题包含多个业务域、需要外部资料、存在相互矛盾的指标、需要提出行动建议，或预计超过查询预算。协调层据此创建研究任务，并把已经确认的指标定义、查询结果和未决问题一起交接。
反过来，深度研究也不应把简单问题复杂化。若核心事实可由一次受治理查询回答，就直接返回并保留查询证据。短链负责效率，长链负责不确定性；两者之间的交接质量，决定多 Agent 系统是否真的节省时间。
运营指标也应分开：问数链关注首个可用答案时间、定义命中率和追问修正率；研究链关注证据覆盖、关键反例、建议采纳与后续结果。把两条链混成一个满意度分数，会掩盖各自真正的瓶颈。
还要观察协调成本：一次任务发生多少次路由、重复读取了多少上下文、交接是否丢失来源，以及人工需要在哪一步重新解释问题。若角色增加后这些成本持续上升，说明分工边界需要合并，而不是继续增加新 Agent。