用途：指导设计与实现多智能体大模型架构，采用编排者-子智能体（orchestrator-subagent）模式；同时帮助判断是否值得从单智能体升级为多智能体。
主要能力与内容：
- 决策框架。多智能体因跨智能体重复上下文、协调消息、交接摘要，token 消耗为单智能体的 3-10 倍，且每个智能体都是潜在故障点。任务顺序且依赖上下文、工具数在 15-20 以下、并行无明显收益时，应优先用单智能体。
- 三类适用场景：上下文污染（子任务产生超过 1000 token 但大部分与主任务无关）、并行化（任务可独立运行、探索更大搜索空间）、专精化（不同任务需要不同工具、提示或领域知识）。
- 上下文保护模式：让子智能体只返回 50-100 token 的摘要而非 2000+ token 的原始内容，主智能体获得干净上下文；适合子任务定义明确、需要过滤的查询或检索。
- 并行化模式：主智能体拆分查询、用 asyncio.gather 并行调用子智能体再综合结果；收益是覆盖面更全而非更快，token 成本更高。
- 专精化模式：按工具集（20+ 工具、跨领域混淆或性能下降时）、系统提示（客服、代码审查、合规、头脑风暴等行为模式冲突时）、领域知识（法律、医疗等会压垮通才的深度上下文）拆分。示例含 CRMAgent、MarketingAgent 与 OrchestratorAgent 的委派路由。
- 分解原则：以上下文为中心而非以问题为中心；同一功能的实现与测试由同一智能体负责更有效。合适的边界包括独立研究路径、有清晰 API 契约的独立组件、黑盒验证；不合适的边界包括同一工作的顺序阶段、紧耦合组件、需要共享状态的工作。
- 验证子智能体模式：由专职智能体测试和校验主智能体产出，因验证所需上下文转移最少而效果好。需防范“过早成功”，做法是给出具体标准（如“运行完整测试套件”而非“确认能工作”）、覆盖多场景与边界、加入负向测试、明确指令（如“You MUST run: pytest --verbose”）。
- 推进检查清单：确认存在真实约束（上下文限制、并行化、专精化需求），分解依据上下文而非问题类型，设有子智能体可校验的明确验证点；从能工作的最简方案起步，有证据再增加复杂度。
限制与说明：资料未提供安装命令、URL 之外的获取方式、收费或价格、具体平台支持列表与效果数据；代码示例仅为架构示意，未说明可直接运行的环境与依赖版本，实际落地需自行验证。文中模型与工具调用仅为示例写法，不代表功能承诺。