长任务规划是 AI 代理从 "聊天工具" 向 "自主工作者" 演进的核心能力。研究表明，AI 代理的任务完成时长每 7 个月翻一倍，但任务时长每翻倍，失败率将增加 4 倍 —— 这种非线性关系使得长任务规划成为代理系统设计的核心挑战。本文从工程实践角度，剖析如何从零构建具备状态机管理、子目标分解与错误恢复能力的长任务规划模块。
长任务规划的结构性挑战
当前大语言模型在处理长周期任务时面临三个根本性约束。首先是上下文窗口的硬性限制：即使 200K token 的上下文窗口，在数小时甚至数天的任务执行中仍会被填满，导致关键信息 "迷失在上下文中"。其次是性能衰减曲线：数据显示，每个 AI 代理在执行约 35 分钟后都会出现性能下降，注意力随上下文填充而衰减。第三是错误级联效应：早期的小错误会在长任务中累积放大，最终偏离原始目标。
这些约束决定了长任务规划模块必须采用 "分而治之" 的架构策略 —— 将宏观任务分解为可在有效时间窗口内完成的子目标，并通过状态机管理执行流程。
Planner-Executor 分离架构
Plan-and-Act 框架提出了将高层规划与低层执行分离的双模块架构。Planner 负责将用户目标分解为结构化的高层计划，Executor 则将这些计划转换为环境特定的具体动作。这种分离使每个组件专注于核心职责：Planner 进行战略推理而不被实现细节困扰，Executor 专注于将抽象计划落地为可执行动作。
在 WebArena-Lite 基准测试中，这种分离架构配合动态重规划机制达到了 57.58% 的成功率，显著优于单模型端到端方案。关键设计要点包括：
Planner 的输出格式：每个规划步骤应包含推理过程 (Reasoning) 和具体步骤 (Step) 两部分。推理过程解释该步骤的战略意图，步骤描述则明确可衡量的完成标准。例如，"搜索 CMU 附近图书馆" 应细化为 "在搜索框输入 'Library near CMU' 并执行搜索"。
Executor 的动作空间：Executor 接收 Planner 生成的高层计划，结合当前环境状态输出具体动作。动作应包含元素定位信息 (如 HTML 元素 ID) 和操作类型 (点击、输入、选择等)，确保可执行性。
成本优化策略：Planner-Worker 模式可实现高达 90% 的成本降低 —— 使用能力更强的模型 (如 GPT-4o) 进行一次性规划，使用成本更低的模型执行重复性任务。
状态机驱动的子目标管理
状态机是管理长任务执行流程的可靠抽象。外层状态机定义任务的主要阶段及其转换规则，内层则在每个状态下处理具体的子目标。
典型状态设计：
Init → Plan → Execute-Phase-N → Validate-Phase-N → [Replan|Next-Phase|Completed]
每个状态具有明确的进入条件和退出标准。例如，"Execute-Phase-N" 状态的退出条件可能是 "子目标完成" 或 "执行失败超过重试阈值"。
子目标分解原则：
- 原子性：每个子目标应在 35 分钟的有效性能窗口内可完成
- 可验证性：每个子目标必须有明确的完成判定标准
- 独立性：子目标之间应尽量减少状态依赖，降低错误传播风险
- 可回滚性：关键子目标执行前应创建检查点，支持失败回滚
层次化分解：复杂任务可采用树状结构递归分解。根节点为最终目标，中间节点为阶段性里程碑，叶子节点为可在单会话中完成的原子任务。这种结构支持并行执行独立子树，提升整体效率。
动态重规划机制
静态计划的根本局限在于无法应对执行过程中的环境变化。动态重规划机制要求 Planner 在每个 Executor 动作完成后重新评估当前状态，并生成更新的计划。
重规划触发条件：
- 执行动作返回意外结果 (如搜索无结果)
- 环境状态发生显著变化
- 当前子目标执行失败
- 发现新的信息需要调整后续策略
重规划的实现：Planner 接收当前状态、历史动作轨迹和先前计划，生成反映最新情况的修订计划。例如，当搜索 "Library at CMU" 返回无结果时，Planner 应调整策略为搜索 "Library near CMU"。
上下文管理：动态重规划需要维护跨步骤的关键信息。Plan-and-Act 框架通过将执行过程中获得的信息 (如 "已识别到顶级贡献者") 注入后续计划，实现了无需显式记忆模块的长程上下文保持。
错误恢复与检查点机制
长任务执行中的错误不可避免，关键在于建立可靠的恢复机制。
检查点策略：
- 定期快照：每 N 分钟或每完成一个里程碑后自动保存代理状态
- 状态包含内容：当前高层目标、子目标列表、已完成步骤、关键环境状态、决策日志
- 存储方式：使用 PostgreSQL、Redis 或文件系统实现持久化存储
恢复流程：
当检测到失败或需要重启时，系统从最近的检查点加载状态，重建执行上下文，从断点继续执行而非从头开始。这种机制使代理能够 survive 进程重启、部署更新或超时中断。
Git 集成恢复：对于代码生成类任务，将检查点与 Git 提交结合可提供额外的安全保障。每个里程碑完成后自动提交，失败时可通过git diff快速定位问题，必要时回滚到上一个良好状态。
分层验证：建立多层验证防线 —— 语法检查确保输出格式正确，LLM 评估验证语义正确性，人工审核在关键节点进行最终把关。
可落地的参数与监控
关键配置参数：
| 参数 | 推荐值 | 说明 |
|---|---|---|
| 单会话最大时长 | 30 分钟 | 在 35 分钟性能下降前完成 |
| 检查点间隔 | 5 分钟或每里程碑 | 平衡恢复效率与存储开销 |
| 子目标重试次数 | 3 次 | 避免无限循环 |
| 重试退避策略 | 指数退避 (1s, 2s, 4s) | 减少瞬时故障影响 |
| 上下文压缩阈值 | 80% 上下文窗口 | 触发摘要或清理 |
监控指标：
- 任务完成率：目标≥90%，按任务类型分别统计
- 单步成功率：监控各状态转换的成功率，识别薄弱环节
- 平均重规划次数：反映环境动态性，过高可能提示计划质量不足
- 检查点恢复频率：评估系统稳定性
- Token 消耗：每任务、每子目标的成本归因
告警规则：
- 单任务重规划次数超过阈值 (如 10 次) 触发人工介入
- Token 消耗异常增长触发成本告警
- 连续子目标失败触发降级策略
局限与权衡
动态重规划虽然提升了鲁棒性，但每步都重新生成计划会带来执行效率损失。生产环境中可考虑优化策略：仅在检测到异常或进入新阶段时触发重规划，而非每个动作后都执行。
此外，当前合成数据生成方法依赖于基线模型能够成功完成任务。对于缺乏训练数据的领域，需要先构建基础能力才能启动数据飞轮。
资料来源
- Plan-and-Act: Improving Planning of Agents for Long-Horizon Tasks (arXiv:2503.09572)
- Zylos Research: Long-Running AI Agents and Task Decomposition 2026
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。