智能体之间的规划、委派与任务路由

复杂 AI 系统可通过多个智能体协作来完成用户目标。本课探讨如何在多智能体团队中拆解规划任务、委派工作并路由请求——这些能力对于使用 LangGraph、ADK 等框架构建复杂购物助手尤为关键。本课涵盖以下核心内容：

多智能体系统中任务规划与路由的概念及实际作用。
由单一管理者统筹的集中式组织模式，以及由各智能体动态决定后续步骤的分布式路由模式。
如何将高层用户意图拆解为可委派的具体子任务。
如何设计路由逻辑、管理任务先后依赖，并定义失败回退处理方式。
不同路由策略在稳健性、复杂度与延迟上的取舍，以及规划与委派的工程实践建议。

完成本课后，应能够理解规划智能体如何选择任务执行路径，并为实现这些逻辑做好准备。

多智能体系统中的任务规划与路由

如果让单个智能体同时包揽商品搜索、评论分析、库存核查、购物车更新并维护不断增长的对话历史，随着系统规模扩大，往往会遭遇三类瓶颈：

工具数量过多：模型难以在恰当时机准确挑选出正确的工具。
上下文负担过重：搜索结果、商品详情与多轮对话混杂在一起，干扰模型生成切题回答。
专业能力难以兼顾：非结构化评论的情感归纳与结构化数据库更新所需的能力截然不同，单一通用智能体很难在所有子任务上都保持高水平。

将职责拆分给 Product QA、Cart Manager 等专业智能体各司其职，能够带来三方面改进：

模块化：各智能体可独立开发、测试与升级（例如优化 QA 智能体时可有效隔离对其他模块的影响）。
专业化：让一个智能体专注于电商检索，另一个专注于购物车事务操作，有助于提升整体任务表现。
受控交互：明确界定跨智能体的通信格式与交接边界，减少上下文混淆与非预期行为。

在拆分角色之后，如何高效协调各智能体的执行顺序与数据交接，正是任务规划（Task Planning）与路由委派（Routing & Delegation）所要解决的核心问题。

任务规划：从用户意图到操作计划

任务规划负责将高层的自然语言用户请求转化为可执行的操作序列，明确“要做什么、按什么顺序做、每一步交给谁做”。常见实现方式分为两类：

预定义固定计划（Pre-defined Plans）：由开发者针对已知任务类型预先编写确定性的步骤与条件分支，每一步固定调用指定的智能体或工具。
智能体动态规划（Dynamic Planning）：由基于 LLM 的规划智能体（Planner）根据当前用户提问实时生成执行计划并派发子任务，适合步骤无法预先写死的开放式任务，但整体可靠性取决于模型的规划能力。

在实际生产系统中，常将二者结合：高频明确的任务走固定流程，开放式复杂问题走动态规划，从而确保关键前置依赖（如先确认商品及库存、再加入购物车）按合理顺序执行。

将用户意图拆解为子任务

任务拆解需要将复合意图转化为粒度适中、可直接执行的子任务。例如，面对用户请求“把 200 美元以下评分最高的耳机加入购物车”，可拆解为以下六个步骤：

理解请求：识别目标品类为“耳机”、筛选条件为“评分最高”且“价格低于 200 美元”、最终目标动作为“加入购物车”。
搜索和筛选商品：按品类与价格上限检索符合条件的候选商品列表。
分析评论或评分：明确“评分最高”的判定口径（通常指候选商品中平均星级最高或评论口碑最好的一项），拉取评分或分析评论内容以锁定最优商品。
检查库存：核实锁定的目标商品当前是否有可售库存。
加入购物车：确认有货后，调用购物车系统执行加购操作。
返回确认：向用户反馈加购成功详情，或说明未能加购的原因。

上述每个子任务均可委派给不同的智能体或函数：既可以由 Product Finder 一并完成搜索与排序，也可以拆分为 Search Agent 与 Review Analyzer 分别负责；库存核查交由 Inventory Agent，加购交由 Cart Manager；首步意图理解可由顶层 Orchestrator（或在输入格式固定时用正则表达式/分类器）完成，最终确认则由管理者或购物车智能体统一生成。

