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 双实现专门解决一个问题当你的产品里同时跑着好几个 AI 智能体用户的一句话该交给谁它替你管好意图分类、请求路由、对话记忆和结果回写这套流程你只需要专注定义每个智能体管什么事。一条用户请求在框架里走完全程先说结论这个框架的价值不在智能体多而在把多智能体之间的调度标准化了。传统做法是每个智能体各写各的路由逻辑散落在业务代码里加一个新智能体就要改一堆地方。这里的路由被收敛成一个固定回路用户输入先进分类器——你可以把它理解成分诊台只看这个症状该去哪个科——再交给选中的智能体处理最后把这一轮对话存回历史库供下一轮分诊参考。理解了这个回路后面所有的坑都好定位了。五分钟搭出能跑的多智能体系统这一步只验证回路是通的不追求功能。Python 用户装主包加依赖TypeScript 用户跑npm install multi-agent-orchestrator即可包名相同。pip install multi-agent-orchestrator[aws] orchestrator MultiAgentOrchestrator() orchestrator.add_agent(weather_agent) # 只答天气 orchestrator.add_agent(order_agent) # 只答订单 response await orchestrator.route_request(明天会下雨吗, user_id, session_id)注意route_request同时接收 user_id 和 session_id这两个参数是后续所有对话记忆的定位键建议从第一行代码就保持一个用户一个会话的习惯后面换存储时不用返工。跑通后别急着加智能体——先花点时间把每个智能体的职责边界想清楚这一步决定了系统上限。智能体怎么分岗位说明书比数量重要核心观点分类器唯一看得见的东西是每个智能体的 name 和 description。写得好不好直接决定路由准不准。几条经验值都是踩过坑的描述要写成边界描述说清管什么、更关键的是不管什么比如处理订单查询与售后不涉及物流时效预估什么都能聊式的描述等于没写智能体数量克制一些两个描述高度重叠的智能体比缺一个更糟。框架其实内置了体检工具AgentOverlapAnalyzer 会把所有智能体的描述做 TF-IDF 加余弦相似度两两对比输出重叠百分比和冲突等级。const analyzer new AgentOverlapAnalyzer(agents); analyzer.analyzeOverlap();重叠度超过 30% 就属于高冲突回去改描述低于 10% 且每个智能体都有明确领地说明划分是健康的。每次增删智能体或改完描述跑一遍再上线。需要协作时就加上 SupervisorAgent如果任务天然要多个智能体配合别指望用户手动切换。SupervisorAgent 采用agent-as-tools模式它自己是领队把其他智能体包装成工具可以并行分派子任务再汇总答案。它可以被直接调用也可以作为一个普通智能体挂进分类器里拼出更深的协作层级。仓库里的 movie-production、travel-planner 两个示例就是这种玩法值得对着读一遍。分类器选不准先查岗位说明书再怀疑模型分类器是整个系统的咽喉它判错一次用户后面半轮对话都会被带歪。内置三种实现——Bedrock默认、Anthropic、OpenAI——选择只看三件事你的 API 权限在哪、模型在你的语料上实测表现、成本。orchestrator MultiAgentOrchestrator( classifierAnthropicClassifier(AnthropicClassifierOptions(api_key...)), default_agentfallback_agent, )这里有个反直觉但重要的点分类器频繁选错八成是智能体描述写糊了而不是模型不行——分类器靠描述做判断描述模糊它就只能猜。所以排查顺序应该是先重写描述再考虑换模型。另外两个实用技巧分类器可以脱离智能体单独调用classify方法做路由测试输入一句话直接看选中谁、置信度多少调 prompt 时比端到端跑快得多真路由不了时用配置里的USE_DEFAULT_AGENT_IF_NONE_IDENTIFIED挂一个兜底智能体或配NO_SELECTED_AGENT_MESSAGE让用户补充信息别让系统直接报错把用户晾在那。对话历史开发用内存生产换持久化历史存哪决定系统记不记得住人。框架按 userId、sessionId、agentId 三个维度组织每轮对话切换后端不用改业务代码只换一行初始化参数后端适合场景特点内存存储本地开发、测试默认零配置重启即失忆DynamoDB生产环境持久、可跨实例共享SQLite / Turso本地优先、边缘部署一个库文件搞定支持远程开发阶段别浪费时间搭数据库上生产再按上表切换。还有一个常被忽略的旋钮MAX_MESSAGE_PAIRS_PER_AGENT控制每个智能体保留的上下文轮数设太短对话会断片设太长既拖慢又烧钱建议从 10~50 之间按实际体验调。上线前的三个检查点把系统跑稳靠的不是加功能而是盯住三个点路由日志、描述体检、兜底逻辑。打开LOG_CLASSIFIER_OUTPUT和LOG_EXECUTION_TIMES每次路由选了谁、花了多久都落日志出问题能回放现场分类器侧的MAX_RETRIES控制重试次数和兜底消息配合使用。每次改动智能体描述后跑一遍重叠分析这是最低成本的回归测试。上线前确认没路由到智能体时用户看到的是兜底回复而不是堆栈。仓库的 examples/ 目录里有聊天应用、电商客服模拟器、FastAPI 流式接口等多个真实形态可以直接对照你的场景找参考实现。想快速见效就先把两个智能体的描述写成互斥的岗位说明书再跑一次重叠分析。路由错误反复出现时优先重写描述而不是换模型。上线前务必给无人认领的输入留好退路——这三件事做到你的多智能体系统就能平稳跑起来。【免费下载链接】agent-squadFlexible and powerful framework for managing multiple AI agents and handling complex conversations项目地址: https://gitcode.com/GitHub_Trending/mu/agent-squad创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考