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

个人主页北极的代码欢迎来访作者简介java后端学习者❄️个人专栏苍穹外卖日记SSM框架深入JavaWeb✨命运的结局尽可永在不屈的挑战却不可须臾或缺当一个大模型不够用时让一群智能体“组队开黑”引子为什么需要一支AI军团如果你已经玩过单智能体 AI Agent —— 比如一个能查天气、设闹钟、订机票的助手你可能已经遇到几个头疼的问题上下文爆炸一个 Agent 要记住用户的所有意图、历史对话、工具调用结果Token 消耗像喝水职责不清让同一个 Agent 既写代码又做测试它要么偏科要么陷入“我到底是开发还是 QA”的精神分裂脆弱性一个环节出错整个流程直接崩盘毫无容错可言答案很直接从单兵作战转向多智能体协作。这不是把任务拆得更碎而是引入一套智能体分工 通信 调度的架构范式。今天这篇实战指南会直接带你从单体 Agent 演进到一个最小可用的多智能体系统并给出可运行的代码骨架。文章摘要本文探讨了从单智能体转向多智能体协作系统的必要性指出单智能体在复杂任务中存在的上下文爆炸、职责不清和脆弱性等问题。通过引入多智能体系统MAS的角色分工、通信和控制流设计作者演示了如何构建一个包含Writer、Reviewer和Editor的最小可用多智能体系统并提供代码骨架。文章还介绍了进阶协作模式如投票、任务分解和辩论并总结了多智能体开发的常见陷阱与适用场景。最后指出多智能体系统通过分工协作可解决单模型难以处理的长程、多视角任务未来将向动态自组织方向发展。一、核心概念不是多个 Agent而是一个整体多智能体系统MASMulti-Agent System不是简单跑 N 个 Agent 副本而是包含三个关键设计角色Role每个 Agent 有明确职责边界。如 Planner、Executor、Reviewer、Critic。通信CommunicationAgent 之间通过结构化消息交换信息而非共享全局内存。控制流Control Flow由编排层决定何时调用哪个 Agent是顺序、并行、投票还是辩论。常见的几种协作模式模式描述适用场景链式ChainA → B → C 顺次执行固定流水线如代码生成→测试→修复层级Hierarchy主管 Agent 拆解任务分派给子 Agent复杂项目规划与执行协商Negotiation多个 Agent 竞标/投票决定下一步开放性决策多方案评估循环Loop多轮“执行-批判-修正”代码调试、内容润色关键认知多智能体的价值在于分工带来的鲁棒性与可扩展性而非盲目提升单次任务质量。二、从零搭建一个多智能体系统代码实战技术选型LangGraphLangChain 生态天然支持多节点图编排比 LangChain Agent 更适合复杂控制流。OpenAI API或本地模型如 Qwen/Llama 3环境变量OPENAI_API_KEY2.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(modelgpt-4o, temperature0.7).bind( system_message你是一名技术博主擅长写清晰、有深度、带实战代码的多智能体技术文章。 ) reviewer ChatOpenAI(modelgpt-4o, temperature0.3).bind( system_message你是一位严格的资深技术主编擅长抓逻辑漏洞、结构混乱、表达晦涩。输出格式优点、问题清单、修改建议。 ) editor ChatOpenAI(modelgpt-4o, temperature0.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 revise2.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, keylambda v: v.score) return {selected: best}3.2 任务分解与并行执行Map-Reduce适用数据分析、批量测试、多源信息检索。python # Planner: 将分析过去一年销售数据拆成四个季度子任务 # Workers: 并行执行 # Aggregator: 汇总生成年度报告LangGraph 原生支持SendAPI 实现动态 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 准确率》