从跑通第一次对话到生产调优Multi-Agent Orchestrator 多智能体编排框架实操指南【免费下载链接】agent-squadFlexible and powerful framework for managing multiple AI agents and handling complex conversations项目地址: https://gitcode.com/GitHub_Trending/mu/agent-squadMulti-Agent Orchestrator 是一个多智能体编排框架用户请求进来后分类器根据各智能体的职责描述和对话历史把请求路由给最合适的智能体智能体回复后再按用户 会话 智能体三把钥匙把这一轮对话写进存储层。它解决的核心问题是——当你同时有客服、天气、订单等多个智能体时由谁来决定当前这句话该谁接。项目提供 Python 和 TypeScript 两套同构实现从本地脚本到 AWS Lambda 都能部署。概念速览 整条链路只有四步分类器解析用户输入结合智能体特征和会话历史选出最合适的智能体被选中的智能体处理请求编排器保存对话、更新历史后把结果返回给用户。适合谁用如果你要做一个需要多种 AI 能力同时待命的对话系统又不想自己写 if-else 路由规则这个框架替你把调度、上下文维护、历史存储这三块收进去了。你只负责提供智能体本身。从零搭建跑通最小可用链路 ️最小可用链路只做三件事定存储、配路由、注册智能体。先 clone 仓库再看git clone https://gitcode.com/GitHub_Trending/mu/agent-squad先选存储对话历史放哪存储决定进程重启后历史还在不在。storage/目录下有三类内置实现选型很简单InMemoryChatStorage默认值零配置进程退出历史即丢开发调试就用它DynamoDBChatStorage持久化适合生产环境多实例部署SqlChatStorageSQLite 或 Turso本地开发和远程部署都想用 SQL 时选它。构造编排器时不传存储参数会自动落回内存实现所以第一次跑通不用操心这一步。生产上线前再切换并给表配上 TTL 方便后续清理。各实现的接口一致切换时不用改业务代码路径见 storage/。再配路由分类器怎么选、规则怎么写分类器是路由层的大脑classifiers/下内置三种实现BedrockClassifier默认装了 aws 依赖自动启用、AnthropicClassifier、OpenAIClassifier也支持自己实现 Classifier 接口做纯规则路由。实际跑起来你会发现路由准不准主要不取决于分类器而取决于你给每个智能体写的 name 和 description——分类器就是拿这些描述和当前输入做匹配。两条智能体的描述写得太像路由就会来回摇摆。写描述时说回答什么问题而不是是什么比如回答订单状态、退款进度的问题比订单相关智能体稳定得多。实现都在 classifiers/ 里对照着改。注册智能体跑通第一次对话智能体池在agents/下内置 BedrockLLMAgentLLM 加工具调用、LexBotAgentAmazon Lex、ChainAgent多次 LLM 调用串联等十几种实现。跑通第一次对话只需要这几行from multi_agent_orchestrator.orchestrator import MultiAgentOrchestrator from multi_agent_orchestrator.agents import BedrockLLMAgent orchestrator MultiAgentOrchestrator() orchestrator.add_agent(BedrockLLMAgent(name天气助手, description回答天气相关问题)) result await orchestrator.process(明天会下雨吗, user_idu1, session_ids1)跑通后把配置里的 LOG_CLASSIFIER_OUTPUT 打开每次请求会打印出识别到的意图、选中的智能体和置信度这是排查路由问题的第一手资料。下一步可以故意发一句模糊输入看路由会不会摇摆再回去改描述。内置智能体的完整列表见 agents/。调优与避坑生产环境关注点 ⚠️分类失败怎么兜底分类器置信度不足或输出解析失败时如果什么都不配用户会看到一条硬邦邦的默认拒绝语。编排器的降级行为由两个配置项控制USE_DEFAULT_AGENT_IF_NONE_IDENTIFIED默认 True命中时交给 default_agent和 NO_SELECTED_AGENT_MESSAGE没配默认智能体时的兜底文案。处理办法是永远注册一个通用问答智能体并设为 default_agent路由失败也能有回应而不是让对话断在这里。超时和重试怎么设LLM 调用是延迟毛刺最多的一环。配置项里 MAX_RETRIES 默认 3 次失败会按此重试超时建议分两层配智能体内部的模型超时由 LLM 客户端参数控制外层网关再设一个全局超时。网关超时如果小于单次处理耗时 × 最大重试次数会出现网关先断、重试还在跑的错位。对齐这两个数值再根据 P95 延迟回看重试次数是否需要降下来。对话历史清理策略怎么配长会话跑久了会遇到上下文越滚越长token 成本上升分类器还可能被旧话题带偏。配置项 MAX_MESSAGE_PAIRS_PER_AGENT 默认 100 对存储层写入时只保留每个智能体最近 N 对消息另外每个智能体可以用 save_chat 标志决定自己是否参与存历史。客服这类高频短场景把 N 调到 20~30 就够需要跨天记忆的场景保持默认或调高。性能监控怎么看变慢了但不知道慢在哪时先打开 LOG_EXECUTION_TIMES编排器会把分类和各智能体处理两个阶段的耗时记进 execution_times直接看出瓶颈在分类还是在智能体侧。想看路由质量再配合 LOG_CLASSIFIER_CHAT 和 LOG_CLASSIFIER_RAW_OUTPUT把分类器的输入和原始输出都落日志误路由时能直接复盘当时给了分类器什么上下文。扩展能力自定义工具与多智能体协作 给智能体加工具工具注册机制在utils/下的 AgentTool传入一个普通函数框架自动从函数签名提取参数名和类型生成参数 schema取 docstring 首段当工具描述——写个带注释的函数就是一个工具不用额外声明 JSON。把工具列表挂到 BedrockLLMAgent 上对话中智能体会自行决定何时调用。示例目录里有个天气工具照抄起步最快。相关实现在 utils/。多智能体协作SupervisorAgent分类器路由是选一个来答任务需要多个智能体接力时则用 SupervisorAgent。它采用agent-as-tools架构lead 是一个 LLM 智能体team 里的成员各自暴露成 leader 可调用的工具由 leader 统一分派可以并行调用多个成员。Supervisor 不走分类器直接 process_request 就行。典型配法是 leader 写团队协调者team 放产品信息订单管理复杂问题处理这类专家。仓库里的电商客服模拟器就是这个模式的完整落地聊天和邮件双通道下协调产品信息、订单等多智能体并行工作。TypeScript 端还带一个 Agent Overlap 分析器对智能体描述做相似度计算上线前查一遍职责重叠很有用。上线前检查清单智能体描述互不重叠用 overlap 分析器确认相似度不高的描述已改写已注册 default_agent并配置好 NO_SELECTED_AGENT_MESSAGE 兜底文案存储已从 InMemory 切到 DynamoDB/SQLMAX_MESSAGE_PAIRS_PER_AGENT 按场景设过值MAX_RETRIES 与网关超时对齐过不存在网关先断、重试还在跑LOG_EXECUTION_TIMES 已开启能定位慢在分类还是智能体阶段把仓库克隆下来后从 examples/ 开始跑examples/python/ 里有基于 Streamlit 的 demo 和电影制作、行程规划两个完整场景examples/local-demo/ 是纯本地 TypeScript 版本跑通任意一个再对照本文过一遍配置。【免费下载链接】agent-squadFlexible and powerful framework for managing multiple AI agents and handling complex conversations项目地址: https://gitcode.com/GitHub_Trending/mu/agent-squad创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
