从单兵作战到军团协作：多智能体 AI Agent 开发实战指南

🔥个人主页：北极的代码（欢迎来访）

🎬作者简介：java后端学习者

❄️个人专栏：苍穹外卖日记，SSM框架深入，JavaWeb

✨命运的结局尽可永在，不屈的挑战却不可须臾或缺！
当一个大模型不够用时，让一群智能体"组队开黑"

引子：为什么需要一支AI军团

如果你已经玩过单智能体 AI Agent ------ 比如一个能查天气、设闹钟、订机票的助手，你可能已经遇到几个头疼的问题：

• 上下文爆炸：一个 Agent 要记住用户的所有意图、历史对话、工具调用结果，Token 消耗像喝水

• 职责不清：让同一个 Agent 既写代码又做测试，它要么偏科，要么陷入"我到底是开发还是 QA"的精神分裂

• 脆弱性：一个环节出错，整个流程直接崩盘，毫无容错可言

答案很直接：从单兵作战转向多智能体协作。

这不是把任务拆得更碎，而是引入一套智能体分工 + 通信 + 调度 的架构范式。今天这篇实战指南，会直接带你从单体 Agent 演进到一个最小可用的多智能体系统，并给出可运行的代码骨架。

---

文章摘要：本文探讨了从单智能体转向多智能体协作系统的必要性，指出单智能体在复杂任务中存在的上下文爆炸、职责不清和脆弱性等问题。通过引入多智能体系统（MAS）的角色分工、通信和控制流设计，作者演示了如何构建一个包含Writer、Reviewer和Editor的最小可用多智能体系统，并提供代码骨架。文章还介绍了进阶协作模式（如投票、任务分解和辩论），并总结了多智能体开发的常见陷阱与适用场景。最后指出，多智能体系统通过分工协作可解决单模型难以处理的长程、多视角任务，未来将向动态自组织方向发展。

---

一、核心概念：不是多个 Agent，而是一个整体

多智能体系统（MAS，Multi-Agent System）不是简单跑 N 个 Agent 副本，而是包含三个关键设计：

1. 角色（Role）：每个 Agent 有明确职责边界。如 Planner、Executor、Reviewer、Critic。

2. 通信（Communication）：Agent 之间通过结构化消息交换信息，而非共享全局内存。

3. 控制流（Control Flow）：由编排层决定何时调用哪个 Agent，是顺序、并行、投票还是辩论。

常见的几种协作模式：

模式	描述	适用场景
链式（Chain）	A → B → C 顺次执行	固定流水线，如代码生成→测试→修复
层级（Hierarchy）	主管 Agent 拆解任务分派给子 Agent	复杂项目规划与执行
协商（Negotiation）	多个 Agent 竞标/投票决定下一步	开放性决策，多方案评估
循环（Loop）	多轮"执行-批判-修正"	代码调试、内容润色

关键认知：多智能体的价值在于分工带来的鲁棒性与可扩展性，而非盲目提升单次任务质量。

---

二、从零搭建一个多智能体系统（代码实战）

技术选型

• LangGraph（LangChain 生态）：天然支持多节点图编排，比 LangChain Agent 更适合复杂控制流。

• OpenAI API（或本地模型如 Qwen/Llama 3）

• 环境变量：OPENAI_API_KEY

2.1 定义智能体角色

python

from typing import TypedDict, List
from langgraph.graph import StateGraph, END
from langchain_openai import ChatOpenAI

# 共享状态（通信协议）
class AgentState(TypedDict):
    topic: str
    draft: str
    review: str
    revised_article: str
    final: str
    iteration: int

# 三个专用 Agent（用 system prompt 固化角色）
writer = ChatOpenAI(model="gpt-4o", temperature=0.7).bind(
    system_message="你是一名技术博主，擅长写清晰、有深度、带实战代码的多智能体技术文章。"
)

reviewer = ChatOpenAI(model="gpt-4o", temperature=0.3).bind(
    system_message="你是一位严格的资深技术主编，擅长抓逻辑漏洞、结构混乱、表达晦涩。输出格式：优点、问题清单、修改建议。"
)

editor = ChatOpenAI(model="gpt-4o", temperature=0.5).bind(
    system_message="你是一名执行编辑，根据评审意见修改文章，保留原意的同时提升可读性和专业性。"
)

2.2 定义节点函数（每个 Agent 的工作逻辑）

python

async def write_node(state: AgentState):
    prompt = f"请根据以下主题撰写一篇技术博客初稿：{state['topic']}"
    draft = await writer.ainvoke(prompt)
    return {"draft": draft.content}

async def review_node(state: AgentState):
    prompt = f"请对以下文章进行评审：\n{state['draft']}"
    review = await reviewer.ainvoke(prompt)
    return {"review": review.content}

