Manager Pattern
由一个主管 Agent 持有会话、调用专业 Agent 工具并组合最终输出。
学习目标
- 能说明Manager Pattern解决什么问题，以及何时适用。
- 能解释为什么“主管上下文膨胀”是误区。
学习前需要掌握
背景与问题
多个专家都能给出局部结论时，用户仍需要一个连贯、受约束的最终结果。Manager 模式让一个主管维护任务契约、选择专家并协调冲突，而不是把多段回答简单拼接。
主管承担的是分配、验收与综合责任。它不应在无法核对的情况下替专家补充事实，也不能因为自己拥有更多上下文就绕过安全与授权。
概念定义
Manager Pattern 是 Agents as Tools 的系统级使用方式，主管集中施加格式、护栏和汇总策略。
直观理解
总编分派记者调查不同主题，最后自己核对并编辑成一篇文章。
核心原理
主管先把用户目标拆成有明确边界的子任务，选择合适专家并分配最少必要上下文。任务的前后依赖决定串行或并行，未完成的专家结果不能被提前当成最终依据。
专家通常以 Agents as Tools 的形式返回，主管保持对话控制权。返回值应包含结论、证据、适用范围与不确定性，方便主管检查是否回答了真正的子问题。
综合阶段应处理冲突而不只是合并文本。若专家使用不同版本、单位或假设，主管需要回查资料或请求定向补充；专家数量多并不能让矛盾自动消失。
主管也可能成为瓶颈与单点失败源。清晰的输出契约、确定性汇总检查和预算限制可以减少负担；如果专家需要持续与用户处理领域问题，则可改用显式交接，让活动控制者与实际职责一致。
案例：两位专家对采购方案意见相反
成本专家按一年使用量估算方案甲更便宜，可靠性专家根据高峰负载建议方案乙。主管先核对双方是否使用同一负载假设，再区分硬约束与偏好：若甲达不到必需的峰值能力，不能用价格优势抵消该缺口。
若两者都满足约束，主管可以把成本与余量并列呈现，保留需要用户决定的取舍。需要补充时只追问影响结论的假设，而不是让所有专家重新生成整篇分析。最终推荐应附依据，不能靠“多数专家支持”冒充证明。
理解与实践步骤
- 主管拆分任务
- 选择一个或多个专家
- 收集结构化结果
- 检查冲突与证据
- 输出最终答案
实际应用
- 多领域研究
常见错误
- 把所有专家输出顺次粘贴，没有检查单位、版本、假设与相互矛盾的结论。
- 主管为掩盖证据不足而编造衔接事实，或让专家重复做相同工作。
- 把主管设成所有高风险写操作的默认授权者，跳过用户与业务系统的权限边界。
输入、输出与执行边界
输入
- 用户任务
- 专家工具目录
输出
- 统一最终答案
能力
- 多领域研究
安全风险与信任边界
管理者汇总多个执行者的结果时，应保留证据与未解决分歧，而不是仅按多数或语气决定。子任务的输入与输出范围要明确，避免汇总过程扩大敏感数据暴露，或将一个执行者的推测传播为所有任务共享的事实。
性能与失败模式
管理者可能成为串行调度与审核瓶颈，拆得太细又会增加任务说明和合并成本。评价时固定总体预算，记录分派错误、返工与汇总遗漏；多角色产生更多文本并不能证明比单一执行者更可靠。
推荐学习资料
参考库不会生成虚假资源或无效外部链接。