企业官网建设流程全解析

多智能体系统这两年从论文里的概念一路卷到了生产环境，我身边不少做大模型应用的朋友，从去年开始陆续把单 Agent 的 Demo 往多 Agent 架构上迁。但真到了落地这一步，问题就来了：Demo 里三个 Agent 互相聊天看着挺热闹，一上生产就发现延迟爆炸、状态丢失、循环调用停不下来、成本失控。我自己带团队做过几套多智能体系统，从客服工单分流到自动化测试编排都趟过一遍，踩的坑比写过的代码还多。这篇就把多智能体系统落地架构这件事拆开讲透，从编排模式选型、通信机制、状态管理、并发扛压到可观测性，把每个环节为什么这么设计、实际怎么落地讲清楚。不管你是刚接触 Agent 开发的新手，还是正在把单 Agent 往多 Agent 迁移的工程师，都能从里面找到能直接抄作业的东西。

1. 多智能体系统到底解决的是单 Agent 搞不定的什么问题

很多人一上来就问"多智能体框架选哪个"，这其实是个伪命题。选型之前得先想明白：你为什么需要多个 Agent？如果单 Agent 加几个工具就能搞定，硬拆成多 Agent 只会徒增复杂度和成本。我见过太多项目，本来一个带 Function Calling 的 Agent 就能处理，非要拆成规划 Agent、执行 Agent、审核 Agent 三个，结果延迟翻了三倍，调试难度指数级上升。

1.1 单 Agent 的能力天花板在哪里

单 Agent 的核心瓶颈有三个。第一是上下文窗口的物理限制。当一个任务需要处理的信息量超过模型上下文，比如要分析一份几百页的合同再生成摘要，单 Agent 要么截断信息要么分块处理，但分块之后块与块之间的关联就丢了。第二是工具数量的膨胀。当你的 Agent 挂了三十个工具，模型选择工具的准确率会明显下降，因为工具描述本身就占用了大量上下文，而且相似工具之间容易混淆。第三是职责耦合导致的提示词冲突。一个 Agent 既要严谨地做数据校验，又要发散地做创意生成，这两种人格写在同一个 System Prompt 里会互相打架，输出质量反而不如拆开。

我实测过一个场景：让单 Agent 同时负责"从用户自然语言里抽取订单信息"和"根据订单信息生成回复话术"。抽取要求精确、格式固定，生成要求灵活、有温度。放在一个 Agent 里，抽取准确率只有 82% 左右；拆成抽取 Agent 和回复 Agent 两个，抽取准确率提到 94%，回复质量也更稳定。这就是职责分离带来的收益。

1.2 多智能体真正带来价值的三类场景

不是所有任务都值得上多智能体。根据我的经验，真正能吃到多智能体红利的场景有三类。

第一类是任务可以天然分解为串行阶段，且每个阶段需要不同的能力配置。比如自动化测试编排：需求解析 Agent 负责把自然语言需求转成测试点，用例生成 Agent 负责写测试代码，执行 Agent 负责跑用例并收集结果，分析 Agent 负责判断失败原因。每个阶段用的模型、温度参数、工具集都不一样，拆开之后每个 Agent 都能调到最优配置。

第二类是需要多视角交叉验证。比如内容审核，一个 Agent 从合规角度审，一个从事实准确性角度审，一个从语气风格角度审，三个结果汇总后再决策。单 Agent 很难同时保持三个视角的独立性，容易顾此失彼。

第三类是任务规模超出单 Agent 处理能力，需要并行拆分。比如要分析一万条用户反馈，单 Agent 串行处理要几个小时，拆成十个 Agent 并行处理，每个处理一千条，时间直接降到几十分钟。这里的关键是拆分逻辑要清晰，且子任务之间无依赖。

1.3 拆分的代价：你必须提前算清楚的账

多智能体不是免费的午餐。每多一个 Agent，就多一次模型调用，成本和延迟都会上升。我一般会算一笔账：假设单 Agent 处理一个任务平均消耗 3000 token、耗时 8 秒，拆成三个 Agent 串行，token 消耗可能涨到 8000 到 12000，耗时涨到 20 到 30 秒。如果这个任务对延迟敏感，比如实时客服，那多智能体就不合适；如果是对延迟不敏感的批处理任务，比如夜间跑的数据分析，那多智能体完全可行。