async def revise_node(state: AgentState):
    prompt = f"原文：\n{state['draft']}\n\n评审意见：\n{state['review']}\n\n请根据意见修改成最终版。"
    revised = await editor.ainvoke(prompt)
    return {"revised_article": revised.content}

def should_continue(state: AgentState):
    # 简单控制：最多修改两轮，或当评审意见中无"重大修改"标记时退出
    if state["iteration"] >= 2 or "无需进一步修改" in state.get("review", ""):
        return "finalize"
    return "revise"

2.3 构建图工作流

python

builder = StateGraph(AgentState)

builder.add_node("writer", write_node)
builder.add_node("reviewer", review_node)
builder.add_node("editor", revise_node)
builder.add_node("finalizer", lambda s: {"final": s["revised_article"]})

builder.set_entry_point("writer")
builder.add_edge("writer", "reviewer")
builder.add_conditional_edges("reviewer", should_continue, {
    "revise": "editor",
    "finalize": "finalizer"
})
builder.add_edge("editor", "reviewer")  # 形成审校循环
builder.add_edge("finalizer", END)

app = builder.compile()

2.4 执行

python

async def run_team(topic: str):
    result = await app.ainvoke({
        "topic": topic,
        "draft": "",
        "review": "",
        "revised_article": "",
        "iteration": 0
    })
    print(result["final"])

运行后，你会看到：

Writer 写初稿 → Reviewer 挑刺 → Editor 改稿 → Reviewer 再次审查 → 最终定稿。

这就是一个多角色协作闭环。

---

三、进阶模式：让智能体学会开会

上面的链式模式比较简单。更高级的协作方式包括：

3.1 投票表决（Voting）

适用场景：多个专家 Agent 对某方案打分，仲裁 Agent 选择最优。

python

async def vote_node(state):
    experts = [expert1, expert2, expert3]  # 三个不同侧面的评审
    votes = await asyncio.gather(*[e.ainvoke(state["candidate"]) for e in experts])
    # 仲裁逻辑
    best = max(votes, key=lambda v: v.score)
    return {"selected": best}

3.2 任务分解与并行执行（Map-Reduce）

适用：数据分析、批量测试、多源信息检索。

python

# Planner: 将"分析过去一年销售数据"拆成四个季度子任务
# Workers: 并行执行
# Aggregator: 汇总生成年度报告

LangGraph 原生支持 Send API 实现动态 fan-out。

3.3 辩论（Debate）

两个 Agent 持相反立场相互反驳，经过 N 轮后收敛到更可靠的结论。

这在事实核查、逻辑推理、决策支持中极其有效。

实现要点：

• 维护 positive_arg 和 negative_arg 两个通道

• 每轮交换"攻防角色"

• 终止条件：一方认输或轮次到达上限

---

四、避坑指南：多智能体开发的 5 个陷阱

陷阱	表现	解决方法
过度通信	Agent 间消息冗长，token 爆炸	用结构化输出（JSON Schema）+ 摘要中间结果
角色重叠	Writer 也在偷偷改格式	System Prompt 中明确角色边界，必要时用权限校验
无限循环	审评→修改→审评→修改......	强制最大迭代次数 + 收敛检测（如编辑距离变化 < 阈值）
单点脑裂	没有仲裁者，Agent 各说各话	引入 Supervisor Agent 或加权投票
调试困难	日志混乱，不知道谁对谁说了什么	给每个消息增加 agent_id、round、timestamp，用 LangSmith 或本地 tracer

---

五、什么时候不该用多智能体

多智能体不是银弹。以下情况请坚持单 Agent：

• 任务简单线性：单次调用 + 两三个工具就能搞定

• 强实时要求：多 Agent 往返通信增加 2~5 倍延迟

• 预算有限：多个大模型调用，成本线性增长

• 输出需高度一致：多 Agent 的多样性是优点也是缺点，对确定性要求极高的场景慎用

---

六、未来：从"我们编排 Agent"到"Agent 自组织"

目前的主流 MAS 仍是静态图 或有限状态机。下一步方向：

• 动态角色生成：根据任务自动实例化新 Agent

• 经济激励：Agent 之间用"任务积分"或"信用值"协调资源

• 反思型编排：Supervisor Agent 观察执行历史，动态调整后续协作策略

LangGraph 的 StateGraph 已经支持在运行中修改图结构，这为自组织打开了接口。

---

写在最后

多智能体系统不是让你去"取代"更强大的单一模型，而是让你用一群中等能力的模型，通过分工与协作，解决单个超强模型也搞不定的长程、多视角、高容错任务。

从今天开始，给你的 AI 找个搭档，而不是只让它单打独斗。

下一期预告：《当 Agent 学会互相质疑：用辩论机制提升 RAG 准确率》