1. 从单打独斗到团队作战为什么需要多智能体1.1 单智能体的天花板在哪里刚开始接触 Agent 开发的时候大多数人的路径都差不多写一个 System Prompt挂几个 Tool接上大模型跑通一个能查天气、能搜网页、能写代码的助手就觉得已经摸到了门槛。我最初做第一个 Agent 项目时也是这个心态一个 Agent 包打天下用户问什么它答什么需要搜索就调搜索工具需要计算就调计算器看起来什么都能干。但项目稍微复杂一点问题就全暴露出来了。最典型的场景是“帮我调研一下某个行业然后写一份分析报告”。单 Agent 处理这个任务时它要同时扮演调研员、分析师、写作者三个角色。结果就是搜索的时候它想着要写报告写报告的时候又发现调研不够充分来回反复Token 消耗巨大不说输出质量还很不稳定。更麻烦的是当任务链路变长单 Agent 的上下文窗口会被各种中间结果塞满早期获取的关键信息被后来的内容挤到边缘模型开始“遗忘”前面做过什么。这不是模型能力的问题而是架构的问题。一个 Agent 的上下文是线性的它没有办法像人类团队那样“各司其职、各记各的账”。你让一个人同时做市场调研、数据分析和报告撰写他也会手忙脚乱更何况是上下文有限的模型。单 Agent 的另一个硬伤是错误累积。当所有步骤都在一个 Agent 里串行执行时前一步的偏差会直接污染后续所有步骤。搜索关键词选偏了后面的分析全建立在错误信息上分析逻辑错了报告写得再漂亮也是废纸。而且你很难定位问题出在哪一环因为所有步骤的日志都混在一起。1.2 多智能体到底解决了什么问题多智能体的核心思路其实很朴素把一个大任务拆成若干子任务每个子任务交给专门的 Agent 负责Agent 之间通过明确的协议协作。这就像公司里做项目不会让一个人从调研到交付全包而是分成产品、开发、测试、运营几个角色各管一摊通过文档和会议同步进度。具体来说多智能体架构带来三个关键收益。第一是上下文隔离。每个 Agent 只关心自己那一部分信息调研 Agent 的上下文里全是搜索资料写作 Agent 的上下文里全是素材和提纲互不干扰。这直接解决了单 Agent 上下文爆炸的问题也让每个 Agent 的 Prompt 可以写得更聚焦、更精准。第二是专业化分工。你可以给调研 Agent 配最强的搜索工具和网页解析能力给写作 Agent 配最好的文风控制 Prompt给审核 Agent 配严格的检查清单。每个 Agent 在自己的领域内做到极致整体效果自然比一个“万金油” Agent 强。第三是可观测与可干预。多智能体系统里每个 Agent 的输入输出都是独立的你可以清楚地看到调研 Agent 返回了什么、写作 Agent 基于什么写的、审核 Agent 挑出了什么问题。哪个环节出问题就修哪个环节不用推倒重来。当然多智能体不是银弹。它引入了新的复杂度Agent 之间怎么通信、任务怎么分配、冲突怎么解决、成本怎么控制。这些问题如果处理不好多智能体系统可能比单 Agent 还难用。所以接下来我会重点讲清楚角色分工和协作机制这两件事这也是整个架构能不能跑通的关键。1.3 这篇文章适合谁来读如果你已经写过一个能跑的单 Agent想把它升级成多 Agent 协作系统这篇文章就是为你准备的。我会用 LangGraph 作为编排框架来演示因为它在状态管理和流程控制上做得比较成熟社区资料也多。但核心思路不绑定任何框架你用 LangChain、CrewAI 或者自己手写调度器都能落地。如果你还没接触过 Agent 开发建议先补一下基础概念什么是 Tool Calling、什么是 ReAct 循环、Prompt 怎么写。这些是前置知识本文不会从头讲。另外说明一下本文的代码示例以 Python 为主但角色分工和协作机制的设计思路是语言无关的你用 TypeScript 或 Java 实现同样适用。2. 角色分工怎么拆任务、怎么定角色2.1 任务拆解的基本原则多智能体的第一步不是写代码而是拆任务。拆得好后面顺风顺水拆得不好Agent 之间互相甩锅系统跑不起来。我踩过的最大坑是“按功能拆”而不是“按职责拆”。举个例子做代码审查系统我一开始拆成“读代码 Agent”“找 Bug Agent”“写报告 Agent”。听起来合理但实际跑起来发现读代码 Agent 读完代码传给找 Bug Agent找 Bug Agent 发现需要看更多上下文又回头找读代码 Agent来回通信开销巨大。后来我改成按职责边界拆一个 Agent 负责“理解代码结构和意图”一个 Agent 负责“基于理解结果做缺陷检测”一个 Agent 负责“汇总检测结果并生成可读报告”。每个 Agent 的输入输出都是明确的、自包含的不需要频繁回头。所以任务拆解的核心原则是每个 Agent 应该是一个“无状态”的处理单元给它确定的输入它产出确定的输出不需要依赖其他 Agent 的中间状态。如果两个 Agent 需要频繁来回通信才能完成一件事那它们大概率应该合并成一个 Agent。另一个原则是粒度适中。拆得太粗等于没拆拆得太细通信成本超过收益。我的经验是一个 Agent 的职责用一句话能说清楚且这句话里不包含“然后”“接着”这类连接词粒度就差不多了。比如“搜索并整理某主题的资料”可以是一个 Agent“先搜索再整理”就应该拆成两个。2.2 常见角色类型与职责定义在实际项目中我总结出几类高频出现的角色你可以根据任务需要组合使用。规划者Planner负责把用户需求拆成可执行的步骤列表。它的输出通常是一个任务清单每个任务标明由谁执行、依赖哪些前置任务。规划者不需要很强的工具调用能力但需要很强的逻辑推理和任务分解能力。Prompt 里要强调“输出结构化的步骤列表每步包含目标、输入、预期输出”。执行者Executor负责具体干活比如搜索、计算、调 API、写代码。执行者通常需要挂载工具Prompt 要聚焦在“如何用好工具完成当前步骤”。执行者的输入应该是规划者给出的单个步骤而不是整个任务这样才能保持上下文干净。审核者Reviewer负责检查执行者的输出质量。审核者的 Prompt 要包含明确的检查清单比如“检查事实准确性、检查逻辑一致性、检查格式规范”。审核者的输出应该是“通过”或“不通过 具体问题”而不是直接修改内容修改交给执行者或专门的修订者。汇总者Aggregator负责把多个执行者的输出合并成最终结果。汇总者的难点在于处理冲突比如两个执行者给出了矛盾的信息。Prompt 里要明确冲突处理策略比如“以权威来源为准”“以最新时间为准”或“标注冲突并说明”。这四类角色不是必须全有简单任务可能只需要执行者 汇总者复杂任务可以加规划者和审核者。关键是每个角色的职责边界要清晰不能重叠。2.3 用 LangGraph 定义角色节点LangGraph 里每个 Agent 就是一个节点Node节点之间通过边Edge连接。定义角色的过程就是把上面说的职责翻译成节点函数。先看一个最简的角色定义from langgraph.graph import StateGraph, END from typing import TypedDict, Annotated import operator class AgentState(TypedDict): task: str plan: list[str] research_results: Annotated[list[str], operator.add] draft: str review_feedback: str final_output: str def planner_node(state: AgentState): task state[task] # 调用 LLM 生成计划 plan llm.invoke(f把以下任务拆成步骤列表{task}) return {plan: plan} def researcher_node(state: AgentState): # 取当前未完成的调研步骤 step state[plan][0] result search_tool.invoke(step) return {research_results: [result]} def writer_node(state: AgentState): materials \n.join(state[research_results]) draft llm.invoke(f基于以下素材写报告{materials}) return {draft: draft} def reviewer_node(state: AgentState): draft state[draft] feedback llm.invoke(f检查以下报告的问题{draft}) return {review_feedback: feedback}这里有几个关键点。AgentState是整个图的共享状态所有节点读写同一个状态对象。Annotated[list[str], operator.add]表示这个字段是累加的多个节点往里面追加内容不会覆盖。这是 LangGraph 里处理多 Agent 输出汇总的标准做法。每个节点函数接收完整状态但只返回自己修改的字段。LangGraph 会自动合并。这种设计让节点之间解耦你改一个节点的逻辑不影响其他节点。2.4 角色定义的注意事项Prompt 要写“角色边界”。我见过很多项目Agent 的 Prompt 只写了“你是一个调研助手”但没写“你只负责调研不要写报告不要做分析”。结果调研 Agent 自作主张把分析也做了写作 Agent 拿到的是半成品反而更乱。所以 Prompt 里一定要明确“你做什么”和“你不做什么”。工具权限要隔离。调研 Agent 只给搜索工具写作 Agent 只给文本生成能力审核 Agent 不给任何修改工具只能输出意见。这样从机制上防止 Agent 越权。LangGraph 里可以通过给不同节点绑定不同的 Tool 列表来实现。输出格式要强制。每个 Agent 的输出最好用结构化格式JSON、XML 或 Markdown 模板方便下游 Agent 解析。我通常会在 Prompt 末尾加一句“输出必须符合以下 JSON Schema”然后用 LangChain 的 StructuredOutputParser 做校验。格式不对就重试避免脏数据流入下游。角色数量不要贪多。我试过一个任务拆了 7 个 Agent结果调试成本极高而且很多 Agent 的职责其实可以合并。后来精简到 4 个效果反而更好。经验值是一个多智能体系统里核心角色控制在 3 到 5 个超过 5 个就要重新审视是否拆得太细。3. 协作机制Agent 之间怎么通信和协调3.1 通信模式共享状态 vs 消息传递多智能体协作的第一件事是确定通信模式。主流有两种共享状态和消息传递。共享状态就像一块白板所有 Agent 都能读写。LangGraph 默认就是这种模式AgentState就是那块白板。优点是简单直接Agent 不需要知道其他 Agent 的存在只管读写状态就行。缺点是状态会越来越大而且并发写入时可能冲突。消息传递就像发微信Agent 之间直接发消息。CrewAI 用的是这种模式每个 Agent 有明确的“收件人”。优点是通信路径清晰容易追踪谁给谁发了什么。缺点是需要维护消息路由Agent 数量多了之后消息图会变得很复杂。我的选择是中小规模系统用共享状态大规模系统用消息传递。LangGraph 在共享状态基础上也支持消息传递通过SendAPI可以混合使用。比如规划者和执行者之间用共享状态传递任务列表执行者之间用消息传递同步进度。实际项目里我通常这样设计状态结构class CollaborativeState(TypedDict): # 全局信息 task: str plan: list[dict] # 每项包含 step_id, description, assignee, status # 各 Agent 的产出 research_output: Annotated[list[str], operator.add] analysis_output: Annotated[list[str], operator.add] draft_output: str # 协作控制 current_step: int messages: Annotated[list[dict], operator.add] # Agent 间消息 errors: Annotated[list[str], operator.add]plan字段是任务分配的核心每个步骤标明谁负责、状态如何。messages字段记录 Agent 之间的通信方便调试。errors字段收集异常避免一个 Agent 失败导致整个系统崩溃。3.2 任务分配谁来决定谁干什么任务分配有两种模式中心化分配和去中心化协商。中心化分配是有一个“调度者”角色它看全局状态决定下一步该谁干。LangGraph 里的条件边Conditional Edge就是干这个的。比如def route_next(state: CollaborativeState): plan state[plan] for step in plan: if step[status] pending: return step[assignee] return aggregator graph.add_conditional_edges( planner, route_next, { researcher: researcher, analyst: analyst, writer: writer, aggregator: aggregator } )这段代码的意思是规划者完成后检查计划里第一个未完成的步骤把控制权交给对应的 Agent。这种模式逻辑清晰容易调试适合大多数场景。去中心化协商是 Agent 之间自己商量谁干。比如一个 Agent 说“我需要数据分析”另一个 Agent 说“我来做”。这种模式更灵活但容易出现死锁或重复劳动。我一般只在 Agent 能力高度重叠、需要动态负载均衡时才用。实际项目里我推荐中心化分配为主局部去中心化为辅。主流程用条件边控制个别需要动态决策的环节比如“这个任务该给搜索 Agent 还是数据库 Agent”让 Agent 自己判断。3.3 冲突解决与一致性保障多智能体系统里冲突是常态。两个 Agent 给出矛盾结论、多个 Agent 同时想写同一个字段、一个 Agent 的输出格式不符合下游要求这些都会导致系统卡住。冲突类型一结论矛盾。调研 Agent 说“市场规模 100 亿”分析 Agent 说“根据我的计算是 80 亿”。解决方式是引入仲裁者角色它的 Prompt 里写明冲突处理规则“如果两个来源数据矛盾优先采用权威来源如果权威性相同标注两个数据并说明差异”。仲裁者的输出是最终结论下游 Agent 只认仲裁结果。冲突类型二写入冲突。两个 Agent 同时往draft_output写内容后写的覆盖先写的。解决方式是字段隔离每个 Agent 写自己的字段最后由汇总者合并。比如research_draft和analysis_draft分开汇总者负责拼成final_draft。冲突类型三格式不匹配。上游 Agent 输出自由文本下游 Agent 期望 JSON。解决方式是在边上加校验节点。LangGraph 里可以在两个节点之间插入一个轻量节点专门做格式转换和校验。校验不通过就返回上游重做或者调用一个“修复 Agent”做格式转换。我通常会在状态里加一个validation_errors字段校验节点把问题写进去上游 Agent 下次执行时能看到自己的输出哪里不合格自动修正。这比直接抛异常友好得多。3.4 循环与终止条件设计多智能体系统最容易失控的地方是循环。审核者说“不通过”执行者改完再提交审核者又说“不通过”无限循环。或者两个 Agent 互相等待对方先行动死锁。终止条件一最大迭代次数。给每个循环加一个计数器超过阈值就强制退出。比如审核循环最多 3 次3 次还不通过就交给人工处理或直接输出当前最佳版本。def should_continue_review(state: CollaborativeState): if state[review_feedback] 通过: return aggregator if state[review_count] 3: return aggregator # 强制通过标注未解决 return writer # 打回重写终止条件二状态收敛。如果连续两轮状态没有实质变化说明系统卡住了应该退出。实现方式是比较前后两轮的状态哈希相同就终止。终止条件三超时。给整个图设置最大执行时间超时抛异常。LangGraph 支持在compile时设置interrupt_after或自定义超时逻辑。我的经验是任何循环都必须有至少两个终止条件一个是正常退出任务完成一个是异常退出迭代超限或超时。只靠正常退出系统迟早会卡死。3.5 Human-in-the-Loop 的接入点多智能体系统不是完全 autonomous 就好关键决策点需要人工介入。LangGraph 提供了interrupt机制可以在指定节点前暂停等人工确认后再继续。常见的介入点有三个。规划确认规划者给出任务列表后人工确认是否合理避免方向性错误。关键决策涉及敏感操作比如发邮件、改数据库前人工确认。最终审核系统输出最终结果前人工做最后把关。from langgraph.checkpoint import MemorySaver checkpointer MemorySaver() graph builder.compile( checkpointercheckpointer, interrupt_before[send_email, update_database] )这样配置后执行到send_email节点前会暂停人工调用graph.update_state确认后才继续。这个机制在生产环境里非常重要我见过太多因为 Agent 自动执行了不该执行的操作而翻车的案例。4. 实操落地从零搭一个多智能体协作系统4.1 环境准备与依赖安装先明确技术栈Python 3.10、LangGraph、LangChain、OpenAI SDK或其他模型 SDK。安装命令pip install langgraph langchain langchain-openai python-dotenv如果你用其他模型把langchain-openai换成对应的包即可。环境变量里配好 API KeyOPENAI_API_KEYyour_key_here我建议用python-dotenv管理环境变量避免 Key 硬编码在代码里。另外装一个rich库用来在终端里漂亮地打印 Agent 之间的消息流调试时非常有用。pip install rich4.2 定义状态与角色节点我们做一个“行业调研报告生成”系统包含四个角色规划者、调研者、写作者、审核者。先定义状态from typing import TypedDict, Annotated import operator class ReportState(TypedDict): topic: str plan: list[str] research: Annotated[list[str], operator.add] draft: str feedback: str review_count: int final_report: str然后定义四个节点函数。每个节点里调用 LLMPrompt 要写清楚角色边界。from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate llm ChatOpenAI(modelgpt-4o, temperature0) def planner(state: ReportState): prompt ChatPromptTemplate.from_messages([ (system, 你是一个任务规划专家。把用户给的调研主题拆成3-5个具体的调研子问题。 只输出子问题列表每行一个不要编号不要解释。), (user, 调研主题{topic}) ]) chain prompt | llm result chain.invoke({topic: state[topic]}) plan [line.strip() for line in result.content.split(\n) if line.strip()] return {plan: plan} def researcher(state: ReportState): # 取第一个未调研的子问题简化处理实际可用状态标记 query state[plan][len(state[research])] prompt ChatPromptTemplate.from_messages([ (system, 你是一个调研专家。针对给定问题输出一段200字以内的调研结论。 只输出结论不要写分析不要写建议。), (user, 调研问题{query}) ]) chain prompt | llm result chain.invoke({query: query}) return {research: [result.content]} def writer(state: ReportState): materials \n\n.join(state[research]) prompt ChatPromptTemplate.from_messages([ (system, 你是一个报告撰写专家。基于给定素材写一份结构清晰的调研报告。 报告包含背景、核心发现、结论。不要编造素材里没有的信息。), (user, 主题{topic}\n\n素材\n{materials}) ]) chain prompt | llm result chain.invoke({topic: state[topic], materials: materials}) return {draft: result.content} def reviewer(state: ReportState): prompt ChatPromptTemplate.from_messages([ (system, 你是一个严格的审核专家。检查报告的事实准确性、逻辑一致性、结构完整性。 如果通过只输出通过。如果不通过输出具体问题列表。), (user, 报告\n{draft}) ]) chain prompt | llm result chain.invoke({draft: state[draft]}) return {feedback: result.content, review_count: state[review_count] 1}注意researcher节点里用len(state[research])来判断当前该调研第几个问题。这是简化写法实际项目里应该在plan里加状态标记避免重复调研。4.3 编排图结构与条件边现在把节点连成图加上条件边控制流程。from langgraph.graph import StateGraph, END def route_after_plan(state: ReportState): return researcher def route_after_research(state: ReportState): if len(state[research]) len(state[plan]): return researcher # 还有子问题没调研完 return writer def route_after_review(state: ReportState): if state[feedback].strip() 通过: return finalize if state[review_count] 3: return finalize # 强制通过 return writer # 打回重写 def finalize(state: ReportState): return {final_report: state[draft]} builder StateGraph(ReportState) builder.add_node(planner, planner) builder.add_node(researcher, researcher) builder.add_node(writer, writer) builder.add_node(reviewer, reviewer) builder.add_node(finalize, finalize) builder.set_entry_point(planner) builder.add_conditional_edges(planner, route_after_plan, {researcher: researcher}) builder.add_conditional_edges(researcher, route_after_research, {researcher: researcher, writer: writer}) builder.add_edge(writer, reviewer) builder.add_conditional_edges(reviewer, route_after_review, {writer: writer, finalize: finalize}) builder.add_edge(finalize, END) graph builder.compile()这个图的结构是规划者 → 调研者循环直到所有子问题调研完→ 写作者 → 审核者不通过则打回写作者最多 3 次→ 最终输出。4.4 运行与调试跑起来看看result graph.invoke({ topic: 2024年新能源汽车市场趋势, plan: [], research: [], draft: , feedback: , review_count: 0, final_report: }) print(result[final_report])调试时我强烈建议把中间状态打出来。用rich库from rich.console import Console console Console() for event in graph.stream(initial_state): for node_name, node_output in event.items(): console.print(f[bold green]{node_name}[/bold green]) console.print(node_output) console.print(---)这样能看到每个节点的输入输出哪个环节出问题一目了然。我调试多智能体系统时80% 的时间都在看这个流而不是改代码。4.5 成本与性能优化多智能体系统的 Token 消耗通常是单 Agent 的 3 到 5 倍因为每个 Agent 都要带自己的 System Prompt 和上下文。优化手段有几个。Prompt 精简。每个 Agent 的 System Prompt 只保留必要信息不要把所有规则都塞进去。我见过一个项目的 System Prompt 写了 2000 字其中一半是重复的格式说明。精简后 Token 降了 40%。模型分级。规划者和审核者用强模型GPT-4o执行者用便宜模型GPT-4o-mini 或 Claude Haiku。执行者的任务通常更机械不需要最强推理能力。缓存。调研 Agent 的搜索结果可以缓存相同查询直接返回缓存结果。LangChain 有CacheBackedEmbeddings和SQLiteCache配置一下就能用。并行执行。如果多个调研子问题之间没有依赖可以并行跑。LangGraph 支持SendAPI 做并行分支from langgraph.constants import Send def continue_to_research(state: ReportState): return [Send(researcher, {query: q}) for q in state[plan]]这样所有子问题同时调研总耗时从串行的 N 倍降到 1 倍。但要注意并行写入research字段时的冲突用Annotated[list, operator.add]可以安全累加。5. 常见问题与排查技巧实录5.1 Agent 之间互相等待导致死锁现象系统卡住不动日志显示两个 Agent 都在等对方输出。原因条件边路由逻辑有环但没有终止条件。比如 A 等 B 的结果B 等 A 的结果形成循环依赖。解决检查条件边的路由函数确保每个循环都有退出路径。用review_count这类计数器强制退出。另外状态里加一个visited_nodes列表如果某个节点连续被访问超过 N 次直接跳到 END 并记录错误。5.2 输出格式不符合下游要求现象调研 Agent 返回自由文本写作者 Agent 期望 JSON解析失败。原因上游 Agent 的 Prompt 没有强制输出格式或者格式约束不够明确。解决在 Prompt 里加 JSON Schema 示例用 LangChain 的JsonOutputParser做校验。校验失败时自动重试重试 2 次还失败就调用一个“格式修复 Agent”做转换。我通常会在状态里加format_errors字段记录每次格式问题方便定位是哪个 Agent 的 Prompt 需要改。5.3 上下文过长导致模型截断现象写作者 Agent 收到的素材太长模型报context_length_exceeded。原因调研 Agent 输出太多累加到research字段后超过模型窗口。解决在调研 Agent 的 Prompt 里限制输出长度比如“200 字以内”。如果素材确实需要很长用摘要 Agent 先压缩再传给写作者。或者用支持长上下文的模型如 GPT-4o 的 128K 窗口。我的经验是每个 Agent 的输出控制在 500 字以内超过就拆成多个 Agent 或加摘要环节。5.4 审核循环不收敛现象审核者一直说“不通过”写作者改了 10 次还是不过。原因审核标准太模糊或者写作者能力不足以满足审核要求。解决审核者的 Prompt 要给出可操作的修改建议而不是只说“不好”。比如“第二段的数据来源不明确请补充引用”比“事实准确性不足”有用得多。另外设置最大迭代次数我一般设 3超过就输出当前最佳版本并标注“未完全通过审核”。5.5 常见问题速查表问题典型现象排查方向解决手段死锁系统卡住无新日志检查条件边是否有环无出口加计数器强制退出格式错误下游解析失败检查上游 Prompt 格式约束加 JSON Schema 校验和重试上下文超限模型报长度错误检查状态字段累积量限制单 Agent 输出长度加摘要审核不收敛循环次数过多检查审核标准是否可操作细化审核 Prompt设最大迭代成本过高Token 消耗异常检查各 Agent Prompt 长度精简 Prompt模型分级加缓存输出质量差最终结果不理想检查各环节输出质量逐节点调试定位薄弱环节5.6 独家避坑技巧技巧一先跑通单 Agent再拆多 Agent。不要一上来就设计多智能体架构。先用单 Agent 把任务跑通观察它在哪一步卡住、哪一步输出质量差然后针对性地拆。这样拆出来的多智能体系统才是有的放矢。技巧二给每个 Agent 加“自检”环节。Agent 输出前先自己检查一遍格式和内容不合格就重试。这比下游发现错误再打回效率高得多。实现方式是在 Prompt 末尾加“输出前请检查1. 格式是否符合要求 2. 内容是否完整 3. 是否有编造信息”。技巧三状态字段命名要带前缀。比如research_、draft_、review_这样在调试时一眼就能看出哪个字段是哪个 Agent 写的。我见过一个项目所有字段都是output1、output2调试时完全懵。技巧四用 LangSmith 做可观测。LangGraph 和 LangSmith 集成很好配一个 API Key 就能看到每个节点的完整调用链、Token 消耗、耗时。调试多智能体系统时可视化链路比看日志高效 10 倍。技巧五生产环境一定要加 Human-in-the-Loop。至少在两个地方加规划确认和最终输出确认。我见过太多 Agent 自动执行了错误操作导致数据污染的案例加个人工确认环节能避免 90% 的严重事故。5.7 从单 Agent 迁移到多 Agent 的检查清单如果你已经有一个单 Agent 系统想迁移到多智能体按这个清单逐项检查[ ] 单 Agent 的 Prompt 是否超过 1000 字如果是拆分的收益很大[ ] 任务是否有明显的阶段划分有的话按阶段拆 Agent[ ] 是否有多个工具需要不同权限有的话按工具权限拆 Agent[ ] 是否有环节需要人工介入有的话在该环节前加 interrupt[ ] 单 Agent 的上下文是否经常超限是的话必须拆[ ] 是否有环节的输出质量明显拖后腿针对该环节单独优化或拆出独立 Agent[ ] 整体 Token 成本是否可接受多 Agent 通常更贵要算账迁移时建议渐进式先拆出一个 Agent跑通后再拆第二个。不要一次性全拆否则出问题很难定位。6. 多智能体系统的扩展方向6.1 动态角色生成目前角色是硬编码的规划者、调研者、写作者都是预先定义好的。更高级的做法是根据任务动态生成角色。比如用户给一个“开发一个电商网站”的任务系统自动生成“前端 Agent”“后端 Agent”“数据库 Agent”“测试 Agent”。这需要规划者具备“角色设计”能力Prompt 里要让它输出“需要哪些角色、每个角色的职责、角色之间的依赖关系”。LangGraph 支持动态添加节点可以在运行时根据规划结果builder.add_node。但动态图的调试复杂度高我建议只在任务类型高度不确定的场景下用。6.2 Agent 记忆与经验复用当前每个 Agent 都是无状态的每次执行都从零开始。如果能让 Agent 记住历史执行中的经验下次遇到类似任务直接复用效率会大幅提升。实现方式有两种。短期记忆在状态里加history字段记录本次任务中每个 Agent 的执行结果后续 Agent 可以参考。长期记忆用向量数据库存历史任务的输入输出新任务来时先检索相似历史把相关经验注入 Prompt。我试过用 Chroma 做长期记忆效果不错。调研 Agent 遇到相似问题时直接返回历史调研结果省去重复搜索。但要注意记忆的时效性过时的信息要标记或淘汰。6.3 多智能体强化学习这是学术界的热点核心思路是让 Agent 通过试错学习最优协作策略。比如调研 Agent 和写作者 Agent 之间的通信频率、信息传递量可以通过强化学习优化。实际落地时我建议先从规则驱动开始把协作流程跑通收集足够的执行数据后再用强化学习做微调。直接上强化学习冷启动阶段会非常痛苦因为奖励信号稀疏Agent 很难学到有效策略。一个折中方案是基于反馈的 Prompt 优化记录每次执行中人工审核的意见把高频问题总结成规则反写回 Agent 的 Prompt。这比强化学习简单得多效果也立竿见影。6.4 多智能体系统的安全边界Agent 数量多了之后安全风险也放大。一个 Agent 被注入恶意 Prompt可能影响整个系统。防护手段包括输入过滤检查用户输入是否包含 Prompt 注入模式、权限最小化每个 Agent 只给必需的工具权限、输出审核关键操作前加审核 Agent、沙箱执行代码执行类 Agent 在隔离环境里跑。我在实际项目里会给每个 Agent 配一个“安全 Prompt”明确“不要执行以下操作删除数据、发送外部请求、修改系统配置”。虽然不能 100% 防住但能挡住大部分低级攻击。6.5 框架选型LangGraph vs 其他LangGraph 的优势是状态管理和流程控制精细适合复杂编排。缺点是学习曲线陡概念多State、Node、Edge、Checkpointer、Send。CrewAI 更简单角色和任务的定义很直观适合快速原型。但流程控制能力弱复杂条件分支不好表达。AutoGen 强在对话式协作Agent 之间自由聊天。适合探索性任务但生产环境里可控性差。我的建议是需要精细控制流程用 LangGraph快速验证想法用 CrewAI研究对话协作机制用 AutoGen。实际项目里也可以混用比如主流程用 LangGraph某个子环节用 CrewAI 的 Agent 做自由讨论。最后分享一个我在实际项目中的体会多智能体系统的难点不在“多”而在“协”。Agent 数量增加带来的边际收益递减很快3 个 Agent 配合好效果远好于 10 个 Agent 各自为战。每次想加 Agent 之前先问自己这个 Agent 的职责能不能合并到现有 Agent 里如果能就别加。把省下来的精力花在优化现有 Agent 的 Prompt 和协作机制上回报率高得多。
:UFS_软件设计规范)
