多智能体系统这两年从论文里走出来落到实际项目里的速度比我预想得快很多。我最早接触多 Agent 协作是在一个自动化代码审查的场景里当时天真地以为只要把几个 Agent 拼在一起、给每个 Agent 写一段提示词就能跑起来结果第一版跑出来的东西简直没法看——Agent 之间互相甩锅、重复劳动、上下文爆炸、任务在几个角色之间来回踢皮球。后来花了大概两个月时间反复调提示词、改拓扑结构才慢慢摸到一点门道。这篇就围绕多智能体设计这个主题把我在提示词优化和拓扑结构优化这两条主线上的实战经验完整拆一遍包括为什么某些设计会失败、怎么判断该用哪种拓扑、提示词到底该写到什么颗粒度。不管你是刚上手多 Agent 协作还是已经踩过一些坑希望这些内容能帮你少走点弯路。1. 先搞清楚多智能体到底难在哪1.1 单 Agent 能做的事为什么非要拆成多个很多人一开始会问一个 Agent 加一段足够长的提示词不就能干活了吗为什么非要搞多智能体这个问题我认真想过也做过对比实验。结论是单 Agent 的能力上限受限于两个东西——上下文窗口和角色冲突。上下文窗口好理解任务一复杂历史消息、工具返回、中间结果全堆在一个对话里很快就撑爆了。但更隐蔽的问题是角色冲突。举个例子你让一个 Agent 同时扮演严格的代码审查者和友好的需求沟通者这两个角色的行为倾向是矛盾的审查者要挑刺、要否定沟通者要共情、要肯定。当它们挤在同一个提示词里模型会倾向于折中结果就是审查不够狠、沟通不够暖两头不讨好。多智能体的核心价值就在这把互相冲突的职责拆到不同的 Agent 上每个 Agent 的提示词只服务于一个明确目标。这样每个 Agent 的行为一致性会大幅提升整体系统的可控性也更强。但代价是引入了新的复杂度——Agent 之间怎么通信、任务怎么分配、结果怎么汇总这些就是后面要重点讲的拓扑结构问题。1.2 多智能体系统的三个典型失败模式在讲怎么优化之前先说说我踩过的坑这些失败模式几乎每个新手都会遇到第一种无限循环踢皮球。Agent A 把任务交给 Agent BB 觉得这不是自己的活又交回给 AA 再交出去……如果没有明确的终止条件和职责边界系统会一直转下去烧掉大量 token 还出不来结果。我见过最夸张的一次两个 Agent 来回交接了四十多轮最后是我手动掐断的。第二种上下文污染。多个 Agent 共享一个消息历史时A 的中间推理过程会被 B 看到B 可能会被 A 的错误思路带偏。更麻烦的是当历史里混入了大量无关的工具返回和试错记录模型抓重点的能力会明显下降。第三种责任稀释。当多个 Agent 都能处理某类任务时反而没人认真处理。每个 Agent 都觉得反正别人也会做结果关键步骤被跳过。这在拓扑结构设计不合理时特别常见。理解了这三个失败模式后面的提示词优化和拓扑优化就有了明确的目标消除循环、隔离上下文、明确责任。2. 提示词优化不是写得越长越好2.1 多智能体场景下提示词和单 Agent 的本质区别单 Agent 的提示词可以写得很全把背景、目标、约束、示例全塞进去。但多智能体场景下每个 Agent 的提示词要遵循一个完全不同的原则只写这个 Agent 需要知道的绝不写它不需要知道的。为什么因为多智能体系统里每个 Agent 的输出会成为其他 Agent 的输入。如果 A 的提示词里包含了大量 B 才知道的细节A 在输出时可能会把这些细节也带出来污染 B 的上下文。反过来如果 A 的提示词里缺少必要的接口约定A 的输出格式可能和 B 期望的对不上导致解析失败。我总结了一个多智能体提示词的三段式结构实测下来比自由发挥稳定得多角色与边界这个 Agent 是谁、负责什么、明确不负责什么输入契约它会收到什么格式的输入每个字段的含义输出契约它必须输出什么格式字段定义、取值范围、必填项注意这里没有背景介绍任务目标这类单 Agent 常见的内容。在多智能体里背景和目标应该由编排层Orchestrator统一管理而不是散落在每个 Agent 的提示词里。2.2 角色提示词的颗粒度控制颗粒度是个很微妙的东西。写太粗Agent 行为不稳定写太细Agent 失去灵活性遇到提示词没覆盖的情况就卡住。我的经验是用职责清单 判断原则代替步骤清单。举个例子一个代码审查 Agent差的写法是这样的你是一个代码审查员。请按以下步骤审查代码 1. 检查变量命名 2. 检查函数长度 3. 检查是否有硬编码 4. 检查错误处理 ...这种写法的问题是它把审查变成了一个固定流程遇到流程外的代码问题就漏了。好的写法应该是你是一个代码审查员专注于发现代码中的可维护性问题和潜在缺陷。 你的职责范围 - 命名规范与可读性 - 函数职责单一性 - 错误处理完整性 - 资源管理如文件句柄、连接 你不负责性能优化建议、架构层面的重构建议这些由其他角色处理 判断原则当你不确定某个问题是否属于你的职责时优先报告而不是忽略 但要在报告中标注待确认。这种写法的好处是Agent 有了明确的判断依据遇到边界情况知道怎么处理而不是死板地按步骤走。2.3 用输出契约约束 Agent 之间的接口这是我认为多智能体提示词里最重要、也最容易被忽略的部分。Agent 之间的通信如果靠自然语言解析起来会非常痛苦。我的做法是强制每个 Agent 输出结构化数据通常是 JSON并在提示词里给出完整的 schema。比如一个任务分配 Agent 的输出契约{ task_id: string, 任务唯一标识, assignee: string, 必须是以下之一: coder, reviewer, tester, priority: integer, 1-5, 1 最高, context: string, 不超过 200 字的任务背景, acceptance_criteria: [string, 验收标准列表] }关键点在于schema 里要明确枚举值和取值范围。我踩过的坑是只写了字段名没写取值范围结果 Agent 输出了一个不存在的 assignee 值下游直接报错。另外context字段我特意限制了长度因为不加限制的话 Agent 会把所有历史都塞进去导致下游上下文爆炸。提示输出契约里的字段名尽量用英文值可以用中文。这样解析代码写起来干净同时不影响 Agent 理解。2.4 提示词里的防循环设计前面提到的踢皮球问题很大一部分可以在提示词层面缓解。具体做法是在每个 Agent 的提示词里加入交接规则明确列出这个 Agent 可以把任务交给哪些 Agent规定交接时必须附带已尝试的操作和失败原因设置交接次数上限超过就升级给人工或终止我通常会在提示词里写这样一段当你无法完成任务时你可以将任务交接给 [其他 Agent 列表]。 交接时必须包含 1. 你已经尝试过的操作 2. 失败的具体原因 3. 你期望接手方做什么 如果你已经收到过同一个任务两次以上不要再交接直接输出 {status: escalate, reason: ...} 终止流程。这段收到过同一个任务两次以上就终止的规则帮我省了无数次手动掐断的麻烦。3. 拓扑结构决定系统上限的隐形骨架3.1 四种常见拓扑结构及其适用场景拓扑结构说白了就是 Agent 之间怎么连接、消息怎么流动。我实际用过的有四种各有各的适用场景拓扑类型结构特点适用场景主要缺点流水线A→B→C 线性步骤明确的流程如文档处理无法并行单点阻塞星型中心调度器 多个执行 Agent任务类型多、需要统一调度中心节点是瓶颈网状Agent 之间可任意通信需要频繁协商的复杂任务容易失控难调试分层上层规划 下层执行大型任务需要分解层间通信开销大我个人的经验是新手从星型开始熟练后再考虑分层。流水线太死板网状太容易失控这两个我都不推荐作为起点。星型结构的核心是一个 Orchestrator它负责接收任务、分解、分配给执行 Agent、收集结果。执行 Agent 之间不直接通信所有交互都经过 Orchestrator。这样做的好处是上下文隔离得很干净每个执行 Agent 只看到自己那部分任务不会被其他 Agent 的中间过程干扰。3.2 星型拓扑的 Orchestrator 该怎么设计Orchestrator 是整个系统的大脑它的提示词设计直接决定系统能不能跑起来。我的 Orchestrator 提示词通常包含这几块任务分解规则什么粒度的任务该拆、拆到什么程度停。我的经验是拆到单个 Agent 一次能完成为止判断标准是这个任务不需要再调用其他 Agent。路由规则什么类型的任务交给哪个 Agent。这里要用明确的判断条件不能模糊。比如涉及代码修改的交给 coder涉及验证的交给 tester。结果汇总规则多个 Agent 返回结果后怎么合并。这里要处理冲突——如果 coder 说改好了、tester 说没通过Orchestrator 要决定是打回重做还是升级。终止条件什么时候认为任务完成。这个必须明确否则 Orchestrator 会一直觉得还可以再优化。我见过很多人把 Orchestrator 写成一个万能 Agent什么活都自己干。这是大忌。Orchestrator 应该只做调度不碰具体执行。一旦它开始写代码、写文档整个系统的职责边界就乱了。3.3 分层拓扑什么时候值得上当任务复杂到需要先规划再执行时星型就不够用了。这时候需要分层顶层是 Planner负责把大任务拆成子任务中间是 Orchestrator负责调度每个子任务底层是执行 Agent。分层的价值在于规划质量和执行效率可以分开优化。Planner 可以用更强的模型、更长的思考时间因为它只跑一次执行 Agent 可以用更轻量的模型因为它们要跑很多次。这种重规划、轻执行的搭配在成本和质量之间能取得不错的平衡。但分层也有代价层间通信的延迟和失真。Planner 输出的计划如果不够具体Orchestrator 理解偏了整个执行就歪了。我的做法是在 Planner 和 Orchestrator 之间加一层计划校验用一个独立的 Agent 检查计划是否可执行、是否有歧义。这一步看起来多余但实测能减少大量返工。3.4 拓扑结构不是越复杂越好我特别想强调这一点。很多人一上来就想搞一个全连接网状 分层 动态路由的复杂系统结果调试到崩溃。拓扑结构的复杂度应该由任务复杂度决定而不是由技术炫技决定。我的判断标准很简单如果星型能跑通就不要上分层如果流水线能跑通就不要上星型。每增加一层结构就增加一份调试成本和失败概率。我现在的项目里大部分场景用的都是星型只有少数需要长链条规划的任务才上分层。4. 提示词与拓扑的协同优化4.1 拓扑决定提示词怎么写这两者不是独立的。拓扑结构决定了 Agent 之间的通信模式而通信模式又决定了提示词里要写什么。比如在星型拓扑里执行 Agent 的提示词里不需要写如何与其他 Agent 协商因为它们根本不直接通信。但在网状拓扑里每个 Agent 的提示词都必须包含协商规则、冲突解决策略。这就是为什么我推荐从星型开始——星型对提示词的要求最低最容易上手。再比如分层拓扑里Planner 的提示词要包含如何评估子任务复杂度因为它要决定拆几层而执行 Agent 的提示词要包含如何向上层报告进度因为它的输出会被 Orchestrator 消费。4.2 一个实际的调优案例说个具体的。我之前做过一个自动化测试用例生成的系统最初用的是流水线需求分析 → 用例生成 → 用例审查。跑起来发现两个问题一是用例审查经常打回重做来回好几轮二是需求分析阶段的信息在传递过程中丢失严重。后来改成了星型一个 Orchestrator 负责协调需求分析、用例生成、用例审查三个 Agent 独立。关键改动是在 Orchestrator 里维护一份共享上下文所有 Agent 都能读到这份上下文但各自的中间推理过程不共享。同时优化了提示词用例生成 Agent 的输出契约里增加了覆盖的需求点字段用例审查 Agent 的输入契约里明确要求检查这个字段。这样审查 Agent 就能快速判断用例是否覆盖了所有需求而不是重新读一遍需求文档。改动之后平均返工轮次从 2.8 降到 0.6token 消耗降低了约 40%。这个案例说明拓扑优化和提示词优化要一起做单改一个效果有限。4.3 怎么判断该优化提示词还是优化拓扑这是个很实际的问题。我的判断方法是看失败发生在哪里如果失败是Agent 输出格式不对Agent 理解错了任务那是提示词问题如果失败是任务在 Agent 之间来回转某个 Agent 一直等不到输入那是拓扑问题如果失败是整体结果质量差但每个 Agent 单独看都还行那通常是拓扑问题——信息在传递中丢失了我一般会先看日志统计每个 Agent 的调用次数和失败率。如果某个 Agent 被调用次数异常高多半是拓扑里有循环如果某个 Agent 失败率高但调用次数正常多半是提示词没写清楚。5. 实操中那些文档不会告诉你的细节5.1 上下文管理共享什么、隔离什么多智能体系统里上下文管理是最容易出问题的地方。我的原则是共享事实隔离推理。事实指的是任务目标、约束条件、已知信息这些客观内容所有 Agent 都应该能看到。推理指的是某个 Agent 的思考过程、试错记录这些不应该共享否则会污染其他 Agent。具体实现上我会在 Orchestrator 里维护一个shared_context对象只放事实类信息。每个 Agent 调用时把shared_context加上自己的专属输入一起传进去。Agent 的输出只返回结果不返回推理过程除非明确需要。这样做的好处是上下文体积可控而且每个 Agent 看到的都是干净的信息。代价是 Orchestrator 要负责维护shared_context的更新逻辑稍微复杂一点但值得。5.2 失败重试的正确姿势Agent 调用失败是常态关键是怎么重试。我的经验是区分可重试失败和不可重试失败可重试格式解析失败、超时、临时性错误。这类直接重试但最多重试 2 次。不可重试任务本身无法完成、输入数据有问题。这类重试多少次都没用应该直接升级。重试时有个技巧把上次失败的原因作为额外输入传给 Agent。比如上次你的输出缺少 acceptance_criteria 字段请确保这次包含。实测这样能显著提高重试成功率。另外重试不要用完全相同的输入。如果 Agent 第一次没做对同样的输入大概率还是做不对。要么补充信息要么换个角度描述任务。5.3 日志和可观测性多智能体系统如果不做日志出问题基本没法查。我要求每个 Agent 的每次调用都记录输入、输出、耗时、token 消耗、是否成功。这些日志汇总起来能看出很多问题哪个 Agent 是瓶颈耗时最长哪个 Agent 最烧钱token 最多任务流转路径是什么样的有没有异常循环失败集中在哪个环节我一般会做一个简单的可视化把任务流转路径画出来。看到某个任务在 A 和 B 之间来回跳就知道拓扑有问题了。5.4 成本控制的几个实用手段多智能体系统烧 token 是很快的尤其是 Agent 之间来回交互的时候。我常用的控制手段第一给每个 Agent 设置 token 上限。超过就截断或报错防止单个 Agent 失控。第二用不同规格的模型。Orchestrator 和 Planner 用强模型执行 Agent 用轻量模型。实测下来执行类任务用轻量模型质量差距不大但成本能降一大截。第三缓存重复调用。如果同一个 Agent 用相同输入被调用了多次直接返回缓存结果。这在有循环的系统里特别有用。第四设置全局预算。整个任务的总 token 消耗超过阈值就终止避免无限烧钱。6. 从能跑到好用我的迭代路径6.1 第一版先让它跑起来我的建议是第一版不要追求完美用最简单的拓扑流水线或星型 最朴素的提示词先让整个流程跑通。这个阶段的目标是验证任务能不能被拆解、Agent 之间能不能通信而不是追求质量。第一版跑通后你会对任务的实际复杂度有更清晰的认识这时候再优化才有方向。我见过太多人一上来就设计复杂架构结果连基本流程都没跑通白白浪费时间。6.2 第二版定位瓶颈跑通之后开始看日志找瓶颈。重点关注三个指标失败率、返工率、token 消耗。哪个指标最差就先优化哪个。如果是失败率高先看提示词尤其是输出契约部分。如果是返工率高看拓扑多半是信息传递有问题。如果是 token 消耗高看是不是有循环或者上下文太大。6.3 第三版针对性优化定位到瓶颈后针对性优化。这个阶段我通常会做几件事把提示词里的模糊表述改成明确的判断规则给关键 Agent 增加输出校验不合格就重试调整拓扑把串行改成并行如果任务之间没有依赖引入缓存减少重复调用每改一处都要重新跑一遍测试集对比指标。不要一次改太多否则出了问题不知道是哪个改动导致的。6.4 持续迭代的心态多智能体系统没有完成的时候只有当前够用。任务在变、模型在变、成本要求在变系统就得跟着调。我的做法是保留一套回归测试集每次改动后跑一遍确保没有把之前修好的问题又改回去。这套测试集不用很大覆盖主要场景就行。我一般准备 20-30 个典型任务涵盖简单、中等、复杂三档。每次改动后跑一遍看通过率和成本变化。7. 几个容易被忽略的设计原则7.1 单一职责原则在多智能体里的应用这个原则在软件工程里是老生常谈但在多智能体设计里同样适用而且更重要。每个 Agent 只做一件事做不好就换掉不影响其他 Agent。我见过有人设计一个全能执行 Agent既能写代码又能写文档还能做测试。这种 Agent 的提示词会非常臃肿行为也不稳定。正确的做法是拆成三个 Agent各自专注。虽然 Agent 数量多了但每个都简单可控整体反而更好维护。7.2 幂等性设计Agent 调用可能失败重试所以每个 Agent 的操作应该是幂等的。也就是说同一个任务执行一次和执行多次结果应该一样。这在有副作用的操作里特别重要比如写文件、发请求。我的做法是给每个任务分配唯一 IDAgent 在执行前先检查这个 ID 是否已经处理过处理过就直接返回之前的结果。7.3 优雅降级系统不可能永远正常。当某个 Agent 持续失败时系统应该有降级方案而不是直接崩溃。常见的降级策略用备用 Agent 替代如果有的话跳过非关键步骤继续执行返回部分结果并标注哪些部分未完成我在实际项目里会给每个关键 Agent 配一个降级版本用更简单的提示词、更宽松的约束。主版本失败时切到降级版本虽然质量差一点但至少能出结果。7.4 人机协作的接口设计完全自动化的多智能体系统在复杂场景下往往不够可靠保留人工介入的接口是明智的。我的做法是在几个关键节点设置人工确认点任务分解完成后人工确认分解是否合理关键决策前人工确认方向系统无法处理时升级给人工这些确认点不用太多否则就失去自动化的意义了。我一般只在任务开始和结束时各设一个中间过程全自动。8. 关于提示词工程和拓扑优化的一些个人体会写到这里我想分享几个可能有点反直觉的体会。第一提示词不是越长越好而是越准越好。我早期写的提示词动辄两三千字后来发现很多内容是冗余的。现在我的提示词通常控制在 500-800 字但每个字都有明确作用。删掉那些正确的废话Agent 的表现反而更稳定。第二拓扑结构的价值在于约束而不是连接。很多人以为拓扑是为了让 Agent 之间能通信其实更重要的是限制它们不能随便通信。星型拓扑之所以稳定就是因为执行 Agent 之间不能直接对话所有交互都经过 Orchestrator 这个关卡。约束越明确系统越可控。第三优化是个持续过程没有一劳永逸的方案。我现在的项目里提示词和拓扑结构平均每两周就要微调一次。这不是因为设计得不好而是因为任务在变、模型在更新、成本要求在变。接受这个现实把优化当成日常而不是一次性工程。第四测试比设计更重要。多智能体系统的行为很难预测设计得再好也可能出意外。所以我把大量精力放在测试上——准备测试集、跑回归、看日志。测试做得越充分系统上线后越省心。最后说个具体的技巧如果你刚开始做多智能体先用两个 Agent 跑通一个最简单的协作场景比如一个负责生成、一个负责审查。把这个场景调稳了再往上加 Agent、加拓扑复杂度。我见过太多人一上来就搞五六个 Agent结果连两个 Agent 的协作都没搞明白。从最小可用系统开始逐步演进这是我在多智能体设计上最深的体会。