在工程上，识别并生成子任务计划主要有三种方法：

基于规则解析：针对近似命令式的输入编写规则或正则表达式（例如匹配到“加入购物车”即触发 Cart Agent，匹配到“200 美元”即提取价格过滤条件）。
基于 LLM 的结构化规划：提示模型解析用户请求并输出包含执行步骤与负责智能体的 JSON 计划（如提示：“根据用户请求，列出完成任务的步骤，以及每一步负责的智能体或工具”）：

[
  {"action": "search_products", "criteria": "headphones under $200", "agent": "ProductSearchAgent"},
  {"action": "find_top_rated", "criteria": "highest review score", "agent": "ReviewAnalysisAgent"},
  {"action": "check_inventory", "product": "<ID from previous step>", "agent": "InventoryAgent"},
  {"action": "add_to_cart", "product": "<ID>", "agent": "CartAgent"}
]

系统随后即可按该 JSON 数组顺序依次调度执行。

参数化工作流模板：预先定义带占位符的标准流程模板（例如“加购标准流程”固定依次执行 Search → Analyze → Inventory → Cart），由智能体从用户输入中提取“200 美元以下的耳机”等参数填入模板，兼顾结构稳定性与参数灵活性。

计划需要覆盖全部必要步骤，并尊重逻辑顺序及依赖。遗漏库存检查，或在确定商品前尝试添加，都可能导致失败。确定计划后，还需要选择任务如何在智能体之间执行。

集中式与分布式任务路由

生成子任务计划后，需要决定如何在智能体之间调度执行，主要分为集中式组织与分布式路由两种模式：

1. 集中式组织：Manager / Supervisor 模式

由单一的中央管理者（Manager / Supervisor / Orchestrator，既可以是配置了专用提示词的 LLM，也可以是确定性的控制代码）统一掌控路由决策：管理者每次选定下一步、调用对应子智能体、接收返回结果，再决定后续动作；各子智能体互不直接通信，统一向管理者汇报。

运行方式：管理者选择下一步，调用子智能体，接收结果，再决定后续步骤。子智能体通常向管理者报告，由管理者组织后续调用。

仍以“把 200 美元以下评分最高的耳机加入购物车”为例，ShoppingOrchestrator 的协调过程如下：

解析用户请求，提取“耳机”品类与“< 200 美元”价格限制。
委派 Product QA 检索符合价格条件的耳机。
接收返回的候选耳机列表（含价格与评分）。
委派 Review Analysis 从列表中选出评分最高的商品（或由管理者直接调用排序工具完成）。
接收选出的最优商品（如五星好评的 Product X）。
委派 Inventory Agent 检查 Product X 的库存状态。
收到“有现货”确认。
委派 Cart Agent 将 Product X 加入购物车。
由管理者自身（或委派 Dialogue Agent）向用户生成最终确认回复。

在整个过程中，管理者集中维护任务进度；一旦某一步受阻（如 Product X 缺货），管理者可立即决定退而求其次检查第二名候选商品，或主动询问用户是否更换款式。

优势：

全局逻辑清晰：单一管理者掌握完整计划，执行轨迹一目了然。
易于集中管控：便于统一实施业务规则、在异常时暂停流程、调整全局优先级或插入人工审批节点（HITL）。
行为可预测性强：当遵循固定脚本或结构化计划时，流程易于复现与回归测试。

限制：

单点故障与性能瓶颈：若管理者自身推理混淆或决策出错，将波及整条链路；所有步骤均需等待中央节点调度，也可能形成吞吐瓶颈。
灵活性有限：固定脚本可能难以处理新请求，具有推理能力的 LLM 管理者可以改善适应能力。
并行度受限：若管理者采用简单的串行一问一答调度，容易错失独立子任务的并行执行机会（需专门编写并行派发与汇聚等待逻辑）。

2. 分布式路由：智能体自主决定交接（Handoff）

