跳到主要内容

Multi-Agent基础

1. 定义与边界​

多 Agent 系统（Multi-Agent System）是由多个具备相对独立目标、上下文、工具权限或运行状态的 Agent 组成的协同系统。这里的 Agent 可以是 LLM Agent、规则节点、工作流节点、外部服务代理，也可以是另一个远程 Agent 系统。

多 Agent 不等于：

  • 多个 prompt 模板。只有 prompt 不同但共享全部上下文、工具和权限时，本质上仍是单 Agent 的动态配置。
  • 多轮链式调用。串行步骤如果没有独立职责和可观测边界，更接近 workflow。
  • 一定更聪明。多个模型实例会增加互相误导、重复调用和裁决错误的可能。

工程上更有用的定义是：多 Agent 是把复杂任务拆成可独立观测、可独立评测、可独立限权的执行单元，并通过协议或编排层进行协作。

2. 为什么重要​

单 Agent 的常见瓶颈包括：

瓶颈多 Agent 可能带来的收益代价
上下文过大让每个 Agent 只看必要信息需要上下文裁剪和状态同步
工具过多按职责隔离工具集合路由错误会导致漏调或误调
专业能力冲突使用不同角色、模型或提示需要统一输出协议
可并行子任务并发检索、分析、验证成本和汇总复杂度增加
权限差异高风险操作由专门 Agent 处理权限边界和审计必须更严格

LangChain 官方文档也强调，并非所有复杂任务都需要多 Agent；很多时候单 Agent 加动态工具、技能加载或规则路由即可满足需求。这个判断应成为多 Agent 设计的前置门槛。

3. 核心机制​

多 Agent 系统通常由五类机制组成：

  1. 编排（Orchestration）：决定谁先执行、谁接管、谁裁决、何时结束。
  2. 通信（Communication）：传递消息、任务、状态、artifact、工具结果或 trace。
  3. 状态（State）：保存共享任务状态、各 Agent 私有状态、预算、权限和历史。
  4. 隔离（Isolation）：隔离上下文、工具、凭据、文件系统和网络访问。
  5. 观测（Observability）：记录 Agent 调用、LLM 调用、工具调用、handoff、guardrail 和人工审批。

一个最小 Agent 协同状态可以这样描述：

{
  "task_id": "task_20260509_001",
  "goal": "生成季度经营分析报告",
  "active_agent": "planner",
  "agents": {
    "planner": { "status": "done", "budget_tokens": 8000 },
    "researcher": { "status": "running", "allowed_tools": ["search", "kb_query"] },
    "writer": { "status": "blocked", "waiting_for": "research_summary" }
  },
  "shared_artifacts": [
    { "id": "outline_v1", "type": "markdown", "owner": "planner" }
  ],
  "risks": [
    { "type": "external_content", "severity": "medium", "control": "quote_and_verify" }
  ]
}

4. 架构模式​

常见模式：

模式机制适用场景
Supervisor中央 Agent 或规则节点调度子 Agent需要集中控制、审计和汇总
Handoff当前 Agent 通过工具调用或状态切换把控制权交给另一个 Agent客服、流程状态机、多轮领域切换
Debate多个 Agent 独立作答、互评、裁决高风险判断、推理题、事实核对
SwarmAgent 可动态互相转交，形成松耦合网络开放式探索、未知路径任务
Pipeline固定顺序执行文档处理、ETL、生成后审核
Fan-out / Gather并发分发再汇总多源检索、多方案生成、批量评审

5. 工程实现​

多 Agent 实现不要从“角色扮演”开始，而要先定义接口。

from dataclasses import dataclass
from typing import Any, Literal

@dataclass
class AgentInput:
    task_id: str
    instruction: str
    context: dict[str, Any]
    artifacts: list[str]
    budget: dict[str, int]

@dataclass
class AgentOutput:
    status: Literal["done", "need_input", "handoff", "failed"]
    summary: str
    artifacts: list[str]
    next_agent: str | None
    confidence: float
    risks: list[dict[str, Any]]

class Agent:
    name: str
    allowed_tools: list[str]

    async def run(self, data: AgentInput) -> AgentOutput:
        ...

最小编排循环：

