多 Agent 架构的三次反转：从中心调度到自驱协作｜得物技术
得物技术 · 软件开发
微辣帝 2026-11-04 18:30 上海 当一个任务只需要一次回答时，单个Agent往往已经够用。但任务一旦变成长链路工作，例如先检索资料、再分析、再写代码、最后复核，问题就不再只是“模型够不够聪明”，而是“整个系统怎样组织行动”。 目录 一、 引言：控制权问题 二、设计前提：两个边界 1. 上下文边界 2.模型边界 三、 协作方式 1. 第一种：Master Agent 调度 2. 第二种：任务看板 3. 第三种：Advisor 四、 三次反转：控制权下沉 五、 落地案例：中间件巡检 1. 巡检难点 2. Master Agent：意图与路由 3. 任务看板：并行与自愈 4.Advisor：按需咨询 六、 结语：匹配控制权 一 引言：控制权问题 当一个任务只需要一次回答时，单个Agent往往已经够用。但任务一旦变成长链路工作，例如先检索资料、再分析、再写代码、最后复核，问题就不再只是“模型够不够聪明”，而是“整个系统怎样组织行动”。 我们需要安排不同的能力，也需要处理任务依赖、并发、失败重试和上下文传递。于是，多Agent架构真正要解决的不是“如何调用更多模型”，而是四个组织问题：谁拆解任务，谁分配任务，谁判断任务完成，以及Agent之间共享什么信息。 这四个问题最终都指向同一件事： 系统里的控制权究竟放在哪里 。 沿着控制权的变化往下看，Master Agent、任务看板和Advisor正好构成一条逐步反转的路径。不过，在比较三种架构之前，还需要先划清两个经常被忽略的设计边界。 二 设计前提：两个边界 上下文边界 很多人第一次接触多Agent，会自然地把它理解成一支“职业团队”：数据库Agent、前端Agent、后端Agent，各自负责一个领域。但在同一个基础模型上，仅仅换一段角色提示词，通常不足以让Agent真正专精于某个领域。 模型知道什么，首先取决于它拿到了什么上下文 ；它能否给出高质量回答，也取决于上下文是否足够相关。 因此，更有价值的切分方式不是给Agent贴职业标签，而是划分上下文边界和信息压缩边界。代码分析Agent面对的是完整的调用关系、错误堆栈和实现细节，它的任务是把这些细节压缩成核心Agent可以直接使用的结论。数据探索Agent则处理原始数据、分布和异常，把探索过程蒸馏成少量关键发现。核心Agent不必携带所有原始材料，只需要接收与当前决策最相关的上下文。 这也是为什么“代码分析Agent”“数据探索Agent”往往比“后端Agent”“数据库Agent”更实用： 前者描述了上下文和产出的边界，后者只是一个容易被提示词放大的职业想象 。 模型边界 多Agent的另一个现实收益，是可以把不同模型放在同一条协作链上。大模型通常更擅长长链路推理、复杂权衡和最终裁决，但代价是更高的延迟和调用成本；小模型响应很快，适合批量筛选、结构化提取和早期探索，却可能在开放式问题上失去细节。 一个更实际的组合是 让小模型负责“快” ：先扫描大量候选、提取字段、发现异常，把结果压缩成结构化线索；再 让大模型负责“深” ：基于这些线索补足上下文，比较方案，处理冲突，并对最终结果负责。模型之间不是简单的上下级替代关系，而是通过Agent边界把速度和质量组合起来。 当然，模型切换也会带来新的工程问题：小模型输出需要被校验，大模型需要知道结论的来源，预算和超时要有明确上限。只有把输出协议、证据引用和失败回退设计好，“大小模型协作”才不会变成一次不可解释的随机接力。 上下文边界决定每个Agent应该看见什么，模型边界决定每一步值得投入多少能力。划清这两个边界之后，接下来的问题才是：这些Agent到底由谁组织，又由谁决定下一步。 三 协作方式 第一种：Master Agent调度 最容易理解的多Agent形式，是让一个Master Agent站在中心位置。它负责理解用户目标，把大任务拆成若干步骤，再将每一步路由给合适的Worker Agent。Worker Agent完成工作后把结果交回Master Agent，由Master Agent决定下一步并最终汇总。 例如，一项“调研并撰写技术报告”的工作，可以先由Research Agent搜集资料，再由Analyst Agent提炼观点，最后交给Writer Agent组织文章。每个Worker Agent都只需要做好自己的局部工作，整个流程由Master Agent负责串起来。 Master Agent模式的优势在于控制流非常清楚。谁先执行、谁后执行、哪些结果要传给下一个 Agent，都可以在一个地方观察和修改。权限、预算、超时和失败处理也更容易集中管理。对于流程固定、依赖明确的任务，这种确定性很有价值。 它的问题也来自同一个中心。任务变复杂后，Master Agent不仅要完成自