在分布式路由中，不设唯一的中央调度器，而是由当前执行任务的智能体根据局部状态自主决定下一步交接给谁，常见形式包括：

全分布式网络：智能体可以按需相互通信，完成自身任务后依据当前状态决定调用谁。
基于角色的协作讨论：多个智能体围绕共享目标各自贡献信息（如一个提议搜索条件、一个执行检索、第三个补充评论分析），通过多轮交互共同推进任务。

每个智能体需要了解整体目标，或至少知道何时交接控制。完成自身工作或无法独立完成时，可以输出指示下一步的命令或消息，例如 "next_agent": "ReviewAgent"，并附上需要传递的数据。路由由运行时结果或分析决定。

在购物助手场景下，请求可先进入通用的 ShoppingAssistant，识别出查商品需求后交接给 Product QA；Product QA 完成价格过滤后直接调用 Review Analyzer 挑选最高评分商品；评论智能体选出最优商品后，识别到用户最初意图还包含“加入购物车”，便直接将控制权与商品 ID 交接给 Cart Agent；加购完成后由 Cart Agent 直接结束流程并向前端返回确认（若某一步无法判断下一棒交给谁，则回退给默认接收者或主助手）。

优势：

动态适应力强：可在执行中途灵活应对需求变化或突发支线问题。
并行机会：多个智能体可以同时处理不同方面。
天然支持并行与去中心化容错：无需所有操作都绕经单一控制点，某个节点受阻时可由相邻节点尝试替代路径。
形成新的解决路径：智能体可能提出开发者没有预先规定的方法，尤其适合研究和创造性任务。

限制：

协调复杂：可能重复工作或遗漏步骤，因此每个智能体需要明确目标和边界。
路径不确定性增加排障难度：相同输入在不同运行中可能走过不同交接路径；评估时需以最终结果为主，同时结合轨迹合理性审查，而不能仅靠固定步骤序列断言。
Token 与延迟开销大：每一次局部交接决策若均调用 LLM，会显著增加调用次数、延迟与成本。
相互等待或重复循环：缺少终止条件时，A 调用 B、B 再调用 A，可能不断重复；也可能各自等待对方操作。

因此，工程实践中常采用混合路由架构：在顶层采用集中式规划把控主干流程，在局部子团队内部允许智能体直接交接，或在大体固定的图流程中仅开放少量由 LLM 动态决定的条件分支。

设计有效的智能体工作流程

工作流程需要明确各智能体负责什么、何时执行，以及如何传递信息。

1. 路由逻辑的实现方式

路由逻辑是决定下一步的条件规则或策略，可以通过代码、提示或两者结合实现。

规则路由（Rule-based Routing）：通过确定性代码直接规定流转条件（例如购物车操作一律进 Cart Agent、常规咨询进 QA Agent；检索结果非空则进评论分析，为空则触发澄清提问）。在 LangGraph 中可通过 add_conditional_edges 编写读取状态并返回目标节点名的路由函数。
LLM 动态路由（LLM-based Routing）：向 Planner 模型提供可用智能体列表及其功能描述，由模型根据当前状态选定下一个智能体并组装输入参数。为防止模型捏造不存在的智能体名称，必须将可选名称限制在固定枚举范围内，并要求输出结构化的 Command 或包含 target_agent 字段的 JSON。
混合路由（Hybrid Routing）：宏观阶段切换用确定性规则保障主干稳定，局部细分支选择交由 LLM 判断（例如商品查找固定先走 QA 节点，拿到候选列表后再由 LLM 决定是走参数对比分支还是评论情感分析分支）。

规划智能体可以在提示中表达路由策略，例如要求“列出所需步骤及负责智能体，再按顺序执行”。其输出和后续判断决定任务如何分配。

需要注意，每一个共享控制点在同一时刻都必须有且仅有一个明确的决策负责人——若 QAAgent 与 ReviewAgent 同时尝试决定下一步走向，就会引发状态冲突，需通过图结构或状态中的控制权标记予以约束。

