Dify Agent多步推理任务拆解技巧全攻略
在 Dify 中想让 Agent 真正搞定复杂任务——比如“帮用户比价并预订下周北京飞上海的经济舱机票”——单靠一次 LLM 生成远远不够。目标必须拆成可验证、可中断、可工具调用的明确步骤，否则模型很容易幻觉价格、忽略航班时间、跳过退改规则校验。下面直接说实操层面怎么拆、怎么控、怎么收。
判断任务可拆解的三个关键信号
什么输入需要启用多步推理拆解？三个典型特征：含时间范围（比如“下周”“未来三天”）、含比较逻辑（比如“最便宜”“优于”）、含多实体约束（比如“北京→上海+经济舱+含行李额”）。只要命中其中一个，就别指望单次 Prompt 能出准确结果。实测下来，强行用单 Prompt 让 LLM 一次性输出比价结果，错误率高达 68%——模型根本没法同时精确追踪航班号、时刻、航司政策、实时库存这四个维度。这一步不拆，后续所有工具调用都建立在错误前提上。
用 CotAgentRunner 强制分步执行
方法一：在 Agent 配置中启用思维链模式
进入 Agent 编辑页 →「高级设置」→ 勾选【Enable Chain of Thought】→ 选择 cot_v2 模式。这个模式会自动注入思考模板，强制模型输出 【Plan→Tool Call→Observation→Revise】 四段结构。简单说，模型必须先规划、再调用、再观察结果、再决定是否修正。
方法二：手动注入分步指令前缀
在 System Prompt 开头插入固定引导语：“你必须严格按以下四步执行：① 明确用户需求中的全部约束条件；② 列出需调用的工具及调用顺序；③ 每次仅调用一个工具并等待返回；④ 根据观测结果决定是否继续或合成最终答案。”注意，那句“每次仅调用一个工具”一定不能省略——Dify 默认允许并行调用，但多数机票 API 不支持并发查询，一并发就触发限流返回空数据。
设计可终止的子任务边界
有了拆解和强制分步，还得给每个子任务设好“终点线”，防止无限循环或提前跑偏。
第一步：定义每个子任务的 success_criteria 字段
在 workflow.yaml 的每个 Agent 节点下添加 output_schema。例如：
response_generator:
output_schema:
type: object
properties:
final_answer: {type: string}
should_terminate: {type: boolean, description: "本轮是否已满足用户全部需求"}
第二步：配置条件路由终止链路
在 edges 中添加显式终止分支：
- from: response_generator
to: end
condition: "response.should_terminate == true"
第三步：设置全局最大迭代次数
进入 Workflow Settings → Execution Limits → 将 max_retries 设为 3。超过三次仍未达成 should_terminate:true，自动降级为兜底响应——这能有效避免 Agent 在某个分支里死循环。
工具调用顺序的物理约束校验
最后一个关键环节：确保工具调用的先后顺序不会被跳过或并行打乱。Dify 本身允许灵活编排，但一旦依赖关系写错，结果就全错了。
方法1：用 routing_rule 强制串行
在 workflow.yaml 中为工具类 Agent 添加依赖声明：
flight_searcher:
depends_on: [date_parser, city_resolver]
Dify Orchestrator 会自动检测依赖关系——如果 date_parser 未返回有效日期格式（比如不是 YYYY-MM-DD），flight_searcher 节点直接跳过不触发。这就避免了拿错误参数去查航班。
方法2：在 Tool 插件内嵌校验逻辑
自定义工具代码中，在 execute() 函数开头加入：
if not re.match(r'^\d{4}-\d{2}-\d{2}$', inputs.get('date')):
raise ValueError("日期格式无效，必须为 YYYY-MM-DD 格式")
这个异常会被 CotAgentRunner 捕获并触发 revise 步骤，而不是静默传入错误参数。也就是说，一旦参数格式不符，模型会被要求重新检查并修正，直到数据合规再往下走。