复杂 AI 系统可以让多个智能体协作完成用户目标。本课关注如何规划任务、委派工作，以及在团队中分配请求。这些能力对于使用 LangGraph、ADK 等框架构建购物助手很重要。本课将讨论以下内容。
- 多智能体系统中任务规划和路由的含义及实际作用。
- 由单个管理者协调任务的集中式组织方式，以及由各智能体动态选择后续步骤的分布式路由。
- 将高层用户意图划分为可以委派的子任务。
- 设计路由逻辑、管理任务依赖，并定义失败后的处理方式。
- 不同路由策略在稳健性、复杂度和延迟等方面的取舍，以及规划和委派的实践建议。
完成本课后，应能够理解规划智能体如何选择任务执行路径，并为实现这些逻辑做好准备。
多智能体系统中的任务规划与路由
单个智能体同时搜索商品、分析评论、检查库存、更新购物车，并维护不断增长的对话，可能难以维护。系统规模扩大后，通常会遇到以下问题。
- 工具过多：难以在适当时间选择正确工具。
- 上下文负担过重：搜索结果、商品资料和对话混合后，模型较难生成切题回答。
- 专业能力不足：评论解析与数据库更新需要不同能力，通用智能体可能无法在每类任务上都表现良好。
让 Product QA、Cart Manager 等专门智能体各司其职，可以带来以下改进。
- 模块化：便于开发、测试和维护，例如更新 QA 智能体时控制对其他部分的影响。
- 专业化：一个智能体专注电商搜索，另一个处理购物车操作，提高整体效果。
- 受控交互：明确通信和任务交接方式，减少混淆及非预期行为。
规划和路由有助于扩展系统能力，同时需要有效协调各智能体，这正是任务规划与委派要解决的问题。
任务规划：从用户意图到操作计划
任务规划将高层请求转换为可执行步骤，确定需要完成什么、执行顺序以及负责者。主要有两种方法。
- 预先定义的计划：开发者为已知任务类型规定步骤和条件分支，每一步调用指定智能体或工具。
- 智能体动态规划：规划智能体通常使用 LLM，根据用户查询形成计划，再委派子任务。它适合步骤无法提前确定的开放任务，但效果取决于规划能力。
生产系统常结合两者：明确的任务使用固定流程，开放问题使用动态规划。清楚的计划可以保证顺序合理，例如确定商品后才能加入购物车，并在适当时刻使用各专家智能体。
将用户意图划分为子任务
任务划分需要形成规模较小、可以执行的部分。例如，“把 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"}
]系统可以按照该计划依次执行。
- 工作流程模板：定义含占位参数的任务模板，例如加入购物车流程依次包含 Search、Analyze、Inventory 和 Cart，由智能体将“200 美元以下的耳机”等具体条件填入。固定结构与动态内容由此结合。
计划需要覆盖全部必要步骤，并尊重逻辑顺序及依赖。遗漏库存检查，或在确定商品前尝试添加，都可能导致失败。确定计划后，还需要选择任务如何在智能体之间执行。
集中式与分布式任务路由
得到子任务后，需要决定负责者和执行顺序。集中式组织与分布式路由是两种主要方式，实际系统常结合两者。
集中式组织：Manager 或 Supervisor 模式
集中式方式由 manager、supervisor 或 orchestrator 统一决定路由。它接收用户请求，形成子任务，并按适当顺序分配给对应智能体。管理者可以是具有专门提示的 LLM，也可以是按规则执行的代码。
运行方式：管理者选择下一步，调用子智能体，接收结果，再决定后续步骤。子智能体通常向管理者报告，由管理者组织后续调用。
例如，ShoppingOrchestrator 收到“把 200 美元以下评分最高的耳机加入购物车”后，可以执行以下步骤。
- 解析请求，识别耳机类别和价格限制。
- 委派 Product QA 搜索符合价格要求的商品。
- 接收包含价格和评分的耳机列表。
- 让 Review Analysis 从结果中选择评分最高的商品，或自行通过工具完成。
- 接收最佳候选，例如五星商品 Product X。
- 让 Inventory Agent 检查 Product X 库存。
- 接收有库存的确认。
- 让 Cart Agent 将 Product X 加入购物车。
- 自行生成确认信息，或交给 Dialogue Agent。
管理者始终记录已完成内容和后续步骤。任何一步失败时，例如商品无库存，它可以选择下一件商品，或询问用户是否更换。
集中式方式的优势：
- 逻辑清楚：一个管理者掌握整体计划，执行记录便于追踪工作流程。
- 便于控制：可以实施业务规则、发生错误时暂停，并进行全局优先级判断。也便于插入人工批准。
- 执行可预测：计划大体固定或管理者按脚本执行时，流程便于重复测试，有助于可靠性。
集中式方式的限制：
- 单点故障：管理者混淆或决策错误可能影响整个流程，所有步骤等待其决策也可能形成性能瓶颈。
- 灵活性有限：固定脚本可能难以处理新请求，具有推理能力的 LLM 管理者可以改善适应能力。
- 并行机会受限：严格顺序执行可能错过独立任务的并行机会。管理者仍可并行委派并等待结果，但需要专门设计相关逻辑。
分布式路由：智能体自主决定后续操作
分布式路由由智能体根据局部情况决定下一步，或向其他智能体求助。常见形式包括以下两种。
- 全分布式网络：智能体可以按需相互通信，完成自身任务后依据当前状态决定调用谁。
- 基于角色的讨论：智能体根据各自角色贡献信息，共同形成计划。例如，一个提出搜索商品，另一个执行搜索，第三个补充分析，通过讨论组织任务。
每个智能体需要了解整体目标，或至少知道何时交接控制。完成自身工作或无法独立完成时，可以输出指示下一步的命令或消息，例如 "next_agent": "ReviewAgent"，并附上需要传递的数据。路由由运行时结果或分析决定。
例如，用户请求首先进入通用 ShoppingAssistant。它识别需要寻找商品并加入购物车，将搜索交给 Product QA。Product QA 完成价格筛选后，可以直接选择最高评分，也可以调用 Review Analyzer 再次检查。评论智能体返回最佳商品后，当前智能体识别仍需加入购物车，于是调用 Cart Agent。添加成功后，Cart Agent 可以结束交互，或向界面返回确认。某一步无法判断后续操作时，可以调用默认接收者，或返回主要助手。
分布式路由的优势：
- 适应能力：需求在执行中变化或出现新问题时，可以动态处理。
- 并行机会：多个智能体可以同时处理不同方面。
- 减少中央瓶颈：各操作不必都经过一个控制者；某个智能体失败时，可以尝试其他路径或由其他智能体接手。
- 形成新的解决路径：智能体可能提出开发者没有预先规定的方法，尤其适合研究和创造性任务。
分布式路由的限制：
- 协调复杂：可能重复工作或遗漏步骤，因此每个智能体需要明确目标和边界。
- 执行路径不确定：相同输入可能经过不同步骤，使调试更难。评估应重视结果，同时检查过程是否合理，不能仅要求固定步骤序列。
- 资源开销较高：每个小决策都调用 LLM，会增加 token、API 调用、延迟和成本。
- 相互等待或重复循环：缺少终止条件时，A 调用 B、B 再调用 A，可能不断重复；也可能各自等待对方操作。
实际系统常采用混合方式，例如顶层集中规划，子智能体之间自行处理部分具体交互，或在大体固定的流程中设置少量由 LLM 决定的分支。
设计有效的智能体工作流程
工作流程需要明确各智能体负责什么、何时执行，以及如何传递信息。
路由逻辑与决策
路由逻辑是决定下一步的条件规则或策略，可以通过代码、提示或两者结合实现。
- 规则路由：直接规定条件。例如，购物车操作交给 Cart Agent，一般问题交给 QA Agent；找到商品后进入评论分析，没有结果则请求澄清或提供其他选项。在 LangGraph 中可以使用
add_conditional_edges，由路由函数读取状态并返回下一节点。也可以检查智能体输出，再决定交接对象。 - LLM 路由：Planner 根据状态选择下一智能体，例如决定将搜索结果交给 ReviewAgent。提供可用智能体及功能说明后，模型选择对象并生成输入。这种方式灵活，支持修改计划和循环，但必须限制可选名称，减少编造不存在工具的情况。可以要求输出
Command或含target_agent字段的 JSON，以便可靠解析。 - 混合路由：高层采用规则，具体步骤由模型决定。例如，商品查找始终先进入 QA，获得结果后再由 LLM 选择筛选或分析智能体。
规划智能体可以在提示中表达路由策略，例如要求“列出所需步骤及负责智能体，再按顺序执行”。其输出和后续判断决定任务如何分配。
每个共享控制点应有明确的决策负责人，其他智能体等待或执行已经分配的工作。如果 QAAgent 和 ReviewAgent 同时决定不同后续步骤，可能产生冲突。可以通过程序结构或共享状态记录当前控制权。
任务依赖与执行顺序
规划需要识别依赖。例如，获得商品信息后才能加入购物车，拿到搜索结果后再分析评论。独立任务可以并行：比较“200 美元以下评分最高的耳机”和“300 美元以下评分最高的扬声器”时，可以同时搜索两类商品，再汇集比较。
- 顺序与并行：并行能够减少延迟，但需要合并结果。购物示例大部分步骤有顺序依赖；同时检查两个商品库存等独立任务则适合并行。应设置同步和结果收集机制，例如等待双方完成的汇合节点。
- 传递数据：智能体可以通过共享状态或明确参数交换信息。LangGraph 的
StateGraph可以维护共享状态：QA 将商品列表放入state["products"]，Review 再读取。输出必须符合下一智能体预期的格式，例如约定 JSON schema 或文本结构。 - 错误处理：搜索没有找到符合价格要求的商品时，可以返回明确标记，由管理者选择告知用户或请求其他条件。商品无库存时，可以尝试次优候选，询问是否预订缺货商品，或选择其他商品。
- 循环改进：首次候选无库存时，可以继续尝试第二名。管理者可以遍历列表，也可以允许智能体重复调用自身或其他智能体，但必须规定退出条件或次数限制。
委派与工作流程设计的实践建议
智能体生态仍在发展，委派流程需要结合任务特点设计。以下经验有助于提高可靠性。
- 明确任务边界：委派时说明任务内容和成功标准。例如，要求“查找低于 200 美元的耳机，按用户评分降序排列”，比笼统要求找耳机更明确。Review Analysis 可以只负责从给定商品列表中识别最高评分，无需重新搜索或处理已完成的价格筛选。由 LLM 生成任务时，也应要求每项任务包含这些具体信息。
- 减少重复工作：通过以下方法管理协作。
- 共享状态：QA 已获取的商品资料应传给 Review，或保存在共同数据库、向量存储及上下文变量中，以便复用。
- 明确数据与职责负责人：多个智能体同时承担相同查询时，需要重新明确各自范围。
- 归纳后交接：大量搜索结果可以先筛选，例如只传递前五项候选，降低后续智能体处理负担。
- 避免无效重复：相同评论已经分析过时，不应再次执行同一工作。可以由规划者管理，或通过
state["review_done"] = True等状态标记完成情况。
- 共享记忆或记事板：允许各智能体记录已经完成的工作和发现，并查看其他成员的信息，减少重复并提供整体背景。
StateGraph可以承担结构化共享记忆的作用；字段名称和格式需要明确约定。 - 保持职责集中：每个角色尽可能具有单一职责。商品 QA 和评论分析若经常互相承担对方任务，可能意味着边界不清。清楚划分有助于替换实现或单独升级。如果 A 每次执行后立即调用 B，也应考虑两者是否适合合并为一个智能体或步骤。
- 停止条件与超时：集中式管理者应知道最终步骤何时完成；分布式系统可以指定最终回答者或在不再交接时结束。还应设置合理的最大步骤数或收敛检查，防止不断尝试而无法停止。
- 日志与可观测性：记录每次委派及结果，包括负责智能体、输入和输出。这既有助于调试，也能评估执行过程是否合理。
这些做法能够使复杂交互更便于管理，并提高稳健性。
路由策略取决于具体任务。购物助手可以通过中央管理者或明确的图流程保证常见任务的可靠性，实践部分也适合采用这种方式。更分布式的设计可以提高灵活性，但需要充分的提示工程和测试。在电商等错误可能造成订单损失或客户不满的场景中，应重视可靠、可预测的执行流程。