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

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

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

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

状态不能只存在对话里

规划、执行和验证要分工