2. 任务依赖、数据传递与异常处理

串行依赖与并行汇聚：必须在确认商品信息后才能执行加购、拿到搜索结果后才能分析评论（串行依赖）；而当用户要求“对比 200 美元以下评分最高的耳机与 300 美元以下评分最高的音箱”或“同时检查两款商品库存”时，两路检索互不依赖，可并行发起并在汇合节点（Join Node）同步等待两路完成后再合并比较。

顺序与并行：并行能够减少延迟，但需要合并结果。购物示例大部分步骤有顺序依赖；同时检查两个商品库存等独立任务则适合并行。应设置同步和结果收集机制，例如等待双方完成的汇合节点。
跨智能体数据传递：可通过共享状态（如 LangGraph 的 StateGraph，由 QA 将商品列表写入 state["products"]，再由 Review 读取）或显式调用参数传递数据。上下游之间必须约定严格的数据接口格式（如统一的 JSON Schema）。
错误与回退循环：当未检索到符合价格上限的商品时，返回明确的空结果标记，由管理者告知用户或请求放宽条件；当首选高分商品无库存时，管理者可按序遍历候选列表尝试第二名商品，但任何回退重试循环都必须设置明确的最大尝试次数上限。
循环改进：首次候选无库存时，可以继续尝试第二名。管理者可以遍历列表，也可以允许智能体重复调用自身或其他智能体，但必须规定退出条件或次数限制。

3. 委派与工作流设计的工程建议

智能体生态仍在发展，委派流程需要结合任务特点设计。以下经验有助于提高可靠性。

明确委派边界与验收标准：下发给子智能体的指令应具体明确（例如下发“查找低于 200 美元的耳机并按用户评分降序排列”，而不要只笼统下发“找耳机”；让 Review Analysis 仅负责在已给定的候选列表中挑选最高分，不再重复执行价格过滤）。
减少重复工作：通过以下方法管理协作。
- 复用共享状态：将已拉取的商品详情存入共享状态或缓存变量供下游直接读取。
- 明确数据与职责负责人：多个智能体同时承担相同查询时，需要重新明确各自范围。
- 交接前先做摘要收敛：若初检召回了大量结果，先筛选或归纳出前 5 项核心候选再往下游传递，减轻后续智能体的上下文负担。
- 显式标记完成状态：通过 state["review_done"] = True 等状态位或共享记事板（Blackboard）记录已完成的动作，防止同一批评论被反复分析。
共享记忆或记事板：允许各智能体记录已经完成的工作和发现，并查看其他成员的信息，减少重复并提供整体背景。StateGraph 可以承担结构化共享记忆的作用；字段名称和格式需要明确约定。
保持角色职责单一内聚：若发现两个智能体经常越界代劳对方的工作，说明职责划分不清；反之，若智能体 A 每次执行完都无条件固定调用智能体 B，则应考虑将二者合并为同一个智能体或固定步骤。
停止条件与超时：集中式管理者应知道最终步骤何时完成；分布式系统可以指定最终回答者或在不再交接时结束。还应设置合理的最大步骤数或收敛检查，防止不断尝试而无法停止。
日志与可观测性：记录每次委派及结果，包括负责智能体、输入和输出。这既有助于调试，也能评估执行过程是否合理。

这些做法能够使复杂交互更便于管理，并提高稳健性。

路由策略取决于具体任务。购物助手可以通过中央管理者或明确的图流程保证常见任务的可靠性，实践部分也适合采用这种方式。更分布式的设计可以提高灵活性，但需要充分的提示工程和测试。在电商等错误可能造成订单损失或客户不满的场景中，应重视可靠、可预测的执行流程。

委派任务时保留身份与资料范围

任务消息保存 request_id、tenant、user、source_scope、corpus_version、deadline 和幂等键。被委派的服务重新认证调用方并检查权限，不直接信任任务文字中的身份。比较串行与并行读取的耗时，并限制同一飞书应用总请求速率。

练习：记录本课所用配置、输入、预期结果与失败分支，并用脱敏数据复现。