Multi-Agent 协作¶

一句话：Multi-Agent 把一个复杂任务拆给多个分工角色（如规划者-执行者-审核者）协作完成，相比单 Agent 提升了可控性、专业性和安全兜底，代价是更高的编排复杂度与 Token 成本。

概念¶

单 Agent 是"一个 LLM 通吃思考、调工具、给答案"，简单高效，但在复杂任务上容易一手包办、缺校验、出错难拦截。Multi-Agent 则引入多个专职 Agent，各自有不同系统提示、工具集和职责，通过编排协议协作。

报告 §5.3 中彭超案例的 "规划者-执行者-审核者"三角色架构 是企业级最经典的分工：

角色	职责	关键能力
规划者（Planner）	拆解任务、生成执行计划、决定调哪些工具	全局规划、意图理解
执行者（Executor）	按计划调用工具、检索、生成中间结果	工具调用、RAG 检索
审核者（Reviewer）	基于规则引擎校验执行者输出是否合规、可信	规则匹配、阈值判断、兜底

审核者是这套架构的"安全阀"。它的校验不是让 LLM 自我判断，而是落地成可配置规则引擎，覆盖：

合规：是否触发敏感词、违规承诺、超出业务范围；
金额阈值：涉及金额是否超阈值需人工确认；
业务约束：是否满足业务前置条件（如订单状态、权限范围）；
事实性：关键事实是否在检索证据中有支撑（与幻觉治理联动）。

校验不通过时，审核者按策略回退重规划（让规划者带着失败原因重拟）或转人工（高风险场景兜底），形成闭环。

原理¶

报告里另一个标杆案例是江旭的"6 子 Agent 协同 + 幻觉治理"——尽调报告生成场景下，6 个子 Agent 分别负责不同尽调维度（财务、股权、舆情、法律等），协同产出报告，并叠加幻觉治理把幻觉率压到 0.1%、尽调成功率从 78% 提升到 93%。这印证了 Multi-Agent 的核心价值：按领域分工 + 每个子链路可独立优化 + 统一审核兜底。

下面给出三角色架构的实现骨架。

JavaPython

// LangChain4j 风格：规划者-执行者-审核者三角色
public class MultiRoleAgent {

    private final ChatLanguageModel planner;   // 规划者
    private final ChatLanguageModel executor;  // 执行者
    private final ReviewRuleEngine reviewer;   // 审核者（规则引擎，非 LLM）

    public AgentResult handle(Task task) {
        int maxRetry = 3;
        for (int attempt = 0; attempt <= maxRetry; attempt++) {
            // 1. 规划者：拆解任务
            Plan plan = planner.generate(PromptTemplates.plan(task)).toPlan();

            // 2. 执行者：按计划执行
            PlanResult result = executor.generate(PromptTemplates.execute(plan, task)).toResult();

            // 3. 审核者：规则引擎校验（合规/金额阈值/业务约束/事实性）
            ReviewDecision decision = reviewer.review(task, plan, result);

            switch (decision.getOutcome()) {
                case PASS:
                    return AgentResult.ok(result);
                case REJECT_HUMAN:                 // 高风险转人工
                    return AgentResult.toHuman(decision.getReason());
                case REPLAN:                       // 回退重规划，带失败原因
                    task = task.withFeedback(decision.getReason());
                    continue;
            }
        }
        return AgentResult.toHuman("超过最大重规划次数，转人工兜底");
    }
}

/** 审核者规则引擎：可配置、可热更，非 LLM 判定 */
public class ReviewRuleEngine {
    public ReviewDecision review(Task t, Plan p, PlanResult r) {
        if (complianceChecker.violates(r))      return ReviewDecision.replan("命中合规规则");
        if (r.getAmount() != null && r.getAmount().compareTo(threshold) > 0)
            return ReviewDecision.human("超金额阈值需人工确认");
        if (!businessConstraintChecker.ok(t, r)) return ReviewDecision.replan("业务约束不满足");
        if (!evidenceChecker.supported(r))      return ReviewDecision.replan("关键事实无证据支撑");
        return ReviewDecision.pass();
    }
}

# LangGraph 风格：三角色状态图 + 规则引擎审核
from langgraph.graph import StateGraph, END
from typing import TypedDict, Literal

class State(TypedDict):
    task: dict
    plan: dict
    result: dict
    review: dict
    feedback: str
    to_human: bool

def planner_node(state: State) -> State:
    prompt = plan_prompt(state["task"], feedback=state.get("feedback"))
    state["plan"] = llm.invoke(prompt).plan
    return state

def executor_node(state: State) -> State:
    state["result"] = executor.run(state["plan"], tools=tools)
    return state

def reviewer_node(state: State) -> State:
    # 审核者：规则引擎（合规/金额/业务/事实），非 LLM
    state["review"] = rule_engine.review(
        state["task"], state["plan"], state["result"]
    )
    return state

def after_review(state: State) -> Literal["planner", "human", "done"]:
    outcome = state["review"]["outcome"]
    if outcome == "pass":   return "done"
    if outcome == "human":  return "human"
    return "planner"        # replan，带 feedback 回到规划者

def human_node(state: State) -> State:
    state["to_human"] = True
    return state

g = StateGraph(State)
for n, fn in [("planner", planner_node), ("executor", executor_node),
              ("reviewer", reviewer_node), ("human", human_node)]:
    g.add_node(n, fn)
g.set_entry_point("planner")
g.add_edge("planner", "executor")
g.add_edge("executor", "reviewer")
g.add_conditional_edges("reviewer", after_review,
                        {"planner": "planner", "human": "human", "done": END})
g.add_edge("human", END)
graph = g.compile()

实战要点¶

审核者尽量是规则引擎而非另一个 LLM：用可配置、可热更的规则做合规/阈值/业务约束判断，比让 LLM 自审更可控、可解释、低成本。事实性校验可与 RAG 证据召回联动。
不通过要形成闭环：审核失败不是终点，要带"失败原因"回退到规划者重规划；超过重规划上限则转人工兜底，不能死循环。
按领域拆子 Agent：江旭案例证明，按尽调维度拆 6 个子 Agent，每个可独立优化、独立评测，比一个巨型 Agent 更易迭代。
可控性是 Multi-Agent 相对单 Agent 的最大价值：分角色 + 规则审核 + 兜底，是金融/合规等高风险场景"敢上线"的前提。
代价要正视：Multi-Agent 的编排复杂度、Token 成本、延迟都高于单 Agent，简单查询用它是过度设计——应配合意图分类器（见 ReAct vs Plan-and-Execute）动态选用。

本节相关题目¶

难度	题目	链接
基础	Multi-Agent 相比单 Agent 的优势与代价	→ 题库
进阶	规划者-执行者-审核者架构、审核者规则引擎覆盖维度	→ 题库
深度	设计 Agent 平台如何落地 Multi-Agent + 审核闭环	→ 题库