多智能体自主规划模式的优化

原文：https://mp.weixin.qq.com/s/PlScarC4gVwEton-T7TNdg

作者在将一个基于多智能体 ReAct 模式（即一个主智能体负责规划，多个子智能体或工具负责执行）的系统应用于生产环境后，发现了一系列性能和体验上的问题。文章详细剖析了这些问题并给出了五种精准的解决方案。

作者遇到的五大核心问题

1. 工具调用延迟严重：使用大模型标准的FunctionCall功能来调用工具，响应速度慢，无法流式返回，导致用户需要长时间等待，体验不佳。

2. 上下文膨胀失控：随着工具调用次数增多，对话历史（上下文）变得越来越长，导致模型推理变慢、API成本剧增，甚至超出模型的上下文窗口限制。

3. 关键中间态缺失：主智能体在规划步骤时，可能会设想出一个没有现成专用工具来执行的中间步骤（例如“生成大纲”）。这导致该步骤的产出缺失，影响了后续任务的质量。

4. 任务结束草率：智能体完成所有任务后，只会给出一句简单的“任务已完成”之类的总结，用户需要自己回溯查找真正有价值的产出，体验割裂。

5. 执行过程缺乏监督：在多轮执行后，智能体可能会偏离最初的整体规划（“跑题”），或者陷入反复调用同一个工具的死循环，缺乏一个全局的监督机制来纠偏。

对应的解决方法与思路

针对以上五个问题，作者提出了五种策略，其核心思路都是通过精巧的工程设计和“工具驱动”的思想，来弥补当前大模型能力的不足。

1. 问题一的解决方案：用“流式XML”替代FunctionCall

   • 思路：将工具调用的指令融入到普通的对话Prompt中，要求模型以固定的XML格式（如<tool_name>和<arguments>）输出。
   • 方法：这样做的好处是，模型的“思考过程”（Thought）和“工具调用”（Action）可以在一个请求中以流式文本返回。用户可以先实时看到模型的思考过程，极大地降低了等待焦虑，同时也兼容了更多不支持FunctionCall的模型。

2. 问题二的解决方案：“合理引用”与压缩

   • 思路：不把所有信息都直接塞入上下文，而是区分处理。
   • 方法：
     • 针对生成文档：将生成的长文档（如PRD）存为文件，在上下文中只保留一个引用标识（如文件名）。当后续工具需要时，再根据引用去读取原文，做到“按需加载”。
     • 针对外部数据：对于网络检索等返回的大量信息，先用一个文本改写小模型进行摘要和压缩，再将精简后的内容放入上下文。

3. 问题三的解决方案：设计“万能Agent”来兜底

   • 思路：系统不应该因为缺少某个特定的专业工具而中断。
   • 方法：创建一个通用的“万能Agent”工具，它的能力被描述为处理任何其他专业工具无法完成的通用任务（如思考、总结、文本创作）。当主智能体发现规划的步骤没有专用工具时，就会调用这个“万能Agent”来生成必要的中间内容，确保任务流程不中断。

4. 问题四的解决方案：设计专用的“总结工具”

   • 思路：将“任务结束并总结”这个行为本身也视为一个需要调用的工具。
   • 方法：创建一个“结束总结工具”。当主智能体判断任务完成并调用此工具时，系统会以此为信号，利用当前全部的上下文信息，再做一次专门的大模型调用，生成一份内容详尽、格式优美的最终报告给用户，化被动为主动，提升最终交付质量。

5. 问题五的解决方案：引入“规划监督（MCP）”服务

   • 思路：为避免智能体“信马由缰”，需要一个顶层的“项目经理”来全程监督。
   • 方法：建立一个即插即用的MCP (Mission Control Platform) 服务，将“监督”这一能力本身，也封装成了一套“工具”，并集成到现有的多智能体框架中。该服务在任务开始时就生成一个总体的计划清单（To-do List），并在每一步执行后更新任务状态。这确保了智能体的每一步行动都围绕着初始目标展开，有效避免了任务跑偏和死循环。

许可协议

本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。

分享文章