AI

每天吃透一个 AI 知识点 —— 企业级 Agent 是如何做长任务规划的？

Posted Cola🌀

转载：小红书 AI产品赵哥

前言 🔖

面试 AI 应用方向的候选人时，我常用一道题区分人：Agent 处理长周期多步骤的复杂任务时，执行到一半容易迷糊，忘记最初目标，甚至擅自跳步或走偏。怎么设计任务规划模块来系统性解决这个问题？

大多数人的回答比较直接：

  • 优化 Prompt，加约束让它别乱跑；
  • 换更大的模型，比如 GPT‑4o，据说长上下文理解更好；
  • 把上下文窗口调到最大。

继续追问两个问题：

  • 完全依赖模型自身的规划能力，有哪些天然的、无法克服的缺陷？
  • 任务拆解、进度跟踪、动态重规划，这三个环节怎么协同形成闭环？

能说清楚完整方案的人不多。

这道题暴露了一个现实：很多开发者只是在靠调参和运气做 Agent，把成败寄托在模型状态上。

今天咱们来聊一聊，怎么通过三层架构，来约束模型在执行长任务时不跑偏！

　　

一、为什么不能完全信任大模型的自主规划？🔖

我们先提出问题：为什么一个拥有超强理解和推理能力的大模型，在执行长任务时，还是会像一匹脱缰的 “野马”，说跑偏就跑偏？

大模型自身有几个难以克服的问题：

  • 1．近期偏差
    • 处理长上下文时，虽然理论上能看到所有历史信息，但做决策时总是更关注最新的内容。任务执行到后半段，容易被新出现但不重要细节带跑，忘了最初的核心目标。
  • 2．贪心短视
    • 每一步都选当下看起来最合理或最容易执行的路径，缺乏全局战略眼光。很难为了长期更优目标忍受短期绕远路。
  • 3．意外处理能力弱
    • 真实任务充满意外：API 挂了、文件不存在、用户指令模糊。模型遇到训练数据里少见的情况，容易无效重复，或者直接选一个错误方向强行解释。

举个具体例子：

你让一个没有规划的 AI Agent 策划一个 “数字戒断” 主题露营活动：北京周边 3 小时车程内的安静营地，每天无电子产品活动，装备和食物清单。

它的执行过程可能是这样的：

  • 第一步：看到 “露营地”，立刻开始搜索北京周边露营地推荐
  • 第二步：浏览时看到一篇手冲咖啡帖子，觉得有意思，花半小时研究咖啡器具
  • 第三步：想起任务，开始设计活动，觉得篝火晚会需要音乐，又去搜吉他歌曲
  • 第四步：终于想起要列清单，但忘了 “数字戒断” 主题，清单里写了 “便携投影仪、蓝牙音箱、充电宝 x3”

整个过程就像一只被奶酪诱惑的小马，在死胡同里来回打转，离出口越来越远。

专业 Agent 系统不能靠模型自己自由发挥。需要工程化的规划机制来引导它走在正确方向上。

　　

二、三层规划架构：为你的 Agent 装上任务导航系统 🔖

一套稳定可靠的 Agent 任务规划体系，就像一个车载导航系统。它不仅能在出发前规划好最优路径，还能在行驶过程中实时提醒你，并在遇到堵车或修路时，动态地为你重新规划路线。

这个导航系统，由三层协同工作的机制构成：

  • 第一层：静态任务拆解。出发前的路径规划，将宏大目标分解为清晰的、有序的步骤。
  • 第二层：进度持续追踪。行驶中的实时导航，时刻对照最终目的地，防止走偏。
  • 第三层：动态重规划。遇到意外时的路线调整，灵活应对各种突发状况。

接下来，我们继续用 “数字戒断露营活动策划” 这个案例，来详细拆解这三层架构是如何运作的。

　　

🔹2.1 第一层：静态任务拆解

任务规划的第一步，也是最关键的一步：在 Agent 开始行动之前，先让它把用户模糊的目标进行一次结构化拆解。

【裸奔版 Agent】的做法

把 “策划 3 天露营活动” 这个整体需求直接丢给大模型，让它边想边干。结果就是前面看到的，行动毫无章法。

【专业版 Agent】的做法（静态任务拆解）