还有一个隐性成本是调试复杂度。单 Agent 出问题，你看一遍完整对话就能定位；多 Agent 出问题，你得在多个 Agent 的对话记录之间来回跳，还得理解它们之间的消息传递。所以我在项目初期一定会把可观测性做扎实，后面会专门讲。

2. 编排模式选型：顺序、并行、层级还是群聊

编排模式决定了 Agent 之间怎么协作，这是多智能体架构的骨架。选错了模式，后面怎么优化都别扭。我见过有人用群聊模式做本该串行的任务，结果 Agent 之间互相打断，输出一团乱麻。下面把四种主流模式讲清楚，以及各自适合什么场景。

2.1 顺序编排：最稳但最容易踩的坑

顺序编排就是 Agent A 输出给 Agent B，B 输出给 C，像流水线一样。这是最容易理解和实现的模式，也是我推荐新手第一个上手的模式。它的优点是链路清晰、每步可验证、出错容易定位。

但顺序编排有个大坑：错误会沿着链路放大。如果第一个 Agent 抽取信息时错了一个字段，后面所有 Agent 都基于错误信息工作，最后输出全错。我的应对办法是在关键节点加校验 Agent，或者用结构化输出加 schema 校验。比如抽取 Agent 必须输出符合 JSON Schema 的结果，不符合就重试，重试两次还不行就转人工。

另一个坑是延迟累加。三个 Agent 串行，每个 8 秒，用户就要等 24 秒。如果业务能接受，那没问题；如果不能接受，就得考虑把部分步骤并行化，或者用流式输出让用户先看到部分结果。

2.2 并行编排：拆分逻辑比并行本身更重要

并行编排是把一个大任务拆成多个子任务，同时交给多个 Agent 处理，最后汇总。它的收益来自时间压缩，但前提是子任务之间真的没有依赖。

我做过一个用户反馈分析的并行编排：把一万条反馈按批次分给十个 Agent，每个 Agent 独立分析自己那批，最后汇总 Agent 把十份结果合并。这里的关键是拆分维度要均匀。如果按时间拆分，可能某段时间反馈特别多，导致某个 Agent 负载过高。我一般会先统计总量再均分，或者用动态任务队列，谁空闲谁领任务。

并行编排的另一个问题是结果汇总。十个 Agent 的输出格式可能不一致，汇总 Agent 得能处理这种不一致。我的做法是给每个 Agent 定死输出 schema，汇总 Agent 只做合并和去重，不做格式转换，这样最稳。

2.3 层级编排：主管 Agent 加执行 Agent 的经典结构

层级编排是有一个主管 Agent 负责规划和分派，下面多个执行 Agent 负责具体干活。这个模式适合任务复杂、需要动态决策的场景。主管 Agent 根据任务情况决定调用哪个执行 Agent、调用几次、按什么顺序。

这个模式最大的挑战是主管 Agent 的规划能力。如果主管规划得不好，比如该调 A 却调了 B，或者该调三次只调了一次，整个任务就废了。我的经验是给主管 Agent 提供清晰的执行 Agent 能力描述，并且限制它的决策空间。比如不要让它自由生成调用计划，而是让它从预定义的几个工作流里选一个，这样可控性高很多。

还有一个坑是主管 Agent 的上下文膨胀。所有执行 Agent 的结果都要回传给主管，如果执行 Agent 输出很长，主管的上下文很快就被撑爆。解决办法是让执行 Agent 输出精简摘要，详细结果存到外部存储，主管只拿摘要做决策。

2.4 群聊编排：最灵活也最难控的模式

群聊编排是多个 Agent 在一个共享对话里自由发言，通过某种规则决定谁发言。这个模式适合头脑风暴、多视角讨论这类场景。它的优点是灵活，Agent 之间可以互相启发；缺点是极难控制，容易出现无限循环、话题跑偏、成本失控。

我用群聊模式做过一个创意生成场景：三个 Agent 分别扮演不同风格，在一个对话里轮流提创意，互相点评。效果确实不错，但必须加两个约束：一是最大轮次限制，比如最多讨论十轮就强制结束；二是发言者选择规则，不能让 Agent 自己决定谁发言，而是用轮询或者基于内容相关度选择。没有这两个约束，群聊模式基本没法上生产。

3. 通信机制：Agent 之间到底怎么传消息

编排模式定了之后，下一个问题是 Agent 之间怎么通信。这看起来是个实现细节，但实际上直接影响系统的稳定性和可维护性。我见过用共享内存传消息的，也见过用消息队列的，各有各的适用场景。

