Agent 的 Planner 模块具体如何实现？

核心回答

Planner是把用户目标转成执行器能够消费、检查和更新的任务结构的模块。它可以先是一个独立函数或文件，复杂后再拆成包；文件数量不是重点，关键是说清输入、输出、何时调用，以及执行反馈如何修改计划。

我会把“生成计划”和“调度执行”分开：模型提出步骤，宿主校验依赖与约束，调度器选择当前可执行步骤，执行器返回结果，再决定继续或重规划。简单任务可以不单独调用Planner，避免计划本身比工作还重。

输入与输出怎样设计

输入包括用户目标、已确认约束、当前环境、可用能力目录、相关历史状态和预算。需要先探索仓库或查询事实的任务，可以先做有限的信息收集；不能让Planner在不知道项目现状时臆造接口和依赖。

输出至少包含计划版本、步骤ID、目标、依赖、预期产物和完成条件。按场景增加建议工具或执行角色、预计成本和不确定条件。步骤描述应能指导行动，例如“读取订单状态并记录退款资格判断所需字段”，比“分析问题”更具体。

线性步骤适合简单依赖，复杂任务可以用DAG表达并行关系；不是所有任务都需要图。尚未知道的信息可以作为探索步骤或条件分支，不用在首次规划时硬写完所有细节。

模块在什么地方调用

任务入口完成必要的身份、输入和上下文准备后调用初始规划；模型返回结构化候选，程序校验字段、工具是否存在、依赖是否引用有效步骤、是否存在不允许的循环，以及是否违背用户限制。

调度器取依赖已满足的步骤，将目标、必要证据和完成条件交给执行器。执行结果写回状态，分别标记进行中、成功、失败或阻塞，保存产物引用。子任务内部可以运行ReAct，Planner不必参与每一个工具调用。

当关键前提改变、步骤持续失败、出现新的必要任务或用户修改目标时，再调用重规划。新版本保留已验证结果，修改受影响的步骤和依赖，记录原因；普通工具超时可以局部重试，不一定重做全局计划。

如何组织代码与验证

一个初始实现可以分为计划数据结构、Planner调用与解析、计划校验、调度执行、反馈更新几个职责。规模小时放在少量模块即可，随着测试和多人维护需要再拆包，不必让Planner成为独立微服务。

例如生成研究报告，可规划成需求界定、分主题收集、证据核对和写作。若某主题资料不足，只补查对应部分；若用户改变研究对象，再调整相关主题与证据范围。

评估不仅看计划文字是否流畅，还看任务覆盖、步骤可执行性、依赖正确性、实际成功、重规划频率和总成本。技术亮点是把计划变成带状态和产物契约的执行数据，并通过反馈维护它。

对应教程

参考资料