1. 多智能体系统设计的核心命题1.1 从单Agent到多Agent为什么需要协作单Agent系统在过去两年里几乎被讨论透了。一个模型、一段系统提示词、几个工具函数就能跑通很多任务。但实际落地时会发现单Agent有三个绕不过去的瓶颈上下文窗口有限、单点能力天花板明显、复杂任务容易在中途“迷路”。比如让一个Agent同时负责需求分析、代码生成、测试验证和文档撰写它往往在第三步就开始丢失前两步的约束条件。多智能体系统的核心思路就是分而治之。把一个大任务拆成若干子任务每个子任务交给一个专门的AgentAgent之间通过消息传递、共享状态或任务队列来协同。这样做的好处很直接每个Agent的提示词可以更聚焦上下文更短工具集更精简出错时也更容易定位是哪个环节的问题。但多Agent不是银弹。引入多个Agent之后系统复杂度会指数级上升。Agent之间的通信开销、任务分配策略、冲突消解机制、失败重试逻辑每一项都可能成为新的故障点。我见过不少团队兴冲冲地把单Agent拆成五六个Agent结果整体成功率反而下降了原因就是拓扑结构没设计好Agent之间互相等待或者重复劳动。所以这篇文章要聊的核心就两件事提示词怎么优化以及拓扑结构怎么选。这两个变量直接决定了多智能体系统是“112”还是“三个和尚没水喝”。1.2 提示词与拓扑结构的关系很多人把提示词和拓扑结构分开看觉得前者是“写文案”后者是“搭架构”。实际上这两者是耦合的。提示词决定了单个Agent的行为边界和能力上限拓扑结构决定了这些Agent如何组织成一个整体。如果提示词写得模糊Agent在协作时就会产生歧义如果拓扑结构不合理再精细的提示词也发挥不出来。举个例子在一个“主管-执行者”拓扑中主管Agent的提示词必须明确“什么情况下把任务派给谁”以及“收到结果后如何判断是否合格”。如果主管的提示词只写了“协调团队完成任务”那它大概率会把所有任务一股脑丢给第一个Agent或者反复询问执行者“你确定吗”导致整个系统卡死。反过来如果拓扑是“流水线”式的每个Agent只负责一个固定阶段那提示词就可以写得非常具体甚至可以把输入输出格式硬编码进去。这时候提示词的优化重点就变成了“如何让当前阶段输出最利于下一阶段消费”。理解了这个耦合关系后面的优化才有方向。2. 提示词优化的底层逻辑与实操方法2.1 多Agent场景下提示词的特殊性单Agent的提示词优化核心目标是“让模型理解任务并给出好答案”。多Agent的提示词优化核心目标变成了“让模型在协作网络中扮演好自己的角色并且与其他角色无缝对接”。这个区别听起来小实际影响很大。在多Agent系统里每个Agent的提示词至少要包含四个层次的信息角色定义我是谁我负责什么我不负责什么。输入契约我会收到什么格式的信息这些信息从哪来。输出契约我要产出什么格式的信息这些信息给谁用。协作规则什么情况下我需要请求帮助什么情况下我需要终止并上报。很多人在写多Agent提示词时只写了第一层“你是一个资深程序员”后面三层全靠模型自己猜。结果就是Agent之间传递的消息格式五花八门下游Agent经常收到无法解析的内容整个系统频繁报错。我自己的经验是多Agent提示词里输入输出契约的篇幅应该占到一半以上。角色定义可以简短但“你收到的是JSON还是自然语言”“你输出时必须包含哪些字段”“如果信息不足你应该返回什么错误码”这些必须写死。2.2 提示词结构化的四层框架基于上面的思路我通常用一个四层框架来组织每个Agent的提示词。这个框架不是理论推导出来的是踩了很多坑之后总结的。第一层身份与边界。用两三句话说明这个Agent是谁、擅长什么、绝对不做什么。比如“你是一个代码审查Agent只负责检查代码中的逻辑错误和安全漏洞不负责修改代码也不负责运行测试。”第二层输入规范。明确列出这个Agent会接收到的字段。如果是上游Agent传来的结构化数据就把字段名和类型写清楚。如果是自然语言就说明“你会收到一段以【任务】开头的文本其中包含目标描述和约束条件”。第三层输出规范。这是最关键的部分。要规定输出的格式、必须包含的字段、字段的含义以及异常情况的处理方式。比如“输出必须是一个JSON对象包含status字段值为pass或fail、issues数组每个元素包含line、severity、description和summary字符串。如果代码无法解析status设为error并在summary中说明原因。”第四层协作指令。说明这个Agent在什么条件下应该把任务转给谁。比如“如果发现的问题属于架构层面而非代码层面不要自行处理将status设为escalate并在summary中说明需要架构Agent介入。”这个框架的好处是每个Agent的提示词都变成了一个“接口文档”上下游对接时不需要额外沟通看提示词就知道怎么传数据。2.3 提示词中的常见陷阱与修正在实际项目中我遇到过几类高频的提示词问题这里列出来供你对照检查。陷阱一角色描述过于宽泛。“你是一个有用的助手”这种话在多Agent系统里等于没说。修正方法是把角色和具体任务绑定比如“你是一个专门从用户反馈中提取功能需求的Agent你的输出将直接作为产品经理Agent的输入。”陷阱二输出格式没有约束。很多提示词只写了“请给出详细分析”结果Agent输出的内容长度、结构、详细程度每次都不一样下游Agent根本无法稳定解析。修正方法是给出具体的模板或JSON Schema。陷阱三缺少失败处理逻辑。Agent遇到无法处理的情况时如果没有明确的指令它可能会胡编一个答案或者陷入无限循环。修正方法是在提示词中明确“如果信息不足返回status: insufficient_info并列出缺少的字段不要猜测。”陷阱四协作规则模糊。“必要时可以请求其他Agent帮助”这种表述太模糊。修正方法是给出具体的触发条件比如“当任务涉及数据库操作时必须将任务转交给数据库Agent不得自行生成SQL。”陷阱五提示词过长导致关键信息被淹没。有些团队把提示词写成几千字的长文结果模型只记住了开头和结尾。修正方法是把最重要的约束放在最前面和最后面中间部分用分点列表而不是大段文字。2.4 提示词迭代的实操流程提示词不是一次写好的需要迭代。我通常按这个流程来先写最小可用版本。每个Agent的提示词先覆盖核心职责和输入输出格式不要追求完美。跑通一条完整链路。用最简单的任务测试整个多Agent流程观察每个环节的输出。定位失败点。如果最终结果不对逐环节检查是哪个Agent的输出偏离了预期。针对性修改。只修改出问题的那个Agent的提示词不要同时改多个。回归测试。修改后重新跑之前的测试用例确保没有引入新的问题。积累测试集。把每次遇到的边界情况都加入测试集后续迭代时用来做回归。这个流程的关键是“每次只改一个变量”。如果同时改提示词和拓扑结构出了问题根本不知道是哪个原因导致的。3. 拓扑结构选型从流水线到网状协作3.1 四种基础拓扑结构对比多Agent系统的拓扑结构决定了Agent之间的连接方式和通信模式。根据我的实践经验常用的基础拓扑有四种每种都有明确的适用场景和代价。拓扑类型结构描述适用场景优势劣势流水线Agent按固定顺序依次处理步骤明确、依赖线性的任务逻辑清晰、易调试无法并行、单点故障影响全局主管-执行者一个主管Agent分配任务给多个执行Agent任务可拆分、需要统一调度灵活、可动态分配主管成为瓶颈、提示词复杂黑板模式所有Agent共享一个状态空间按需读写需要多轮迭代、信息共享解耦、支持异步状态管理复杂、容易冲突网状协作Agent之间可自由通信复杂探索性任务灵活度最高难以调试、通信开销大选哪种拓扑取决于任务的性质。如果是代码生成这种步骤相对固定的任务流水线就够了。如果是需要多轮讨论和修正的任务黑板模式或主管-执行者更合适。网状协作一般只在研究性项目中使用生产环境很少直接上全连接网状结构。3.2 拓扑结构选择的决策依据在实际选型时我会问自己四个问题第一任务是否可以预先分解如果可以流水线或主管-执行者都行。如果任务边界模糊需要边做边探索黑板模式更合适。第二Agent之间是否需要频繁交换中间结果如果每个Agent只需要上游的输出流水线最优。如果需要反复读取和修改共享状态黑板模式更自然。第三系统的容错要求有多高流水线中任何一个环节失败都会导致整个流程中断。主管-执行者可以通过重新分配任务来容错。黑板模式天然支持重试因为状态是共享的。第四调试成本能接受多少流水线最容易调试因为执行路径是确定的。网状协作最难调试因为每次运行的通信路径可能都不一样。我的建议是从最简单的拓扑开始遇到瓶颈再升级。很多团队一上来就设计复杂的网状结构结果大部分时间都花在调试通信问题上而不是解决业务问题。3.3 混合拓扑的实践案例纯理论讲拓扑有点空我拿一个实际项目来说。之前做过一个技术文档生成系统输入是一份需求文档输出是完整的API文档和示例代码。这个任务如果用一个Agent做上下文根本装不下。拆成多Agent后我用了混合拓扑。整体结构是“主管-执行者”套“流水线”。主管Agent负责把需求文档拆成若干模块然后为每个模块启动一条流水线。每条流水线包含三个Agent需求解析Agent、代码生成Agent、文档撰写Agent。需求解析Agent的输出直接喂给代码生成Agent代码生成Agent的输出再喂给文档撰写Agent。主管Agent的提示词里写明了拆分规则“按功能模块拆分每个模块不超过500字描述。如果模块之间有依赖关系在任务描述中标注depends_on字段。”这样主管Agent拆分出来的任务就是结构化的流水线内部的Agent可以直接消费。这个混合拓扑的好处是主管层提供了灵活性可以动态调整模块划分流水线层保证了每个模块内部的处理是确定性的容易调试。实测下来整个系统的成功率比纯主管-执行者结构高了将近三成因为流水线内部的Agent不需要反复和主管通信减少了消息丢失和格式错误的风险。3.4 拓扑结构的动态调整策略拓扑结构不是一成不变的。同一个系统在不同负载或不同任务类型下可能需要不同的拓扑。我通常会在系统里加一个“拓扑选择器”根据任务特征动态选择结构。具体做法是在系统入口处放一个轻量级的分类Agent它的提示词是“根据任务描述判断任务类型输出topology字段值为pipeline、supervisor或blackboard”。然后系统根据这个字段选择对应的执行引擎。这个分类Agent的提示词需要精心设计因为它决定了整个系统的走向。我会在提示词里给出每种拓扑的适用条件比如“如果任务步骤明确且线性输出pipeline如果任务可拆分为独立子任务输出supervisor如果任务需要多轮迭代和共享状态输出blackboard。”这个策略的代价是增加了一次分类调用但收益是系统能自适应不同类型的任务。在实际运行中分类准确率能达到85%以上剩下的15%错误可以通过兜底策略处理——如果分类错误导致执行失败系统会自动降级到主管-执行者模式重试。4. 实操过程从零搭建一个多Agent协作系统4.1 环境准备与基础框架选型动手之前先确定技术栈。多Agent系统的框架选择很多我个人的偏好是轻量级、可观测性好的方案。太重型的框架虽然功能全但调试起来很痛苦出了问题不知道是框架的锅还是自己提示词的锅。基础组件需要这几样模型接口层负责调用大模型需要支持流式输出和函数调用。消息总线Agent之间传递消息的通道可以用内存队列或Redis。状态存储保存共享状态黑板模式必须要有。日志与追踪记录每个Agent的输入输出方便排查问题。如果不想引入太多依赖可以用Python的标准库加一个模型SDK就搭起来。消息总线用asyncio.Queue状态存储用字典日志直接写文件。等系统跑通了再考虑替换成更健壮的组件。4.2 定义Agent角色与提示词模板假设我们要做一个“技术方案评审”系统输入是一份技术方案文档输出是评审意见和修改建议。我设计三个Agent解析Agent负责把方案文档拆解成结构化信息包括目标、架构、技术选型、风险点。评审Agent负责对每个部分给出评审意见判断是否合理。汇总Agent负责把评审意见整理成最终报告。解析Agent的提示词模板你是技术方案解析Agent。你的任务是将输入的技术方案文档拆解为结构化信息。 输入一段技术方案文本以【方案开始】和【方案结束】标记。 输出一个JSON对象包含以下字段 - goal: 字符串方案的目标 - architecture: 字符串架构描述 - tech_stack: 字符串数组技术选型列表 - risks: 字符串数组识别出的风险点 - raw_sections: 对象键为章节名值为该章节的原文 约束 - 如果某个字段在原文中找不到对应内容设为null不要编造。 - risks字段只列出原文明确提到的风险不要自行推断。 - 输出必须是合法JSON不要包含任何额外文字。评审Agent的提示词模板你是技术方案评审Agent。你会收到一个JSON对象包含方案的结构化信息。 输入JSON对象字段包括goal、architecture、tech_stack、risks。 输出一个JSON对象包含以下字段 - overall_score: 整数1-10分 - comments: 数组每个元素包含section评审的部分、score1-10、comment评审意见 - suggestions: 字符串数组具体的修改建议 约束 - 评审意见必须具体指出问题所在不要写“建议优化”这种空话。 - 如果某个部分信息缺失值为null在comments中标注“信息不足无法评审”。 - suggestions中的每条建议必须可操作比如“将数据库从MySQL替换为PostgreSQL以支持JSON字段”。汇总Agent的提示词模板你是评审汇总Agent。你会收到解析结果和评审结果两个JSON对象。 输入两个JSON对象分别为parsed和reviewed。 输出一份Markdown格式的评审报告包含以下部分 - 方案概述基于parsed.goal和parsed.architecture - 评审总评基于reviewed.overall_score和reviewed.comments - 详细意见按section列出reviewed.comments中的每条意见 - 修改建议列出reviewed.suggestions中的所有建议 约束 - 报告语言为中文风格专业但易读。 - 不要添加原文中没有的信息。 - 如果reviewed中有“信息不足”的标注在报告中如实体现。这三个提示词都遵循了前面说的四层框架身份、输入、输出、约束。每个Agent的输出格式都是下游Agent可以直接消费的。4.3 搭建流水线拓扑并跑通第一个用例有了Agent定义接下来搭流水线。代码结构很简单import asyncio import json async def run_pipeline(document): # 第一步解析 parsed await call_agent(parser, document) parsed_data json.loads(parsed) # 第二步评审 reviewed await call_agent(reviewer, json.dumps(parsed_data)) reviewed_data json.loads(reviewed) # 第三步汇总 report await call_agent(summarizer, json.dumps({ parsed: parsed_data, reviewed: reviewed_data })) return report跑第一个用例时我建议用一个简单的方案文档比如“设计一个博客系统使用Django作为后端PostgreSQL作为数据库前端用React”。这样容易观察每个环节的输出是否符合预期。实测中解析Agent可能会把“前端用React”归到tech_stack里这是对的。评审Agent可能会给架构打7分并建议“增加缓存层”。汇总Agent会把这些整理成报告。如果某个环节输出格式不对比如解析Agent返回了非JSON内容流水线会直接报错这时候就需要回去修改提示词。4.4 引入主管Agent实现动态任务分配流水线跑通后可以升级到主管-执行者模式。主管Agent的提示词需要包含任务拆分规则和分配逻辑你是技术方案评审的主管Agent。你的任务是将方案文档拆分为若干评审单元并分配给评审Agent。 输入一段技术方案文本。 输出一个JSON数组每个元素包含 - unit_id: 字符串单元标识 - content: 字符串该单元的原文 - focus: 字符串评审重点 拆分规则 - 按方案的主要章节拆分每个章节作为一个单元。 - 如果某个章节超过800字进一步按段落拆分。 - focus字段根据章节内容自动生成比如“架构设计”章节的focus为“评估架构合理性和扩展性”。 约束 - 拆分后的单元总数不超过10个。 - 每个单元的content必须是原文的连续片段不要改写。主管Agent输出任务列表后系统并行调用多个评审Agent每个评审Agent处理一个单元。最后汇总Agent把所有评审结果合并。这个结构的优势是评审可以并行速度更快。但代价是主管Agent的提示词更复杂而且如果拆分不合理评审质量会下降。我通常会在主管提示词里加一条“如果无法确定拆分方式输出status: need_clarification并说明原因”避免主管胡乱拆分。5. 常见问题与排查技巧实录5.1 Agent输出格式不稳定的排查思路这是多Agent系统里最高频的问题。表现是下游Agent报“无法解析输入”或者解析出来的字段缺失。排查步骤检查上游Agent的原始输出。把日志打开看它到底返回了什么。很多时候是模型在JSON外面加了“好的以下是结果”这种前缀。检查提示词中的格式约束是否足够强硬。“请输出JSON”这种表述太弱要改成“输出必须是合法JSON不要包含任何额外文字。第一个字符必须是{最后一个字符必须是}。”考虑使用结构化输出功能。很多模型接口支持强制JSON模式开启后模型只能输出合法JSON能解决大部分格式问题。加一层解析容错。如果模型偶尔还是会加前缀可以在解析前用正则提取第一个{到最后一个}之间的内容。我自己的做法是双保险提示词里写死格式要求同时在代码里加解析容错。这样即使模型偶尔抽风系统也不会直接崩溃。5.2 Agent之间通信超时或死锁的处理在主管-执行者或网状拓扑中Agent之间互相等待是常见问题。表现是系统卡住不动日志里最后一条消息是某个Agent在等待另一个Agent的回复。排查思路检查是否有循环等待。Agent A等Agent BAgent B又在等Agent A。这种情况通常是因为提示词里没有定义终止条件。检查超时设置。每个Agent调用都应该有超时超时后返回错误而不是无限等待。检查任务分配逻辑。主管Agent是否可能把同一个任务同时分配给多个执行者导致它们互相等待对方的输出。解决方法是在提示词中明确“如果你需要的信息在输入中不存在不要等待直接返回status: missing_info并列出缺少的字段”。同时在系统层面设置全局超时比如单个任务超过60秒未完成就强制终止并上报。5.3 提示词迭代中的回归问题修改一个Agent的提示词后之前能跑通的用例突然失败了。这是典型的回归问题。原因通常是修改影响了输出格式而下游Agent没有相应调整。避免方法维护一个测试集。至少包含10个典型用例每次修改提示词后全部跑一遍。修改提示词时先检查输出格式是否变化。如果变了同步更新下游Agent的输入解析逻辑。使用版本控制。提示词也要像代码一样管理每次修改记录变更原因和影响范围。我踩过最惨的一次坑是为了让评审Agent更“严格”在提示词里加了一句“对每个问题都要给出严重程度评级”结果它的输出从纯文本变成了带评级的结构化文本而汇总Agent还在按纯文本解析整个系统直接挂了。后来我把提示词和解析逻辑放在同一个配置文件里改提示词时强制检查解析逻辑是否需要同步修改。5.4 多Agent系统的性能优化经验多Agent系统比单Agent慢这是必然的因为多了通信和协调开销。但可以通过一些手段把开销降到最低。并行化。主管-执行者拓扑中多个执行者可以并行调用。用asyncio.gather同时发起多个请求总耗时取决于最慢的那个而不是所有耗时之和。缓存。如果某些Agent的输入重复率高可以加缓存。比如解析Agent对同一份文档的解析结果可以缓存避免重复调用。精简提示词。提示词越长模型处理越慢。把不必要的历史信息去掉只保留当前任务需要的内容。选择合适的模型。不是所有Agent都需要用最强的模型。解析和汇总这种格式化任务可以用小模型评审和决策这种需要推理的任务再用大模型。实测下来一个设计良好的多Agent系统总耗时可以控制在单Agent的1.5到2倍以内但成功率能提升30%以上。这个 trade-off 在大多数场景下是值得的。5.5 常见问题速查表问题现象可能原因排查方法解决措施下游Agent无法解析输入上游输出格式不符查看上游原始输出强化格式约束加解析容错系统卡住不动Agent循环等待检查日志最后一条消息加超时明确终止条件修改提示词后旧用例失败输出格式变化对比修改前后的输出同步更新下游解析逻辑整体成功率低拓扑结构不匹配分析失败任务的类型调整拓扑或拆分粒度响应时间过长串行调用过多统计各环节耗时并行化缓存换小模型Agent重复劳动任务分配不清晰检查主管提示词明确每个Agent的职责边界6. 进阶技巧让多Agent系统更稳定6.1 引入验证Agent做质量兜底在多Agent系统中最怕的是某个Agent输出了看似合理但实际错误的内容然后这个错误一路传递到最终结果。解决方法是加一个验证Agent专门检查关键环节的输出。验证Agent的提示词要聚焦在“检查”而不是“生成”你是输出验证Agent。你会收到一个JSON对象和它的预期Schema。 输入data待验证的JSON对象和schema预期字段和类型。 输出一个JSON对象包含 - valid: 布尔值是否通过验证 - errors: 字符串数组具体的验证错误 约束 - 只检查结构和类型不检查内容正确性。 - 如果data不是合法JSONvalid设为falseerrors中说明解析失败。 - 如果某个字段缺失或类型不符在errors中列出字段名和预期类型。这个验证Agent可以插在任意两个Agent之间成本很低但能拦住大部分格式错误。6.2 用共享状态减少消息传递在黑板模式中Agent不直接互相发消息而是读写共享状态。这样做的好处是解耦Agent A不需要知道Agent B的存在只需要把结果写到状态里Agent B自己会去读。共享状态的设计要点每个字段有明确的写入者和读取者。避免多个Agent同时写同一个字段。状态更新要原子化。用锁或事务保证并发安全。状态要有版本号。方便追踪每次变更。黑板模式特别适合需要多轮迭代的任务。比如代码生成后需要审查、修改、再审查每一轮的结果都写到状态里下一轮Agent读取最新状态继续处理。6.3 拓扑结构的可视化与调试多Agent系统调试难很大原因是执行路径不直观。我通常会在系统里加一个追踪模块把每次Agent调用的输入、输出、耗时、状态都记录下来然后生成一个可视化的执行图。这个图不需要多复杂用文本形式就行[解析Agent] 输入: 方案文档(1200字) - 输出: JSON(5字段) [耗时2.3s] - [评审Agent-1] 输入: 架构部分 - 输出: 评分7 [耗时1.8s] - [评审Agent-2] 输入: 技术选型 - 输出: 评分8 [耗时1.5s] - [汇总Agent] 输入: 两个评审结果 - 输出: 报告(800字) [耗时2.1s]有了这个追踪出问题时一眼就能看出是哪个环节慢了或者错了。我一般会把追踪日志按天归档方便回溯历史问题。6.4 从失败案例中提取改进信号每次系统失败都是一次改进机会。我会把失败案例收集起来分类分析格式类失败输出不符合预期格式。改进方向是强化提示词约束或加验证Agent。逻辑类失败输出格式对但内容错。改进方向是优化提示词中的推理引导或者换更强的模型。协作类失败Agent之间配合出问题。改进方向是调整拓扑结构或明确协作规则。超时类失败某个环节耗时过长。改进方向是并行化或换小模型。积累到一定数量后你会发现大部分失败都集中在少数几个环节。针对性地优化这几个环节整体成功率会有明显提升。7. 个人实操体会多Agent系统的设计说到底是在“分工”和“协调”之间找平衡。分工越细单个Agent越简单但协调成本越高。分工越粗协调简单但单个Agent的提示词会变得臃肿。我的经验是先从粗粒度开始遇到瓶颈再拆分。不要一上来就设计五六个Agent先用两三个Agent跑通核心流程观察哪里是瓶颈。如果某个Agent的提示词超过800字或者它需要处理的任务类型超过三种那就是拆分的信号。另一个体会是提示词的质量比数量重要。我见过有人给每个Agent写了上千字的提示词结果关键约束被淹没在废话里。好的提示词应该是紧凑的、结构化的、每句话都有明确目的的。写完提示词后问自己这句话如果不写Agent会做错什么如果答案是“不会做错什么”那就删掉。最后多Agent系统的调试成本远高于单Agent。在引入多Agent之前先确认单Agent真的解决不了问题。很多时候优化单Agent的提示词和工具集比拆成多Agent更划算。只有当任务确实需要不同角色、不同上下文、不同工具集时多Agent才是正确的选择。