3.1 共享状态 vs 消息传递：两种哲学

共享状态是指所有 Agent 读写同一个状态对象，比如一个全局的 context 字典。Agent A 往里面写结果，Agent B 从里面读。这种方式实现简单，适合 Agent 数量少、协作紧密的场景。但它有个致命问题：并发读写冲突。如果两个 Agent 同时写同一个字段，后写的会覆盖先写的。而且状态对象会越来越大，最后变成一个谁都不敢动的巨型字典。

消息传递是指 Agent 之间通过显式的消息来通信，每个 Agent 有自己的输入输出，不共享状态。这种方式更符合分布式系统的设计原则，Agent 之间解耦，容易测试和替换。缺点是消息的序列化和传递有开销，而且需要设计好消息格式。

我现在做项目基本都用消息传递，只有在 Agent 数量少于三个、且协作非常紧密时才考虑共享状态。消息传递虽然麻烦一点，但后期维护成本低太多。

3.2 消息格式设计：结构化是底线

消息格式我强烈建议用结构化数据，不要用自然语言。自然语言消息看起来灵活，但解析起来极其脆弱，模型稍微换个说法你的解析逻辑就崩了。结构化消息用 JSON 或者类似格式，字段固定，解析稳定。

一个典型的消息格式长这样：

{ "message_id": "msg_001", "sender": "extract_agent", "receiver": "validate_agent", "task_id": "task_123", "content": { "order_id": "ORD-2024-001", "amount": 299.00, "items": ["item_a", "item_b"] }, "status": "success", "timestamp": "2024-01-15T10:30:00Z" }

这里的关键字段是task_id，它让整条链路可以追踪。status字段让下游 Agent 知道上游是成功还是失败，失败时可以做相应处理。content是实际数据，用结构化格式。

提示：消息里一定要带task_id和trace_id，否则多 Agent 链路出问题时你根本没法把散落在各处的日志串起来。这个字段在调试阶段能救命。

3.3 同步调用 vs 异步消息：延迟和吞吐的权衡

同步调用是 Agent A 调用 Agent B 后阻塞等待结果，拿到结果再继续。这种方式逻辑简单，适合串行链路。但它的问题是阻塞导致资源浪费，A 在等 B 的时候什么都干不了。

异步消息是 A 把消息发到队列就返回，B 处理完再把结果发到另一个队列，A 从队列里取结果。这种方式吞吐高，适合并行和长链路场景。但它的复杂度高，需要处理消息顺序、重复消费、失败重试等问题。

我的选择标准是：如果链路短（三步以内）且延迟敏感，用同步；如果链路长或者需要并行，用异步。实际项目里经常是混合的，关键路径同步，非关键路径异步。

3.4 消息队列选型：别为了用而用

说到异步就绕不开消息队列。我见过不少项目上来就上 Kafka，结果运维成本高得吓人，实际消息量一天才几千条。消息队列选型要看实际需求。

如果消息量不大（每天百万级以下），用 Redis 的 List 或者 Stream 就够了，部署简单，团队都熟。如果消息量大且需要持久化和多消费者，再考虑 Kafka 或者 RabbitMQ。如果是在云上，直接用云厂商的托管队列服务最省心。

我个人的经验是：多智能体系统的瓶颈通常不在消息队列，而在模型调用。所以消息队列选个够用的就行，别在这上面过度设计。

4. 状态管理与记忆：多轮任务怎么不丢上下文

多智能体系统处理的任务往往不是一次性的，而是多轮的。比如一个客服工单，用户可能来回问好几轮，每轮都可能触发不同的 Agent。这时候状态管理就成了核心问题：怎么让每个 Agent 都知道之前发生了什么。

4.1 短期状态：单次任务内的上下文传递

短期状态是指一次任务执行过程中的上下文。比如顺序编排里，Agent A 的输出要传给 Agent B，B 的输出要传给 C。这个传递如果靠消息携带，那消息会越来越大，因为每一步都要把之前所有步骤的结果带上。

我的做法是状态外置。所有中间结果存到一个外部存储（Redis 或者数据库），消息里只带一个state_id，Agent 需要什么自己去取。这样消息保持精简，状态可以按需读取。缺点是 Agent 需要多一次读取操作，但这点开销相比模型调用可以忽略。

4.2 长期记忆：跨任务的知识沉淀

长期记忆是指跨任务的知识，比如用户的历史偏好、常见问题的解决方案。这部分通常用向量数据库存储，Agent 需要时做相似度检索。

