Java 工程师 LLM 工程化

Appearance

多 Agent 协作模式：四种范式与代价 ​

1. 本节产出 ​

四种协作模式（Pipeline / Supervisor / Debate / Handoff）的可运行示例，一张对比表说明各自代价，以及一条明确的建议：默认别用多 Agent。

2. 前置依赖 ​

3. 为什么「多 Agent」常被过度使用 ​

一个真实案例：团队用 5 个 Agent（规划师、检索员、写作员、审查员、发布员）做一个文档摘要任务。结果：

指标单 Agent5 Agent
模型调用次数423
耗时8s41s
成本0.012 元0.068 元
质量评分4.2 / 54.3 / 5

成本涨 5.7 倍，质量提升 0.1 分。 这个 trade-off 在绝大多数业务里不成立。

什么时候多 Agent 真的有价值：

场景为什么需要
任务可清晰分解为独立子任务（并行能省时间）并行收益超过协调成本
需要不同角色有不同权限（比如查数据的不能写数据）权限隔离是刚需
需要对抗性校验（生成 vs 审查）降低错误率
单 Agent 上下文装不下分工减少单个上下文

除此之外，单 Agent 更好。 这是本节最重要的建议。

4. 核心原理 ​

4.1 四种模式对比 ​

模式结构优点缺点适用
PipelineA → B → C 线性简单可预测、易调试无法回头、串行慢固定流程（抽取→校验→生成）
Supervisor中央调度 + 多个执行者灵活、可动态分工调度器成为瓶颈与单点任务类型多样
Debate多个生成 + 互相批评质量提升明显成本最高、可能僵持高风险决策、内容质控
HandoffAgent 之间转交控制权对话式转接自然状态传递复杂、易循环客服、多轮场景

4.2 Pipeline：最实用 ​

订单处理流水线：
  抽取 Agent → 校验 Agent → 执行 Agent
  
  每一步输入输出明确
  每一步可单独测试
  中间结果可落库（便于排查）

Pipeline 是四个模式里性价比最高的，因为它保留了可预测性和可调试性。建议：能拆成 Pipeline 就不要用 Supervisor。

4.3 Supervisor：中央调度的代价 ​

              ┌─────────────┐
              │  Supervisor │
              └──────┬──────┘
        ┌────────────┼────────────┐
        ▼            ▼            ▼
   查订单 Agent  查库存 Agent  写工单 Agent
代价说明
调度器额外调用每轮都要问一次「下一步交给谁」
单点故障调度器挂了整个流程停摆
上下文膨胀调度器要看到所有子 Agent 的结果
调试困难出问题时难以还原完整决策链

4.4 权限隔离：多 Agent 最正当的理由 ​

查询 Agent：  只有读工具的权限          → 即使被注入也无法改数据
执行 Agent：  有写工具，但需人工审批    → 写操作可控

这是安全设计，不是性能优化。如果多 Agent 的动机是「让每个 Agent 权限更小」，那它非常值得——这直接对抗 Prompt Injection 的破坏力（见 03B-11）。

5. 代码走查 ​

5.1 统一 Agent 接口 ​

java
// ch03-agent/src/main/java/com/aitech/agent/agent/SpecializedAgent.java
public interface SpecializedAgent {
    String name();
    StepResult execute(String input, AgentContext ctx);
}

public record StepResult(String output, boolean success, String error) {}

5.2 Pipeline 实现 ​

java
// ch03-agent/src/main/java/com/aitech/agent/orchestration/Pipeline.java
@Component
public class Pipeline {

    private final List<SpecializedAgent> steps;

    public String run(String input, AgentContext ctx) {
        String current = input;

        for (SpecializedAgent step : steps) {
            log.info("pipeline step: {}", step.name());
            StepResult r = step.execute(current, ctx);

            if (!r.success()) {
                // 失败不静默：记录到哪一步失败，输入是什么
                log.error("pipeline 失败于 {}，error={}", step.name(), r.error());
                throw new PipelineException(step.name(), r.error(), current);
            }
            ctx.record(step.name(), current, r.output());   // 中间结果落盘
            current = r.output();
        }
        return current;
    }
}

ctx.record() 记录每一步的中间结果是 Pipeline 可调试的关键。出问题时能完整还原。

5.3 Supervisor 实现（简化版） ​

java
// ch03-agent/src/main/java/com/aitech/agent/orchestration/Supervisor.java
@Service
public class Supervisor {

    private final Map<String, SpecializedAgent> workers;

    public String run(String goal, AgentContext ctx) {
        String state = goal;

        for (int i = 1; i <= MAX_ROUNDS; i++) {
            // 1. 调度决策：这一步交给谁
            Decision d = decideNext(state, ctx);

            if (d.isFinish()) return d.finalAnswer();

            // 2. 交给子 Agent 执行
            SpecializedAgent worker = workers.get(d.agentName());
            StepResult r = worker.execute(d.instruction(), ctx);

            // 3. 结果回写状态
            state += "\n[%s 的结果] %s".formatted(d.agentName(), r.output());
            ctx.record(d.agentName(), d.instruction(), r.output());
        }
        throw new MaxRoundsException(MAX_ROUNDS);
    }

    public record Decision(String agentName, String instruction,
                           boolean finish, String finalAnswer) {
        public boolean isFinish() { return finish; }
    }
}

5.4 Debate 模式（对照用） ​

java
// ch03-agent/src/main/java/com/aitech/agent/orchestration/Debate.java
@Service
public class Debate {

    public String run(String question, AgentContext ctx) {
        String a = proponent.answer(question);      // 正方
        String b = critic.critique(question, a);    // 批评
        String c = proponent.revise(question, a, b);// 修订
        return judge.pick(question, a, c);          // 裁判选择
    }
}

四次模型调用换一次答案，只在质量优先、成本不敏感的场景用（比如生成对外发布的文案）。

6. 跑起来 ​

bash
git checkout ch03-04-multi-agent
mvn -q test -Dtest=MultiAgentComparisonTest

期望输出（本节核心证据）：

同一任务（处理一笔退货申请）：

模式          模型调用  耗时    成本      质量分
单 Agent        6       11s    0.018     4.2
Pipeline(3步)   9       16s    0.027     4.4
Supervisor     14       28s    0.045     4.3
Debate         18       39s    0.058     4.6

结论：Pipeline 是性价比最优；Debate 质量最高但成本 3 倍
检查项通过标准
四种模式可运行都能完成同一任务
成本可对比日志输出调用次数与 Token
Pipeline 可调试中间结果可查
Supervisor 有上限达到轮次上限时抛异常而非死循环

7. 生产避坑 ​

  1. 默认用单 Agent，只有明确收益才升级为多 Agent。多 Agent 的成本增长是超线性的（协调本身要消耗调用），而质量提升往往边际递减。先把单 Agent 做到极致，再考虑拆分。
  2. Pipeline 的每一步必须记录中间结果。多步流程最大的问题是「不知道错在哪一步」。落盘中间结果后，排查成本从几小时降到几分钟。
  3. Supervisor 必须有轮次上限。调度器可能反复把任务在同一个 Agent 之间来回传递（尤其当子 Agent 的输出不够明确时），没有上限就是死循环——而且它比单 Agent 死循环烧钱快得多（每轮多一次调度调用）。

8. 延伸与锚点 ​

  • 思考题：Agent 跑了 3 分钟还没结束，中间服务重启了，任务状态怎么办？（答案在下一课时：状态机与持久化）
  • 代码锚点：git checkout ch03-04-multi-agent
  • 下一课时：03-05 状态机与持久化
  • 对应课件：L03-04 多 Agent 协作