async def run_multi_agent(task):
    state = init_state(task)
    while not state.done:
        agent = registry[state.active_agent]
        check_budget(state, agent)
        check_permissions(state, agent)

        output = await agent.run(build_input(state, agent))
        append_trace(state, agent.name, output)
        apply_artifacts(state, output.artifacts)
        update_risks(state, output.risks)

        if output.status == "handoff":
            state.active_agent = output.next_agent
        elif output.status == "need_input":
            return request_human_input(state, output)
        elif output.status == "failed":
            state.active_agent = recovery_policy(state, output)
        else:
            state.done = termination_policy(state)
    return finalize(state)

实现要点：

  • Agent registry：声明每个 Agent 的职责、输入 schema、输出 schema、工具、预算和权限。
  • State store：保存共享状态和私有状态，避免只依赖聊天历史。
  • Artifact store：保存文件、表格、代码、检索结果和中间产物。
  • Policy engine：在工具调用、handoff、高风险动作前做权限判断。
  • Trace store：记录每次模型调用、工具调用、handoff、错误和人工确认。

6. 生产实践​

  • 把 Agent 边界设计成服务接口，而不是 prompt 文件边界。
  • 对每个 Agent 设置最大轮数、最大工具调用数、最大 token、最大花费和超时。
  • 对外部工具和高权限工具使用最小权限凭据。
  • 对共享状态做版本号和乐观锁，避免并发写覆盖。
  • 对关键路径保留可回放 trace，支持离线复盘。
  • 对失败设置降级：规则路由、单 Agent 路径、人工接管、只读模式。
  • 对长任务使用任务队列和 checkpoint，不要把所有中间状态塞进模型上下文。

7. 常见反模式​

反模式问题修正
为了显得高级而拆多个 Agent成本和调试复杂度上升先做单 Agent baseline
每个 Agent 都能调用所有工具权限边界失效按职责最小授权
只传完整聊天历史上下文污染和泄漏传结构化摘要和必要 artifact
无终止条件Agent 互相循环交接设置轮数、预算、状态机
无裁决规则多个结论互相矛盾定义仲裁、置信度、证据标准
用模型做所有路由路由不稳定且成本高优先规则和轻量分类器，必要时再用 LLM

8. 评测方法​

多 Agent 评测至少分四层：

层级指标
任务结果任务成功率、准确率、人工验收通过率
协同质量路由准确率、handoff 成功率、冲突解决率
过程质量工具调用准确率、无效调用数、重试次数、trace 完整率
资源成本token、模型调用次数、延迟、并发资源、单位成功成本

评测时要和单 Agent baseline 比较。只有当多 Agent 在成功率、可维护性、权限隔离或并行速度上带来足够收益，才值得保留。

9. 安全与治理​

多 Agent 增加了攻击面：

  • 恶意外部内容可影响 Research Agent，再污染 Planner 或 Writer。
  • 工具描述、MCP server 或远程 Agent 的返回内容可能包含提示注入。
  • 一个低权限 Agent 可能通过 handoff 诱导高权限 Agent 执行动作。
  • 多 Agent 共享状态可能导致敏感信息越权传播。

控制措施：

  • 所有外部内容进入共享状态前标注来源和可信等级。
  • 高权限 Agent 不接受低权限 Agent 的自由文本命令，只接受结构化请求。
  • 关键动作必须有人类在环或策略引擎审批。
  • Trace 默认避免记录敏感数据，或对敏感字段脱敏。
  • 远程 Agent 和工具必须有 allowlist、认证、授权和审计。

10. 工程手册补充​

多 Agent 的默认决策应是“不拆，除非证据足够”。上线前先回答四个问题：

问题通过标准不通过时的替代方案
单 Agent baseline 是否失败有真实评测数据证明瓶颈优化工具描述、RAG、状态机
拆分边界是否稳定角色输入输出和工具权限可写成 contract使用 workflow 节点
通信是否结构化消息 schema、artifact 引用、错误码明确暂时保留单 Agent
成本是否可控单位成功成本优于 baseline 或换来安全隔离限制 fan-out、加缓存

上线清单：

  • 每个 Agent 有 owner、权限、输入输出、SLO、预算、失败责任。
  • 所有通信使用结构化消息和 artifact 引用，不用“转述式聊天记录”作为唯一状态。
  • 冲突解决规则先于上线定义：谁裁决、按什么证据、如何升级人工。
  • 监控除最终成功率外，还要看 handoff 次数、冲突率、重复工作率、单位成功成本。
  • 安全上按最小权限拆工具，不因“需要协作”共享全部上下文。

11. 权威资料​