这里有个坑：记忆检索的时机和数量。如果每个 Agent 都去检索记忆，会重复检索且可能检索到不相关的内容。我的做法是设一个专门的记忆管理 Agent，统一负责记忆的写入和检索，其他 Agent 通过它来访问记忆。这样记忆的读写有统一入口，质量可控。

4.3 状态一致性：并发场景下的坑

当多个 Agent 并行处理同一个任务的不同部分时，状态一致性就成了问题。比如两个 Agent 同时更新同一个订单的状态，一个改成"已支付"，一个改成"已发货"，最后状态就乱了。

解决办法有两个。一是状态更新串行化，所有状态更新走一个队列，按顺序处理。二是乐观锁，每次更新带版本号，版本不匹配就重试。我一般用第一种，简单可靠。第二种适合更新冲突少的场景。

4.4 状态清理：别让垃圾数据拖垮系统

状态数据如果不清理，会越积越多，最后拖垮存储和查询性能。我一般会设一个 TTL，任务完成后状态保留一段时间（比如七天）就自动删除。对于需要长期保留的状态，归档到冷存储。

这里有个细节：清理时机要和业务对齐。比如客服工单的状态，用户可能一周后还会来追问，那 TTL 就不能设太短。我一般会跟业务方确认一个合理的保留期，而不是拍脑袋定。

5. 并发扛压：多智能体系统怎么撑住高并发

多智能体系统的并发压力主要来自两个地方：一是外部请求的并发，二是内部 Agent 调用的并发。这两者的处理策略不一样。

5.1 外部请求并发：限流和排队是必须的

外部请求进来，如果直接透传给 Agent，模型调用会瞬间打满，然后所有请求都超时。所以限流是必须的。我一般用令牌桶算法做限流，根据模型的实际吞吐能力设置速率。

限流之后，超出的请求怎么办？两个选择：拒绝或者排队。拒绝就是直接返回"系统繁忙"，简单但用户体验差。排队是把请求放进队列，等有容量了再处理，用户体验好但需要控制队列长度，否则队列无限增长也会拖垮系统。

我的做法是分级处理：核心业务请求排队，非核心请求直接拒绝。队列长度设一个上限，超过上限的请求也拒绝。这样既保证了核心业务的可用性，又防止了系统被压垮。

5.2 内部 Agent 调用并发：连接池和超时控制

内部 Agent 调用模型 API 时，如果每个调用都新建连接，连接数会爆炸。所以要用连接池，复用连接。连接池大小根据模型 API 的并发限制来设，一般设成 API 限制的 80% 左右，留点余量。

超时控制也很关键。模型调用可能因为各种原因变慢，如果不设超时，一个慢调用会占着连接不放，最后连接池耗尽。我一般设两级超时：单次调用超时（比如 30 秒）和整个任务超时（比如 2 分钟）。单次超时触发重试，任务超时直接失败。

5.3 背压机制：让系统自己调节节奏

背压是指当系统处理不过来时，向上游反馈让它慢下来。在多智能体系统里，背压可以体现在多个层面。比如当 Agent 调用队列积压超过阈值时，限流器自动降低放行速率；当模型 API 返回 429（限流）时，调用方指数退避重试。

背压机制的核心是反馈回路。系统要能感知自己的负载，并根据负载调整行为。没有背压的系统，在压力下会直接崩溃；有背压的系统，会在压力下变慢但保持可用。

5.4 实测数据：一个客服场景的并发调优过程

我做过一个客服工单分流的系统，三个 Agent 串行：意图识别、工单分类、回复生成。上线初期，并发 50 的时候就开始大量超时。排查发现瓶颈在意图识别 Agent，它用的模型响应慢，平均 3 秒，而且没有连接池，每次新建连接。

优化措施：一是给意图识别 Agent 加了连接池，复用连接；二是把意图识别模型换成更快的轻量模型，准确率只降了 2% 但速度快了一倍；三是加了限流，把并发控制在 30。优化后，并发 100 的情况下 P99 延迟从超时降到 8 秒，系统稳定运行。

6. 可观测性：多 Agent 链路出问题怎么快速定位

多智能体系统最让人头疼的就是出问题时不知道哪个环节错了。单 Agent 你看一遍对话就知道，多 Agent 你得在多个 Agent 的日志之间跳。所以可观测性不是可选项，是必选项。

6.1 全链路追踪：trace_id 贯穿始终

