1. 从“能聊天”到“能干活”任务规划到底在解决什么问题很多人第一次接触 AI Agent脑子里想的还是“更聪明的聊天机器人”。但真正做过 Agent 项目的人都知道聊天只是最表层的能力真正决定一个 Agent 能不能落地干活的是它能不能把一句模糊的用户指令拆成一条可执行、可追踪、可恢复的任务链。这就是任务规划Task Planning要解决的核心问题。我见过太多 Demo 级别的 Agent用户说“帮我整理一下这个季度的销售数据并生成报告”它张口就来一段看似合理的文字实际上既没读文件也没做统计纯靠语言模型“编”。这种 Agent 在演示时很唬人一旦放到真实业务里立刻露馅。原因很简单它没有真正的任务规划能力只是在做文本续写。任务规划的本质是把“目标”翻译成“步骤序列”并且每一步都要明确三件事做什么、用什么工具做、做完之后怎么判断成功。这三件事缺一不可。只说要做什么那是待办清单只说用什么工具那是工具说明书只有把三者绑定在一起才构成一个可执行的计划节点。举个具体的例子。假设用户输入是“分析我上传的 CSV 文件找出异常订单并给我一份汇总”。一个合格的规划器会把它拆成类似这样的结构步骤一读取上传目录确认 CSV 文件存在且可解析工具是文件读取器成功条件是拿到表头和行数。步骤二对订单数据做字段校验识别缺失值和格式异常工具是数据校验函数成功条件是输出异常字段清单。步骤三基于业务规则比如金额为负、时间倒挂、重复订单号筛选异常记录工具是过滤逻辑成功条件是得到异常行集合。步骤四对异常记录做聚合统计工具是分组统计成功条件是生成汇总表。步骤五把汇总结果格式化成报告文本工具是模板渲染成功条件是输出可读报告。你会发现这个拆解过程里每一步都有明确的输入和输出。这就是规划器和“随口一说”的本质区别。规划器输出的不是自然语言段落而是一个结构化的任务图Task Graph节点是步骤边是依赖关系。为什么强调依赖关系因为真实任务里步骤不是线性的。步骤三依赖步骤二的校验结果步骤五依赖步骤四的统计结果但步骤一和步骤二之间可能是强顺序而某些子任务之间可以并行。如果规划器只会输出一条直线遇到需要并行或需要回退的场景就会卡死。这里有个很多人忽略的点规划粒度。拆得太粗比如“处理数据”一步到位那执行器根本不知道从哪下手拆得太细比如把“打开文件”和“读取第一行”都当成独立步骤那规划开销会爆炸而且步骤之间的状态传递会变得极其繁琐。我的经验是一个步骤应该对应“一次有意义的工具调用或一次明确的判断”粒度控制在执行器一次能完成、且失败后能独立重试的范围内最合适。还有一个反直觉的结论规划不是一次性的而是滚动进行的。很多人以为 Agent 应该先规划好全部步骤再执行实际上在长任务里后面的步骤往往依赖前面步骤的真实结果提前规划太细反而会错。更稳的做法是“粗规划 动态细化”先出一个高层计划执行到某一步时再根据当前状态细化下一步。这也是后面要讲的状态管理和长任务恢复的基础。2. 状态管理Agent 的“记忆”为什么总是丢如果说任务规划是 Agent 的骨架那状态管理就是它的神经系统。我踩过最大的坑就是早期做 Agent 时把状态全塞进对话历史里结果任务一长模型就开始“失忆”前面确认过的参数后面又搞错已经完成的步骤又重新执行一遍。这不是模型笨是状态设计有问题。先明确一个概念Agent 的状态不等于对话历史。对话历史只是状态的一个来源而且是最不可靠的那个。真正需要被持久化、被结构化管理的状态至少包含以下几类任务状态当前处于哪个步骤、哪些步骤已完成、哪些在进行中、哪些失败了。数据状态中间产出的数据放在哪里是内存变量、临时文件还是数据库记录。环境状态当前可用的工具、权限、外部资源是否就绪。决策状态之前做过哪些关键判断依据是什么避免重复决策或前后矛盾。把这四类混在一起塞进 prompt是灾难的开始。因为 prompt 有长度限制而且模型对长上下文的注意力是衰减的越靠前的内容越容易被忽略。正确的做法是把状态外置用一个结构化的存储来管理每次只把当前步骤真正需要的那部分状态注入到模型上下文里。我通常会用类似下面这样的结构来组织任务状态{ task_id: task_20240101_001, goal: 分析CSV并生成异常订单报告, status: in_progress, current_step: 3, steps: [ {id: 1, name: 读取文件, status: done, output_ref: ctx.file_meta}, {id: 2, name: 字段校验, status: done, output_ref: ctx.validation}, {id: 3, name: 筛选异常, status: running, output_ref: null}, {id: 4, name: 聚合统计, status: pending, output_ref: null}, {id: 5, name: 生成报告, status: pending, output_ref: null} ], artifacts: { ctx.file_meta: {path: /tmp/upload.csv, rows: 1024}, ctx.validation: {missing_fields: [amount], bad_rows: 12} } }注意这里的output_ref它不直接存数据而是存一个引用。真正的数据放在 artifacts 里或者外部存储里。这样做的好处是状态本身很轻可以频繁读写和序列化而大数据不占用上下文。为什么状态要能序列化因为长任务恢复全靠它。想象一个任务跑了二十分钟中间调用了十几次工具突然进程崩了或者用户关掉了页面。如果没有持久化状态一切从头再来前面的工具调用全部白费。而如果状态是结构化的、可序列化的重启后只要加载状态就能从current_step继续往下走。这里有个实操心得状态写入要幂等且要在步骤边界写而不是步骤中间写。什么意思就是每完成一个步骤立刻把状态落盘但一个步骤执行到一半时不要写。因为步骤中间的状态是不完整的恢复时可能处于“做了一半”的尴尬境地反而更难处理。把步骤设计成“要么没开始要么已完成”恢复逻辑会简单很多。还有一个容易忽略的点状态的版本管理。当 Agent 的逻辑升级后旧的状态结构可能不兼容。我建议在状态里加一个schema_version字段加载时先做版本判断和迁移避免升级后老任务全部报错。这个坑我在一次迭代中踩得很惨几十个正在跑的长任务因为状态字段改名全部恢复失败。3. 长任务恢复断点续跑背后的完整机制长任务恢复是 Agent 从“玩具”走向“工具”的分水岭。短任务失败了重跑一遍无所谓但一个跑了半小时、调用了大量外部资源的任务如果失败就得从头来用户体验和成本都受不了。断点续跑不是简单地“记住进度”它涉及一套完整的机制设计。先说恢复要解决的核心问题如何判断一个任务该从哪里继续。这听起来简单实际上要考虑三种失败场景。第一种是进程崩溃状态还在直接加载即可第二种是工具调用超时或失败需要判断这个步骤是重试还是跳过第三种是外部状态已经改变比如文件被删了、数据源更新了这时候盲目续跑可能得到错误结果。针对这三种场景我的处理策略是这样的。对于进程崩溃靠持久化状态恢复这是最干净的。对于工具失败要在状态里记录每个步骤的重试次数和最后一次错误信息恢复时先看这个步骤是否可重试、重试次数是否超限。对于外部状态变化需要在恢复前做一次“前置校验”确认当前步骤依赖的输入是否还有效。具体到实现我一般会把恢复逻辑拆成几个明确的阶段加载状态从持久化存储读取任务状态校验 schema 版本。一致性检查确认已完成步骤的产出物是否还存在、是否被篡改。定位恢复点找到第一个未完成或失败的步骤作为恢复起点。重建上下文把恢复点之前所有步骤的产出引用重新组装成执行上下文。继续执行从恢复点开始按正常流程往下走。这里最关键的是第三步和第四步。定位恢复点不能只看current_step因为可能中间有步骤被标记为失败但实际已经产生了部分结果。更稳的做法是遍历所有步骤找到第一个状态不是done的步骤。而重建上下文时要注意只加载恢复点真正依赖的那些产出不要把全部历史都塞进去否则上下文又会爆炸。提示恢复点之前的步骤产出如果体积很大建议只加载摘要或引用真正需要全量数据时再按需读取。这样能显著降低恢复时的内存和上下文压力。还有一个高级技巧检查点Checkpoint与恢复点分离。检查点是定期保存的完整状态快照恢复点是实际继续执行的步骤位置。两者不一定重合。比如每完成三个步骤存一次检查点但恢复时可能从第五个步骤继续这时需要从最近的检查点第三个步骤开始重放第四、第五步的决策。这种设计在步骤执行成本低、但状态保存成本高的场景下特别有用。我实测下来长任务恢复最容易出问题的地方不是恢复逻辑本身而是副作用的重放。比如一个步骤是“发送通知邮件”如果恢复时这个步骤被判定为未完成而重新执行用户就会收到两封邮件。解决办法是给每个有副作用的步骤加一个幂等键Idempotency Key执行前先查这个键是否已经用过用过就直接返回上次的结果。这个机制在支付、通知、写库等场景里是必须的。4. 规划、状态、恢复三者的咬合关系单独看任务规划、状态管理、长任务恢复每个都能讲清楚。但真正决定 Agent 好不好用的是这三者能不能咬合在一起。我见过不少项目规划器写得很漂亮状态管理也做了但恢复时就是跑不起来问题往往出在接口没对齐。先说规划和状态的接口。规划器输出的步骤必须带上足够的状态描述让状态管理器知道每一步要存什么。比如一个步骤声明了output_ref: ctx.validation那状态管理器就要在执行完这个步骤后把结果写到这个引用下。如果规划器只输出“校验数据”四个字状态管理器根本不知道该存什么。所以规划器的输出格式必须是结构化的每个步骤都要有明确的输入引用和输出引用。再说状态和恢复的接口。恢复逻辑依赖状态里的步骤状态字段所以状态管理器在更新状态时必须严格遵循约定的状态机。我建议用一套固定的状态枚举比如pending、running、done、failed、skipped不要自己造词。状态流转也要有约束比如pending只能到runningrunning只能到done或failed不能从done回到running。这些约束看起来死板但能避免大量恢复时的边界问题。最后是规划和恢复的接口。恢复时规划器可能需要重新规划后续步骤因为前面的执行结果可能和预期不符。比如原计划第三步筛选异常订单结果发现数据里根本没有订单号字段这时候硬着头皮往下走只会得到垃圾结果。正确的做法是恢复时触发一次“重规划”根据当前状态调整后续步骤。这就要求规划器是可重入的能接受一个“当前状态”作为输入输出调整后的计划。把这三者串起来一个完整的长任务执行流程大致是这样的接收目标规划器生成初始计划状态管理器初始化任务状态。执行器按计划逐步执行每步开始前把状态置为running完成后置为done并写入产出。每完成一个步骤状态落盘形成检查点。如果中途失败恢复逻辑加载状态定位恢复点重建上下文。恢复时如果发现前置条件变化触发重规划更新后续步骤。从恢复点继续执行直到任务完成或达到终止条件。这个流程里任何一个环节的接口没对齐都会导致恢复失败。我的经验是在开发阶段就要把“模拟崩溃”当成常规测试用例每写完一个功能就手动杀进程再恢复一次看看能不能正确续跑。这个习惯能帮你提前发现大量接口问题。5. 面试高频追问与真实项目里的取舍聊到这里基本的概念和机制都清楚了。但面试里面试官往往不会只问你“什么是任务规划”而是会追问一些更刁钻的问题考察你有没有真正落地过。我整理了几个高频追问以及我在真实项目里的取舍思路。第一个高频问题规划器用大模型还是用规则引擎这其实不是二选一。纯规则引擎在固定流程里很稳但遇到开放目标就歇菜纯大模型灵活但输出不稳定可能今天拆成五步明天拆成八步。我的做法是混合用大模型做高层意图理解和粗规划用规则引擎做步骤的标准化和校验。比如大模型输出“分析数据”规则引擎把它映射成标准的“读取-校验-统计”三步模板。这样既有灵活性又有稳定性。第二个问题状态存哪里内存、文件还是数据库取决于任务时长和并发量。短任务、单机跑内存加定期落盘就够了长任务、需要跨进程恢复必须用持久化存储。我一般用轻量数据库存状态元数据用对象存储或文件系统存大体积产出。不要把所有东西都塞数据库大字段会拖慢状态读写。第三个问题恢复时怎么保证不重复执行副作用前面提过幂等键这里补充一点幂等键的生成要包含任务 ID、步骤 ID 和关键参数确保同一个逻辑操作在任何时候生成的键都一样。另外幂等记录本身也要持久化不能只放内存否则进程一崩就失效了。第四个问题长任务怎么设置超时和终止条件没有终止条件的 Agent 是危险的可能陷入死循环或者无限重试。我通常设三层保护单步骤超时、单任务总超时、最大重试次数。任何一层触发就终止任务并记录原因。终止不是失败而是可控的停止恢复时可以人工介入决定是否继续。第五个问题怎么评估规划质量这个很多人答不上来。我的评估维度有三个步骤覆盖率计划是否覆盖了目标的所有必要环节、步骤冗余度有没有重复或无用的步骤、恢复成功率失败后能否正确续跑。前两个可以离线用测试集评估第三个只能靠线上真实故障来验证。所以我建议在项目里埋点记录每次恢复的触发原因和结果积累一段时间后就能看出规划器的薄弱环节。真实项目里的取舍往往比面试题更残酷。比如为了降低复杂度我可能会放弃“完全动态重规划”改成“有限重规划”——只在特定类型的失败比如输入格式不符时触发重规划其他失败直接终止。这样牺牲了一部分灵活性但换来了可预测性和可维护性。在资源有限的情况下这种取舍是值得的。6. 一套可复现的最小实现思路讲了这么多原理和取舍最后给一套可以上手的最小实现思路。不追求生产级完备但能把规划、状态、恢复三个环节串起来适合用来练手或者作为项目起点。整体架构分四个模块规划器、执行器、状态存储、恢复器。规划器负责把目标拆成步骤列表执行器负责按步骤调用工具状态存储负责持久化恢复器负责加载状态并续跑。规划器的最小实现可以用一次大模型调用完成。给它一个系统提示要求输出 JSON 格式的步骤列表每个步骤包含id、name、tool、input_ref、output_ref。解析后用 schema 校验不合格就重试。这里要注意提示里必须明确要求输出纯 JSON不要带解释文字否则解析会失败。执行器的核心是一个循环读取当前步骤把该步骤需要的上下文组装好调用对应工具拿到结果后写入状态。工具可以用一个字典注册键是工具名值是函数。每个工具函数接收上下文返回结果和成功标志。状态存储最小实现可以用一个 JSON 文件。每次状态变更后整体写回。虽然效率不高但胜在简单可靠适合验证逻辑。等逻辑跑通了再换成数据库。恢复器的逻辑就是前面说的五步加载、校验、定位、重建、继续。定位恢复点时遍历步骤找第一个非done的。重建上下文时把恢复点之前所有done步骤的产出按output_ref组装成一个字典。下面是一个简化的执行循环伪代码帮你理解整体节奏def run_task(task_state, tools): while task_state.current_step len(task_state.steps): step task_state.steps[task_state.current_step] if step.status done: task_state.current_step 1 continue step.status running save_state(task_state) try: context build_context(task_state, step) result, ok tools[step.tool](context) if ok: task_state.artifacts[step.output_ref] result step.status done else: step.status failed step.retry_count 1 if step.retry_count MAX_RETRY: break except Exception as e: step.status failed step.last_error str(e) save_state(task_state) if step.status done: task_state.current_step 1 return task_state这段代码里save_state在每个步骤边界调用保证崩溃后能恢复。build_context只加载当前步骤需要的产出避免上下文膨胀。重试逻辑放在步骤级别超过上限就终止。实测下来这套最小实现能覆盖大部分单机长任务场景。真正上生产还需要补的东西包括并发控制、幂等键、状态版本迁移、监控埋点。但作为理解规划、状态、恢复三者关系的起点它足够用了。我在实际项目里最大的体会是不要一开始就追求完美的规划器。先把状态和恢复做扎实让任务能稳定跑完、失败能续跑再去优化规划的智能程度。因为一个规划一般但恢复可靠的 Agent比一个规划惊艳但一崩就全丢的 Agent有用得多。这个顺序如果搞反了后面会花大量时间在补状态管理的债。