跳到主要内容

管理者模式

管理者模式是什么？​

  • 触发条件: 任务涉及大量子任务、需要动态调度，或子任务之间存在复杂依赖时，对等协作力不从心;
  • 职责类比: 像一个项目经理——先理解整体任务，再拆解为可分配的子任务，选择合适的 Agent 执行，跟踪进度并处理异常（重试、换 Agent、调整计划），最后把各 Agent 输出整合为最终结果;
  • 抽象手段: 把每个专门 Agent 建模为 Manager 可调用的工具;
  • 统一抽象: 从 Manager 视角看，调用一个 Agent 与调用一个普通工具没有本质区别;
  • 可扩展性: 新增能力只需开发对应 Agent 并注册为工具，Manager 核心逻辑无需修改;
  • 异构性: 不同 Agent 可以用不同模型、提示词、工具集，甚至运行在不同硬件环境上;

管理者模式的固有挑战是什么？​

  • 单点瓶颈: Manager 必须理解所有子任务性质、选择正确 Agent、准确传递上下文，任何决策偏差都会影响整体流程;
  • 上下文膨胀: Manager 需要维护整个任务的全局上下文，随任务推进与调用增多而快速膨胀;
  • 应对方向: 特别需要注意 Manager 的提示词质量、上下文管理策略与合理的任务分解粒度;
  • 实证: 2025 年 Plan-and-Act（arXiv:2503.09572）分析 Planner–Executor 双 Agent 架构，发现弱规划者是整个系统最关键的瓶颈——Planner 质量足够高时简单 Executor 也能取得好结果；Planner 分解有误则所有 Executor 的工作都建立在错误前提上;
  • 基准成绩: 该研究在 WebArena-Lite 上取得 54% 成功率，核心贡献是改善 Planner 而非 Executor;
  • 启示: 应把最强模型与最精心设计的提示词分配给 Manager（规划者），而不是把资源平均分配给所有 Agent;

顺序协调形态适合什么任务？​

  • 结构: Manager 按顺序依次调用专门 Agent，每个 Agent 完成后返回结果，Manager 再决定下一步;
  • 控制流: 线性的，简单明了;
  • 适用: 子任务之间有清晰先后依赖的场景;
  • 实例: 书籍翻译流水线见 管理者模式的实践案例;

并行协调形态需要什么基础设施？​

  • 结构: Manager 同时规划多个并行子任务，实时监控所有运行中的 Agent，协调通信，并在成功或失败时做全局决策;
  • 基础设施: 通常需要消息总线（Message Bus）——可理解为"公共公告板"，Agent 往上面贴消息（发布），也关注自己感兴趣的消息类型（订阅），实现异步通信、互不阻塞;
  • 消息信封与状态语义见 Agent 间的消息与状态;

并行管理器如何界定结算点？​

  • 要求: 必须定义"第一个已验证成功"而不是"第一个声称成功"的结算点;
  • 参考实现:
workers = launch_independent_workers(subtasks)
while workers.any_running:
    event = next_event()
    if event.type == RESULT:
        if verify(event.artifact, hidden_checks):
            if not settle_once(event):       # atomically claim the winner
                continue
            broadcast_cancel(to = workers - {event.worker_id})
            await_all_ack_or_timeout()
            return assemble(event.artifact, evidence = event.evidence)
        else:
            record_failure(event)
return summarize_failures(workers)