全链路追踪的核心是给每个任务分配一个trace_id，这个 ID 在整条链路的所有 Agent 调用、模型调用、工具调用中传递。这样你就能通过一个trace_id把所有相关日志串起来。

实现上，我一般用 OpenTelemetry 这类标准框架，它支持自动埋点和手动埋点。自动埋点覆盖 HTTP 调用、数据库调用这些通用操作，手动埋点覆盖 Agent 内部的逻辑。两者结合，基本能做到全链路覆盖。

6.2 关键指标监控：延迟、成功率、成本

除了追踪，还要监控关键指标。我一般监控这几类：

• 延迟：每个 Agent 的 P50、P95、P99 延迟，以及整条链路的端到端延迟。
• 成功率：每个 Agent 的调用成功率，失败原因分类。
• 成本：每个 Agent 的 token 消耗，按任务类型和用户维度统计。
• 队列深度：各消息队列的积压情况。

这些指标要能实时看，也要能按时间维度看趋势。我一般用 Prometheus 收集指标，Grafana 做展示。

6.3 日志规范：结构化日志是基础

日志一定要结构化，用 JSON 格式，字段固定。关键字段包括trace_id、agent_name、step、status、duration、error。这样日志可以方便地被检索和分析。

我见过用纯文本日志的，出问题时只能 grep，效率极低。结构化日志配合日志分析工具（比如 ELK），可以快速筛选出某个trace_id的所有日志，或者某个 Agent 的所有错误日志。

6.4 告警策略：别让告警淹没你

告警要精准，不能什么都告。我一般设这几类告警：

• 错误率告警：某个 Agent 的错误率超过阈值（比如 5%）持续 5 分钟。
• 延迟告警：端到端 P99 延迟超过阈值持续 5 分钟。
• 成本告警：单日 token 消耗超过预算的 80%。
• 队列积压告警：队列深度超过阈值持续 10 分钟。

告警要分级，P0 告警打电话，P1 告警发消息，P2 告警只记录。这样避免告警疲劳。

7. 框架选型：LangGraph、AutoGen 还是自己撸

框架选型是很多人纠结的问题。我的观点是：框架是加速器，不是必需品。如果你的需求简单，自己撸一个轻量编排层可能比用框架更可控。如果需求复杂，框架能帮你省很多事。

7.1 主流框架的能力边界

LangGraph 适合有状态的多 Agent 工作流，它的图结构很直观，状态管理做得好。缺点是学习曲线陡，而且和 LangChain 生态绑定较深。

AutoGen 适合对话式的多 Agent 协作，它的群聊模式开箱即用。缺点是控制粒度粗，复杂逻辑不好实现。

CrewAI 适合角色扮演式的多 Agent 协作，定义角色和任务很简洁。缺点是灵活性一般，复杂编排支持有限。

如果这些框架都不满足，那就自己撸。自己撸的好处是完全可控，坏处是什么都要自己写。我一般建议先用框架快速验证，验证通过后再评估要不要替换成自研。

7.2 自研编排层的核心模块

如果决定自研，核心模块包括：Agent 注册与发现、消息路由、状态管理、执行引擎、可观测性。这些模块不用一次做全，按需迭代。

我的经验是先做最小可用版本：一个简单的顺序执行引擎，加上基本的日志。跑通之后再逐步加并行、加状态管理、加监控。不要一上来就设计一个大而全的架构，那样大概率会过度设计。

7.3 选型的决策清单

选框架前问自己几个问题：任务复杂度如何？团队技术栈是什么？是否需要深度定制？运维能力如何？根据答案来选。

如果任务简单、团队熟悉 Python、不需要深度定制，用 LangGraph 或 CrewAI 快速上手。如果任务复杂、需要深度定制、团队有分布式系统经验，自研更合适。如果团队运维能力弱，选托管服务或者轻量框架。

8. 落地踩坑实录：那些文档不会告诉你的问题

最后这部分是我踩过的坑，都是文档里不会写的，但实际项目中一定会遇到。

8.1 Agent 无限循环：最常见也最致命

多 Agent 系统最容易出的问题就是无限循环。Agent A 调用 B，B 觉得信息不够又调用 A，A 又调用 B，如此往复。我遇到过一次，两个 Agent 互相调用了几十次，token 消耗直接爆表。

解决办法是设置最大调用深度。每个任务有一个调用计数器，超过阈值就强制终止。阈值设多少？我一般设 10 到 15，根据任务复杂度调整。另外，Agent 之间的调用关系要避免环形依赖，如果必须有环，一定要有退出条件。