接收到初始需求后，不立刻执行，而是先调用一个专门的 “任务拆解模块”。这个模块本身也是一个 LLM，但 Prompt 经过特殊优化。它的职责只有一个：输出一个结构化的任务计划，通常是 JSON 或 YAML 格式。一个好的任务计划应该包含以下内容：

1   # "数字戒断露营活动" 任务规划 v1.0
2
3   # 最终目标 (Overall Goal):
4   # 生成一份完整的、为期3天的、以“数字戒断”为主题的北京周
5   # 包括营地选择、每日活动安排、以及详细的装备和食物清单。
6
7   # 任务分解 (Sub‑tasks):
8   - task_id: 1
9     name: "营地筛选与确定"
10    description: "根据用户要求（北京周边、3小时车程、安静
11    dependencies: [] # 没有依赖，这是第一步
12    output: "确定的营地名称、位置、和选择理由。"
13
14  - task_id: 2
15    name: "每日活动设计"
16    description: "围绕“数字戒断”主题，为3天的活动设计具
17    dependencies: [1] # 必须在确定营地后才能设计，因为活
18    output: "一份详细的每日活动时间表。"
19
20  - task_id: 3
21    name: "装备清单编制"
22    description: "根据已确定的活动（如徒步、过夜），列出‑
23    dependencies: [2] # 必须在确定活动后才能列出所需装备
24    output: "结构化的装备清单，分为“住宿”、“服装”、“工具’
25
26  - task_id: 4
27    name: "食物采购清单编制"
28    description: "规划3天6餐的菜单，并列出所有需要采购的‑
29    dependencies: [2] # 菜单与活动（如篝火烧烤）相关
30    output: "结构化的食物采购清单。"
31
32  - task_id: 5
33    name: "最终方案整合与输出"
34    description: "将前面所有步骤的产出，整合成一份格式精
35    dependencies: [1, 2, 3, 4] # 必须在所有部分都完成后
36    output: "一个最终的PDF文件。"
```

看到这个结构化的计划，Agent 的行动路径一下子就清晰了。它知道了：

  • 要做什么：5 个明确的子任务。
  • 按什么顺序做：通过 dependencies 字段，它知道了任务之间的先后关系。
  • 每一步要达成什么：通过 output 字段，它知道了每个子任务的交付标准。

💡静态任务拆解，就像在出发前，用导航软件规划好了全程的路线和经停点。它从源头上，杜绝了 Agent 的 “无序行动” 和 “随心所欲”。

　　

🔹2.2 第二层：进度持续追踪

制定计划只是开始。执行过程中，Agent 依然可能被其他信息带偏。

裸奔版 Agent 的行为：

执行 “营地筛选” 时，它看到某个营地边上有个 “烤全羊特别出名” 的农家菜馆。于是开始研究这家餐馆的历史、菜单、人均消费，甚至搜索 “如何在家烤美味的羊腿”…… 完全忘了当前核心任务是筛选营地。

专业版 Agent 的行为（进度持续追踪）：

在 “专业版” Agent 的系统中，我们引入了一个任务状态管理器。这个管理器，就像一个严厉的副驾驶，手里拿着我们第一步生成的 “任务计划书”。

它的工作机制是：

  • 维护一个任务状态列表：在任务开始时，它会把所有的子任务都标记为 PENDING（待处理）。
1  - task_id: 1, status: PENDING
2  - task_id: 2, status: PENDING
3  - ...
  • 执行前检查依赖：在执行任何一个子任务（比如 task_id: 2）之前，它会先检查其依赖项（dependencies: [1]）是否都已经完成（status: COMPLETED）。如果依赖项还没完成，它就绝不会启动当前任务。
  • 执行后对照目标：这是最关键的一步。当一个子任务（比如 task_id: 1）完成后，LLM 会生成一段总结性的文本和产出物。此时，任务状态管理器会把这段产出，连同最初的、全局的、最高阶的那个目标，以及当前子任务的目标，一起打包，再问 LLM 一个问题：
【内部校验 Prompt】

1  全局目标：策划一个“数字戒断”主题的露营活动。
2  当前子任务目标：筛选并确定一个安静的营地。
3  当前产出: [这里是 Agent 刚刚生成的关于营地的分析，可能其中混杂了关于“烤全羊”的内容]
4
5  请判断:
6  当前产出是否已经完成了“当前子任务目标”？(是/否)
7  当前产出中，是否存在与“全局目标”或“当前子任务目标”无关的、可以被忽略的“噪音信息”？如果存在，请指出来。

通过这个自我反思的步骤，LLM 很有可能会自己意识到：
“哦，关于烤全羊的信息，虽然很有趣，但它和筛选营地以及数字戒断这两个目标关系不大，属于噪音信息。”

  • 更新状态并推进：如果校验通过，管理器就会将 task_id: 1 的状态更新为 COMPLETED，然后从 PENDING 列表中，找出下一个可以执行的任务（task_id: 2），并启动它。

进度持续追踪，就像导航系统在行驶过程中，不断地把你的当前位置，和地图上的预设路线进行比对。一旦你偏离了航线，它会立刻发出 “您已偏离路线” 的警告，并引导你回到正轨。

　　

🔹2.3 第三层：动态重规划

实际执行中，工具可能调用失败，资料可能找不到，用户也可能中途变卦。Agent 需要有灵活调整的能力。

裸奔版 Agent 的行为：

执行 “营地筛选” 时，调用的营地评分 API 返回 500 错误。它只会反复调用这个 API，达到最大重试次数后就宣告任务失败。不知道还能怎么办。

专业版 Agent 的行为 (动态重规划)：

子任务失败时，不会直接宣告整个任务结束，而是触发 “异常处理与重规划” 模块。

这个模块会：

  1. 分析失败的原因：它会查看失败的日志。是网络超时？是 API 返回了 404 Not Found？还是因为权限问题？
  2. 评估失败的影响：这个失败的子任务，对整个任务计划有多大的影响？它是一个关键路径上的核心任务，还是一个可以被绕过的辅助任务？
  3. 生成备选方案：基于以上分析，它会向 LLM 提出一个新的、更具体的问题：
【重规划 Prompt】

1  当前计划: [原始的任务计划]
2  当前进度: [任务状态列表]
3  遇到的问题: 在执行 task_id: 1 ("营地筛选") 时，用于查询营地评分的 CampRatingAPI 工具连续 3 次调用失败，错误为 500 Internal Server Error。
4  请你作为一名项目经理，提出至少两种解决方案来应对这个意外，并评估它们的优劣。

此时，LLM 可能会给出这样的备选方案：

  • 方案 A (切换工具)：放弃使用 CampRatingAPI。改为使用通用的 web_search 工具，去搜索 “XX 营地 在小红书 / 大众点评上的评价”，然后通过自然语言处理，从搜索结果中提取用户评价的关键信息。
    • 优点：能获取到更真实的用户反馈。
    • 缺点：信息非结构化，处理起来更慢，结果可能不准。
  • 方案 B (调整任务顺序): 暂时跳过 “营地评分” 这个环节。先并行地去执行 task_2（活动设计）和 task_4（食物采购清单）这两个不依赖于具体营地的任务。同时，设置一个定时器，1 小时后再次尝试调用 CampRatingAPI。如果届时 API 仍不可用，再切换到方案 A。
    • 优点：最大化地利用了等待时间。
    • 缺点：如果 API 一直恢复不了，可能会延误整个项目。
  1. 决策与执行: 系统可以根据预设的策略（比如 “优先保证任务完成，而不是追求最高质量”）自动选择一个方案，或者将这些备选方案呈现给用户，由用户来做最终决策。一旦方案被选定，原始的任务计划图就会被动态地修改，然后 Agent 会按照新的计划继续执行。

动态重规划，就像导航系统在你遇到前方道路施工时，能立刻为你计算出一条新的、可以绕行的路线。

　　

三、来来来，总结一下，方便回查复习用 🔖

来回顾一下这套三层规划架构：

  • 第一层：静态任务拆解。行动前把模糊目标转化成清晰步骤，给整个任务画好地图。
  • 第二层：进度持续追踪。执行中对照全局目标和当前子任务，确保不跑偏。
  • 第三层：动态重规划。遇到意外时灵活评估、调整，找到新的出路。

回到开头那道面试题：

  • 初级开发者只会靠更长 Prompt、更强的模型，期望 Agent 自己规划好。这本质上是放任自由，充满不确定性。
  • 资深工程师会搭建事前拆解 + 事中追踪 + 事后重规划的三层架构，主动引导 Agent 的决策路径。这是工程化思维。