Agent任务规划:分解与ReAct机制

回答与解析

规划的关键步骤

1. 目标与约束：把用户目标转换为可验证的完成条件、预算、权限和截止时间。
2. 任务分解：拆成具有明确输入、输出、依赖和失败语义的步骤；能确定的流程优先显式编排。
3. 工具与状态：为每步选择工具，校验参数，保存执行状态、证据和副作用。
4. 执行监控：跟踪超时、错误、循环、预算和结果质量。
5. 重规划与终止：只有观察结果改变前提时才重规划，并设置最大步骤、停止条件和人工节点。

CoT 适合单次推理组织，ReAct 将推理与外部动作交替，ToT 探索多个候选路径；它们不是互斥产品，也不能替代权限、状态机和错误处理。

教学假设：退款查询

假设用户询问退款状态。系统先确认订单标识和用户权限，再查询订单与支付状态；如果信息缺失则追问，如果外部服务超时则按预算重试或降级；真正执行退款属于有副作用动作，必须经过规则校验和用户/人工确认。每一步保存结构化状态，避免模型凭对话文本猜测已经执行的动作。

评测

构造正常、缺参、超时、重复请求、冲突状态和越权样本，测任务成功率、规划合法率、工具参数合法率、重复副作用、人工接管率、延迟和成本。

口语版讲法(约4分钟)

• 一句话定位：Agent 任务规划本质是让 LLM 从思考到行动的闭环
• 任务分解：CoT、ToT、ReAct 的边界，实际是混合使用
• 目标设定与执行监控：层次化拆解加观察-思考-行动-验证闭环
• 落地风险：工具失败、幻觉、长上下文，以及我的取舍

Agent 的任务规划可以理解为把一个自然语言目标变成受约束、可观察、能恢复的执行图。入口先把目标写成明确的完成条件，同时补齐权限、时间、成本和风险限制。接着把任务拆成能够由一个工具或一段确定性逻辑完成的步骤，给每一步定义输入、输出、依赖和失败状态；如果步骤之间有分支或循环，我更倾向显式状态机或工作流图，而不是让模型在自由文本里一直规划。

执行时，模型可以负责识别意图和选择候选动作，但服务端要校验工具 schema、资源归属与权限。每完成一步都把状态、工具参数、返回值和 trace 持久化，再判断继续、重试、降级还是转人工。重试要区分可恢复错误和业务拒绝，写操作必须幂等，最大步骤数、总 token、总时长和调用成本都设上限。计划被新信息推翻时，只重算受影响的后续节点，不重复已经产生副作用的动作。

举个假设场景，用户要查询退款进度。系统先确认用户和订单归属，再查退款记录，信息不足时追问，只有需要人工处理时才创建工单。查询可以安全重试，创建工单则要带幂等键；任何越权、状态冲突或工具超时都进入明确分支。评测不只看最终任务是否完成，还看步骤数、工具选择正确率、参数合法率、重复副作用、人工接管率、P95 延迟和单任务成本。规划是否优秀，最终体现在复杂条件下仍能解释当前状态，并且随时可以停住或恢复。

任务分解并不是越细越好。粒度太粗，模型一次承担过多推理和副作用，失败后无法定位；粒度太细，会增加调用次数、状态同步和补偿成本。我会把“能够独立验证结果、失败后能够安全重试或补偿”作为拆分边界。确定性依赖由图直接表达，不让模型重复猜；只有信息不完整或路径需要选择时才调用模型。工具返回为空、格式错误、业务拒绝和超时未知要进入不同状态，因为它们的重试策略完全不同。

监控层同时看节点和整条任务。节点记录输入摘要、权限结论、工具耗时、重试次数和结果校验；任务层记录当前目标、已完成事实、剩余预算和人工接管原因。线上出现问题时，可以从 trace 恢复到最近的安全检查点，而不是从头执行。若用户中途修改目标，还要判断哪些未执行节点可直接取消，哪些已产生副作用需要补偿。这个机制能回答面试官常追问的两件事：Agent 为什么没有无限循环，以及服务重启或外部系统超时后如何保持前后一致。

关键一句:工具调用失败或超时时的重试与回退策略，以及如何用 Self-RAG 防止 LLM 编造工具返回结果

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你做一个订单客服Agent，用户说“帮我查一下上周的订单”，Agent需要先分解任务，再一步步调用API。你具体会怎么设计这个任务规划流程？

2. 问法 2 · 层层追问

   你理解的Agent任务规划一般包括哪些环节？……那如果任务很复杂，比如订机票，你怎么把大目标拆成小步骤？……拆完以后怎么保证每一步执行正确，出错了怎么办？

3. 问法 3 · 直球架构

   聊一下Agent系统中任务规划的核心步骤，包括任务分解、目标设定和执行监控，最好能结合ReAct或类似框架，讲清楚每一步的具体实现机制。