8.2 提示词冲突：Agent 之间互相打架

多个 Agent 的提示词如果不协调，会出现互相打架的情况。比如 Agent A 被要求输出简洁，Agent B 被要求输出详细，A 的输出给 B 之后，B 觉得信息不够又去问 A，A 又输出简洁的，死循环。

解决办法是统一输出规范。所有 Agent 的输出格式和详细程度要有统一标准，或者至少相邻 Agent 之间要协调。我在项目初期会画一张 Agent 交互图，标注每个 Agent 的输入输出要求，确保上下游匹配。

8.3 成本失控：token 消耗的隐形黑洞

多 Agent 系统的 token 消耗比单 Agent 高得多，而且很容易失控。我遇到过一次，一个任务本来预算 5000 token，实际消耗了 50000，原因是某个 Agent 把整个对话历史都塞进了上下文。

控制成本的办法：一是精简上下文，只传必要信息，不要传整个历史；二是设置 token 预算，每个任务有预算上限，超了就终止；三是监控成本，按任务类型和用户维度统计，发现异常及时处理。

8.4 模型不一致：不同 Agent 用不同模型的坑

不同 Agent 用不同模型时，输出风格和格式可能不一致。比如 Agent A 用 GPT-4 输出 JSON，Agent B 用另一个模型输出 Markdown，汇总时就乱了。

解决办法是统一输出格式，不管用什么模型，输出都要符合统一的 schema。可以在每个 Agent 后面加一个格式化层，把输出转成标准格式。这样下游 Agent 不用关心上游用的什么模型。

8.5 测试困难：多 Agent 系统怎么测

多 Agent 系统的测试比单 Agent 难得多，因为涉及多个组件的交互。我的做法是分层测试：单元测试测单个 Agent 的逻辑，集成测试测 Agent 之间的交互，端到端测试测整条链路。

单元测试用 mock 把上下游隔离，只测当前 Agent。集成测试用真实的上下游，但用固定的输入输出。端到端测试用真实的全链路，但用录制的数据回放，避免依赖外部服务。

注意：多 Agent 系统的测试一定要覆盖异常路径，比如某个 Agent 超时、返回错误、返回格式不对。这些异常路径在实际运行中一定会出现，提前测到能省很多事。

9. 从单 Agent 迁移到多 Agent 的渐进式路径

如果你现在有一个跑得还不错的单 Agent 系统，想迁移到多 Agent，我建议渐进式迁移，不要推倒重来。

9.1 第一步：识别可拆分的边界

先分析现有单 Agent 的职责，找出可以拆分的边界。判断标准是：这部分职责是否有独立的输入输出？是否用了不同的工具集？是否有不同的性能要求？如果满足，就可以考虑拆出来。

我一般会先拆出最独立的那部分，比如一个专门做数据校验的模块。拆出来之后单独部署，单 Agent 通过接口调用它。这样风险最小，收益也能看到。

9.2 第二步：建立通信层

拆出第一个 Agent 后，就要建立通信层。我建议用 HTTP 或者消息队列，不要用进程内调用，这样后续扩展方便。通信层要做好版本管理，接口变更要兼容旧版本。

9.3 第三步：逐步替换和验证

每拆一个 Agent，都要做对比验证：新架构的输出和旧架构的输出是否一致？延迟和成本变化如何？如果变差了，要分析原因，是拆分不合理还是实现有问题。

我一般会保留旧架构一段时间，用影子流量做对比。新架构跑一段时间没问题后，再切正式流量。

9.4 第四步：优化和固化

全部拆完之后，做整体优化：调整 Agent 之间的调用关系、优化提示词、调优并发参数。优化到稳定后，把架构和配置固化下来，形成文档和模板，方便后续复用。

这套渐进式路径我走过两次，每次都是三到六个月完成迁移，过程中系统一直可用，没有出现大的故障。相比推倒重来，这种方式风险可控得多。

多智能体系统落地这件事，说到底是在能力、成本、复杂度三者之间找平衡。没有银弹，只有适合当前场景的取舍。我自己的体会是，先把单 Agent 用到极致，确实遇到瓶颈了再上多 Agent，而且一定要从最简单的顺序编排开始，把可观测性和状态管理做扎实，再逐步加复杂度。那些一上来就设计复杂架构的项目，十个有九个会烂尾。