做过不少 AI 项目之后你会慢慢发现一个规律单智能体的上限往往卡在“角色”上。你让它又写代码又做分析又管流程它要么顾此失彼要么上下文越滚越杂最后产出的质量连你自己都看不下去。所以我一直觉得真正想解决复杂问题不能靠一个全能模型硬撑而是让多个各怀绝技的智能体像一个小团队一样分工协作。这篇文章要拆解的正是我最近实操完成的一个“多智能体协作系统”案例。系统内部有策划、调研、技术验证、评审等多个角色它们围绕同一个任务目标通过明确的通信规范和任务编排机制最终端到端地产出了一份包含技术选型、风险分析和落地方案的可交付成果。整个过程耗时比原先用单智能体硬推缩短了约 40%内容结构的完整度也明显更稳。如果你正在纠结怎么把多智能体从“概念”落到“工程”或者不确定该用现成框架还是自研机制这篇应该能给你省下不少试错时间。1. 案例背景与系统设计思路1.1 从单智能体到多智能体的关键转折先说清楚我为什么从单智能体迁移到多智能体。之前我习惯的做法是一个 Agent 接收任务然后依赖大模型自己的推理能力一步步规划。任务简单时还好一旦涉及多个领域知识比如既要拆解需求、又要调研技术方案、还要评估成本和风险单智能体就会暴露出几个很现实的问题。第一个问题是上下文污染。一个 Agent 同时处理需求分析、技术调研、风险评审这意味着所有领域的信息都挤在同一个上下文窗口里。调研技术方案时模型会被前面无效的需求讨论干扰评审风险时又容易被技术细节带偏。第二个问题是角色切换滞后。模型虽然是概率推理但你不会希望它在同一个会话里反复横跳“我现在是需求分析师、现在我是架构师”。实际效果是它经常在切换角色后仍然带着上一个角色的惯性思维评审产出的质量很难让人放心。所以我最终决定采用多智能体架构核心转变在于把领域边界硬隔离。每个智能体只负责一个明确角色拥有自己独立的上下文空间、工具集合和输出约束。智能体之间的交互不是靠一个超长 prompt 拼起来而是通过标准化的消息接口传递关键结果。这个思路听起来简单落实下去涉及任务怎么拆、依赖怎么排、通信怎么设计恰恰是这种架构最容易翻车的地方。1.2 系统整体架构与角色划分我这次设计的系统包含 5 个智能体分别承担不同的职责。如下图所示整体采用“一个协调者 四个执行者”的星型拓扑结构。智能体名称核心职责依赖的输入输出产物需求解析 Agent将原始需求拆解为结构化任务包用户原始需求任务清单 验收标准技术调研 Agent检索并比对候选技术方案任务清单技术选型对比报告方案设计 Agent基于调研结果设计系统方案技术选型报告详细设计文档 风险清单评审 Agent对方案进行查漏补缺和一致性校验设计文档 任务清单评审意见 修订建议协调者 Agent负责任务路由、进度管理和结果汇聚所有关键中间结果汇总执行报告这里有一个非常重要的设计决策协调者并不参与具体业务内容的生成它只做调度和汇总。我刻意不让协调者具备生成能力原因是我发现一旦协调者也能生成内容它很容易“忍不住”替执行者回答问题导致最终的产出变成协调者的独角戏多智能体的意义就完全丧失了。1.3 为什么选择“协调者 执行者”而不是全互联模式当初设计通信拓扑时我对比过两种主流方案。一种叫全互联模式就是每个智能体都能和其他任意智能体直接通信另一种就是我采用的协调者中心模式所有消息都经过协调者中转。全互联模式的最大优势是灵活两个智能体之间可以直接交换信息走最短路径。但它的致命问题是消息复杂度呈指数级上升A 和 B 说一句B 和 C 又说一句最后你根本不知道是谁先改变的主意也难以做全局一致性控制。调试的时候你连中间状态都很难复现。协调者中心模式牺牲了一部分灵活性却换来了三个确凿的好处。第一消息有迹可循所有交互都经过协调者记录第二任务状态一目了然第三后续做并行优化时协调者可以精确控制哪个智能体先跑、哪个后跑、哪些可以同时跑。对于一个要落地到生产环境的系统可观测性远比理论上的最优通信路径重要得多。2. 核心技术选型与协作机制解析2.1 框架选型现成框架还是自研机制这个案例里我最终选择了基于开源框架二次定制而不是完全自研。市面上的多智能体框架我近年基本都过了一遍AutoGen、MetaGPT、LangGraph、CrewAI 各有侧重点。AutoGen 的优势在于对话驱动的自动化机制很成熟适合两个 Agent 之间多轮协商LangGraph 强在状态图和流程控制适合需要精确控制 DAG 拓扑的任务而 CrewAI 的抽象模型非常符合我“角色 任务”的心智模型。这里要说一句公道话框架没有绝对的优劣关键看你对“协作”的定义。如果只是想快速验证一个多 Agent 的想法CrewAI 的 Agent Task Crew 三件套能让环境在半小时内跑起来如果你需要高度自定义节点行为和状态流转LangGraph 这类基于图的结构更有优势。我这次的需求侧重任务编排和流程可控最后选了 LangGraph因为它把流程边界画得很清晰当你有多个 Agent 来回切换时图结构的确定性比隐式的对话循环好排查得多。2.2 智能体间消息通信规范设计多智能体系统里消息格式的设计往往决定了系统的上限。我最开始贪图方便直接让智能体返回自然语言文本结果下游智能体每次解析的结果都不稳定。模型这次可能说“方案A成本较高”下次可能说“成本方面方案A并不便宜”同一意思多种表达下游做结构化判断时非常痛苦。后来我把智能体之间的通信协议改成了一套轻量 JSON Schema每个智能体的输出统一包含三个字段role、content、structured_data。content 字段给人看用于人工审计structured_data 给下游智能体看用于程序化处理。比如技术调研 Agent 的输出格式大致如下{ role: tech_researcher, topic: 向量数据库选型, content: 综合对比后建议优先考虑 Milvus 和 Qdrant。, structured_data: { candidates: [ {name: milvus, score: 0.92, advantage: 扩展性好, risk: 部署复杂}, {name: qdrant, score: 0.88, advantage: 轻量易用, risk: 性能上限} ], recommendation: milvus, confidence: 0.90 } }这样一个设计解决了两个难题。上游智能体的结论可以稳定地被下游智能体解读不同的表达不再影响解析效果同时人类审计时也不需要去读一堆密密麻麻的 JSON直接看 content 字段就行。我强烈建议任何做多智能体项目的人都认真设计这个结构化接口这是提升整体稳定性的关键一环。2.3 任务分解与依赖关系编排对于任何一个多智能体系统任务如何拆解直接决定了协作效率。我这个案例的任务拆解遵循了一个核心原则高内聚低耦合。每个任务尽量只依赖一个智能体的专长领域任务与任务之间的依赖关系被显式声明为 DAG。以本次需求为例DAG 是这样的需求解析 Agent 是根节点它不依赖任何智能体技术调研 Agent 依赖需求解析产出的任务清单方案设计 Agent 同时依赖技术调研报告和任务清单评审 Agent 依赖方案设计文档和原始需求独立校验是否存在偏离最后协调者汇聚一切产出生成汇总报告。在 LangGraph 里这种依赖通过 StateGraph 的节点和边来实现。我特别关注的是条件边的使用场景如果技术调研 Agent 给出的置信度低于 0.8系统会触发一轮重新调研如果评审 Agent 发现存在高风险项则强制回退到方案设计阶段。这就构成了一个带反馈回路的 DAG而不是一条直线走到底的流程。正是这个回路的配置让系统在多轮复杂需求的执行中表现得足够稳健。3. 实操过程从零搭建一个可复现的多智能体协作系统3.1 环境准备与依赖安装这个案例我是在 Python 3.11 环境下完成开发的。关于版本选择多说一句3.11 在 asyncio 和类型提示上的完善度比 3.9 和 3.10 要好多智能体系统通常涉及大量异步任务用旧版本容易撞上一些并发库的兼容问题。基础依赖我准备了这些pip install langgraph langchain openai jinja2 pip install python-dotenv loguru其中 langgraph 是流程编排核心langchain 负责模型调用和工具封装loguru 用于结构化日志输出。还有一个容易忽视的配置所有模型调用都通过环境变量管理 API Key 和模型名避免把密钥写死在代码里。我在 .env 里维护了不同智能体使用的模型标识毕竟不同角色的复杂度和成本需求不一样。3.2 定义智能体角色的完整步骤LangGraph 中定义一个智能体并不是创建一个类那么简单而是通过节点函数 状态类型的组合来实现。我习惯先将每个智能体的行为封装成一个独立函数它接收当前全局状态经过处理后返回更新后的局部状态。下面是我定义需求解析 Agent 的简化示例class AgentNode: def __init__(self, name, role_prompt, toolsNone, modelgpt-4o): self.name name self.role_prompt role_prompt self.tools tools or [] self.model model def run(self, state: dict) - dict: task state.get(task) parsed call_model( self.model, self.role_prompt \n原始需求 task[content], ) return {f{self.name}_output: parsed}每个节点函数返回的 key 都有明确的命名空间比如需求解析 Agent 的输出存储在requirement_parser_output里方案设计 Agent 的输出存储在solution_designer_output里。这种做法避免了多个节点同时往 state 里塞数据时产生冲突在调试阶段也能清楚看到每个节点到底写了什么。3.3 协作流程的状态管理机制多智能体系统的状态管理是我认为整个项目中最容易被低估的部分。LangGraph 本身提供了基于 StateGraph 的状态管理机制但我们不能把所有智能体的输出都塞进同一个 state 里否则随着执行推进state 很快就会膨胀直接拖慢模型性能和准确性。我采用了一个分区快照策略每个智能体都有自己独立的“黑账本”它只能看到协调者下发的任务提交和上游传递给它的必要上下文它的产出也都加上了自己命名空间的前缀。全局状态里只保留三样东西任务原始描述、当前流转阶段、各智能体产物的索引。下游智能体真正需要读取具体内容时才通过消息接口按索引去取。这种类似“记账本 仓库”的结构让整个系统的内存开销始终在一个可控区间。为了便于读者理解我加了一张执行时序示例展示本轮系统一次完整执行中各个智能体的运行顺序需求解析 Agent 最先启动产出任务清单。任务清单落库后协调者同时拉起技术调研 Agent。技术调研报告生成触发方案设计 Agent。方案设计 Agent 完成初稿协调者进入评审阶段。评审 Agent 给出修订意见若无重大风险协调者汇总结案。这个顺序是 DAG 自动推导出来的不是预写的硬编码逻辑。LangGraph 会根据每个节点的依赖声明自动决定谁能先跑、谁必须等待。这也正是图编排相比传统顺序代码的核心优势它把并发机会自动释放了出来。3.4 运行调试与产物校验要点整个系统跑通之后我只做了最后一层人工校验而这一步往往是很多人疏忽的。模型即使按 DAG 跑了全流程最终的产出仍然可能包含逻辑矛盾。我定义了一套自动校验规则在汇聚前对结果做一次清洗。我会检查需求清单里是否每一条都对应到了技术调研报告中的某个方案方案设计文档是否覆盖了所有调研到的候选方案以及最后风险和评审意见是否被明确记录。只要有一个校验不过协调者就会把对应环节打回重做。做完这些系统才真正从“会跑”升级为“靠谱”。4. 常见问题与排查技巧实录4.1 高频问题速查表调试多智能体系统时我踩了很多坑。为了方便后来者我把最有代表性的问题做成了速查表。问题现象根本原因排查思路解决手段下游 Agent 输出格式不稳定上游 content 字段是自然语言无结构化约束抓取上游原始消息检查 JSON Schema 是否缺失统一使用 structured_data 字段传输结构化结果多轮协作后回答越来越偏全局 state 不断膨胀模型被多余上下文干扰检查 state 增长曲线确认哪些字段被读取采用分区快照只传递必要字段任务卡死Agent 反复重试条件边逻辑不明确陷入自我修正死循环查看状态图跳转记录定位循环节点设计最大重试次数超限后强制降级到下一阶段Agent 间相互“抢活”角色 prompt 边界不清晰职责有重叠逐一审查角色 prompt 中的动词和产出定义每个 Agent 增加“不负责”条款明确边界评审形同虚设直接放行评审 Agent 缺少显著性校验条件查看评审输出的 confidence 权重为评审 Agent 指定必须发现的风险等级4.2 一个典型的“反馈回路”调试过程印象最深的一次问题出现在方案设计 Agent 和评审 Agent 之间的条件回路上。当时系统连续执行了五轮最后输出的方案总是离题。后来我查看状态记录发现评审 Agent 每一次都给出的是低风险意见但方案设计 Agent 每次都会触发一轮重新设计。原因很有意思原来我在条件边里设置的是“只要评审输出的 confidence 低于 0.85 就重新设计”可是评审 Agent 对“是否满意”的表达普遍偏高它经常给自己的评判打 0.95 以上的分但方案中确实有没覆盖到的风险。这个逻辑设置本质上是错的我并不是要让评审的“自信度”做门禁而是应该检查它的风险列表是否有内容。修正后的逻辑是评审 Agent 必须返回一个至少包含 3 项内容的 risk list否则强制它重新评审否则直接通过。这个改动让系统运行结果明显收敛也不再出现无意义的循环。4.3 成本控制与超时处理的实用经验多智能体系统最现实的问题都集中在成本上。多个 Agent 来回调用模型尤其有反馈回路时API 费用蹭蹭往上涨。我最后总结出了一套控制手段。第一个办法是按 Agent 分级使用模型。需求解析这类简单任务我使用轻量模型速度也不差方案设计和评审这类重设计任务才用旗舰模型。第二个办法是给每个 Agent 设置超时上限我在业务场景里把单 Agent 的单次调用限制在 30 秒以内超时直接降级不无限等待。第三个办法是给局部任务设置“早停机制”比如技术调研 Agent 只要搜索到足够数量的高质量候选方案就立即停止拉取不做无意义的穷举。这套组合拳打完我发现单次完整执行的成本降了大约三成而且几乎没有影响最终产出质量。对想要把多智能体系统推向生产环境的朋友来说成本控制不是事后补救而应该在架构设计阶段就想清楚。5. 经验总结与进一步实践方向案例完整跑通后我最直接的体会是多智能体协作系统真正的难点并不在于搭建几个能对话的 Agent而在于把任务边界、消息协议、状态管理和异常回环设计清楚。框架只是骨肉协议和状态才是灵魂。如果你想接着往下做我个人建议优先探索两个方向。一个方向是给 Agent 接入更丰富的外部工具。目前的智能体多数情况下只是依赖模型内在知识做推理如果给技术调研 Agent 接入实时网页检索、给方案设计 Agent 接入代码库检索系统的智能化上限会有明显提升。另一个方向是引入更精细的反馈学习机制比如让评审 Agent 的历史意见沉淀成一份持续更新的规则库后续版本的评审标准就会越来越接近团队内一个熟手专家的水准。这些后续迭代我没有在本次案例中实验完毕但从已有的实现架构来看并不需要推倒重来只需在现有 DAG 上增加新的节点和边。