多智能体协作系统如何重构代理型业务：架构设计与落地实践

1. 从"agency-agents"这个标题说起：它到底在讲什么

第一次看到"agency-agents"这个组合词，我脑子里蹦出来的第一反应是——这大概率不是一个单纯的技术名词，而是一个把"代理机构"和"智能体"两个概念揉在一起的复合命题。拆开看，"agency"在英文语境里既可以指代"代理机构、中介组织"，也可以指"能动性、自主行动的能力"；而"agents"在当下的技术语境里，几乎已经被"智能体"这个含义牢牢占据。把这两个词拼在一起，它指向的核心领域其实非常清晰：用智能体来重构传统代理机构的工作流，或者反过来，为智能体赋予某种"代理机构"级别的组织化协作能力。

这个标题背后藏着的潜在需求，我判断主要有三层。第一层是效率焦虑——传统代理机构（无论是营销代理、房产中介、招聘猎头还是法律咨询）的核心成本都压在人力上，一个案子从接洽到交付，中间要经过大量重复性的信息收集、整理、分发、跟进工作，这些环节恰恰是智能体最擅长啃的骨头。第二层是协作复杂度——单个智能体解决单点问题已经不新鲜了，难的是让一群智能体像一家真正的代理机构那样分工协作，有人负责获客、有人负责执行、有人负责质检、有人负责交付。第三层是可控性——代理机构最怕的是"黑箱"，客户把需求交给你，你得让每一步都可见、可追溯、可干预，智能体系统如果做不到这一点，就没法真正嵌入商业流程。

所以这篇博文我想聊的，不是某个具体的开源项目或者某个产品的使用教程，而是围绕"agency-agents"这个命题，把多智能体协作系统在代理型业务场景下的设计思路、核心实现、踩坑经验和落地方法掰开揉碎讲一遍。适合谁来读？如果你是对多智能体系统感兴趣的技术人员，这篇能给你一套可参考的架构思路；如果你是代理机构的经营者或者业务负责人，这篇能帮你判断哪些环节值得用智能体改造、怎么改才不翻车；如果你只是刚听说"智能体"这个词想搞明白它到底能干嘛，我也会尽量用生活化的例子把原理讲透。

我自己的背景是做过几年企业级自动化系统的落地，中间踩过不少"看起来很美、跑起来很崩"的坑，所以下面讲的东西，尽量往实操上靠，少讲虚的。

2. 整体设计思路：为什么代理型业务适合多智能体架构

2.1 单智能体的天花板在哪里

先说一个我反复验证过的结论：单个智能体做"助手"很称职，做"代理"很吃力。这两者的区别在哪？助手是你问它答，你让它做一步它做一步，主动权在你手里；代理是你给它一个目标，它自己规划路径、自己调用资源、自己判断什么时候该停下来问你，主动权在它手里。一旦主动权转移，单智能体的几个硬伤就暴露了。

第一个硬伤是上下文窗口的物理限制。代理型业务往往涉及长周期的信息积累，比如一个营销代理要跟踪一个客户从初次接触到最终成交的全过程，中间产生的邮件、会议纪要、修改意见、报价记录加起来轻松超过几万字。单智能体要么记不住，要么记串了，要么为了记住而牺牲推理质量。

第二个硬伤是角色冲突。同一个智能体既要当"销售"去说服客户，又要当"质检"去挑自己方案的毛病，这在逻辑上是拧巴的。就像你让一个人既当运动员又当裁判，他很难对自己下狠手。多智能体架构里，这两个角色由不同的实例承担，互相制衡，输出质量会明显不一样。

第三个硬伤是故障隔离。单智能体一旦在某一步跑偏，整个任务链条就崩了，而且很难定位是哪一步出的问题。多智能体架构里，每个智能体是一个独立的执行单元，某个环节出错可以单独重试、单独替换，不会污染全局。

2.2 代理机构的组织逻辑天然适配多智能体

我之所以觉得"agency-agents"这个命题有意思，是因为代理机构的组织结构和多智能体系统的架构之间存在一种同构关系。你去看任何一家成熟的代理机构，它的组织方式无非是这么几层：

• 客户对接层：负责理解需求、管理预期、传递信息，对应到系统里就是"入口智能体"或"路由智能体"。
• 任务分解层：把客户的大需求拆成可执行的小任务，分配给不同专长的人，对应到系统里就是"规划智能体"或"调度智能体"。
• 专业执行层：文案、设计、数据分析、渠道投放各司其职，对应到系统里就是各个"领域智能体"。
• 质量把控层：审核、校对、合规检查，对应到系统里就是"评审智能体"或"校验智能体"。
• 交付归档层：整理成果、生成报告、存档备查，对应到系统里就是"输出智能体"。

这种同构关系意味着，你不需要凭空发明一套多智能体协作范式，直接照着代理机构的运作方式来设计就行。这也是我在实际项目里最常用的一个思路：先把业务流程画出来，再把流程里的每个角色映射成一个智能体，最后定义清楚角色之间的交接协议。这样做的好处是，业务方看得懂你的架构图，技术人员也知道每个模块该干什么，沟通成本大幅降低。

2.3 方案选型：为什么我倾向于"轻编排+重协议"

多智能体系统的实现路线，市面上大致分两派。一派是重编排，用一个中心化的调度器把所有智能体的行为都管起来，每一步走哪、调谁、传什么参数，全部由调度器决定。另一派是重协议，智能体之间通过约定好的消息格式和交互规则自主协作，中心调度器只做最轻量的路由。

我踩过的坑告诉我，代理型业务场景下，"轻编排+重协议"是更稳的选择。原因有三点。第一，代理业务的需求变化太快，今天客户要这个，明天要那个，如果所有逻辑都硬编码在中心调度器里，改一次需求就要动一次核心代码，风险极高。第二，重编排的调度器容易成为单点瓶颈，一旦它挂了或者逻辑出bug，整个系统瘫痪。第三，重协议的方式更接近真实代理机构的运作——每个角色知道自己该干什么、该跟谁对接，不需要老板时时刻刻盯着。

具体到协议设计，我一般会定义三个东西：任务描述格式（一个任务包含哪些字段，比如任务ID、目标、输入、期望输出、截止时间、优先级）、状态流转规则（任务从创建到完成要经过哪些状态，每个状态允许哪些操作）、异常处理约定（任务失败时是重试、转交还是上报）。这三个东西定清楚了，智能体之间的协作就有了共同语言，后面加新角色、改老角色都不会乱。

3. 核心细节解析：多智能体协作系统的关键构件

3.1 智能体的"人设"怎么定才不飘

给智能体写系统提示词（system prompt）这件事，看起来简单，实际上是最容易翻车的地方。我见过太多项目，提示词写得像散文，什么"你是一个专业的、有经验的、负责任的助手"，这种描述对模型来说几乎等于没说。好的智能体人设应该是可操作、可验证、有边界的。

我的做法是，每个智能体的人设必须包含四个部分：身份定义（你是谁，你代表谁）、能力边界（你能做什么，你不能做什么）、输出规范（你的输出长什么样，格式、长度、语气）、升级条件（什么情况下你必须停下来找人）。举个例子，一个负责初步需求收集的智能体，它的人设可能是这样的：

你是XX代理机构的初级客户对接专员。你的任务是收集客户的基本需求信息，包括预算范围、时间要求、核心诉求、决策流程。你不负责报价，不负责承诺交付时间，不负责解释技术细节。你的输出必须是一份结构化的需求摘要，包含上述四个字段，每个字段不超过三句话。如果客户提出的需求超出你的理解范围，或者涉及合同条款、价格谈判，你必须将对话转交给高级对接专员。

你看，这样写出来的人设，模型执行起来就有明确的抓手。它知道自己该问什么、不该问什么、问到什么程度该停。能力边界和升级条件这两条尤其重要，它们是防止智能体"自作主张"的关键闸门。我吃过亏，早期项目里没写升级条件，结果一个负责收集需求的智能体自己给客户报了个价，虽然只是随口一说，但客户当真了，后面扯皮扯了很久。

3.2 任务分解的粒度控制

任务分解是规划智能体的核心工作，也是整个系统里最考验设计功力的地方。分解得太粗，执行智能体不知道从哪下手；分解得太细，智能体之间的通信开销会爆炸，而且容易在细节上跑偏。

我的经验是，任务分解的粒度应该以"一个智能体在一次交互中能完成的工作量"为基准。什么叫一次交互？就是智能体接收输入、处理、输出结果，中间不需要跟其他智能体来回确认。如果一个任务需要多个智能体反复沟通才能完成，那说明它分解得还不够细；如果一个任务简单到智能体一句话就能搞定，那说明它分解得太细了，应该合并到相邻任务里。

具体操作上，我会用一个"三层分解法"。第一层是目标层，把客户的大需求拆成几个里程碑式的目标，比如"完成市场调研""产出创意方案""执行投放计划"。第二层是任务层，把每个目标拆成可独立执行的任务，比如"市场调研"下面拆成"收集竞品信息""分析目标人群""整理行业趋势"。第三层是动作层，把每个任务拆成具体的操作步骤，比如"收集竞品信息"下面拆成"确定竞品清单""抓取公开信息""整理成对比表格"。规划智能体负责第一层和第二层的分解，执行智能体负责第三层的展开。

这里有个细节值得注意：分解出来的任务之间要尽量解耦。什么叫解耦？就是任务A的完成不依赖任务B的中间结果，或者依赖关系是单向的、明确的。如果两个任务互相依赖，那它们就应该合并成一个任务，否则很容易出现死锁——A等B的输出，B等A的输出，谁也动不了。

3.3 智能体之间的通信协议设计

通信协议是多智能体系统的血管，设计得好，信息流动顺畅；设计得不好，到处堵车。我一般会从三个维度来设计协议：消息格式、交互模式、超时机制。

消息格式方面，我强烈建议用结构化格式，比如JSON，而不是自然语言。自然语言灵活但不可靠，同一个意思可以有十种表达，解析起来容易出错。结构化格式虽然写起来麻烦一点，但胜在明确、可校验、可追溯。一个典型的消息体大概长这样：

{ "message_id": "msg-20240115-001", "sender": "planning_agent", "receiver": "research_agent", "task_id": "task-20240115-003", "intent": "execute_task", "payload": { "goal": "收集三个主要竞品的定价策略", "constraints": ["只使用公开信息", "输出格式为对比表格"], "deadline": "2024-01-15T18:00:00Z" }, "context_ref": "ctx-20240115-001" }

交互模式方面，我常用的是请求-响应模式和发布-订阅模式的组合。请求-响应用于点对点的任务分派，比如规划智能体给执行智能体派活；发布-订阅用于状态广播，比如某个任务完成了，所有关心的智能体都能收到通知。这两种模式混用，既能保证任务分派的准确性，又能保证状态同步的及时性。

超时机制是很多人会忽略的一环。代理型业务里，一个任务卡住不动是常有的事，如果没有超时机制，整个流程就会僵在那里。我的做法是，每个任务都带一个超时时间，超时后自动触发重试或转交。超时时间设多长？取决于任务的复杂度和业务对时效的要求。简单的信息查询类任务，我一般设5分钟；复杂的分析类任务，设30分钟到1小时；需要人工介入的任务，设24小时。这个值不是拍脑袋定的，而是根据历史执行数据统计出来的——跑一段时间后，你会知道每类任务的平均耗时和长尾耗时，超时时间就设在长尾耗时的1.5倍左右。

3.4 状态管理与上下文传递

多智能体系统里，状态管理是个容易被低估的难题。单智能体的时候，状态就在它的上下文窗口里，简单直接。多智能体的时候，状态分散在各个智能体手里，怎么保证大家看到的是同一份"真相"？

我的方案是中心化存储+局部缓存。所有任务的状态、中间结果、关键决策都写到一个中心化的存储里（可以是数据库，也可以是文件系统，看规模），每个智能体在需要的时候去读，处理完再写回去。同时，每个智能体本地缓存一份自己最近用到的上下文，减少重复读取。这样做的好处是，任何时刻你都能从中心存储里还原出整个系统的完整状态，排查问题的时候特别有用。

上下文传递是另一个坑。智能体A的输出要传给智能体B，传多少？全传过去，B的上下文窗口可能装不下；只传摘要，B可能丢失关键细节。我的经验是，传递"任务相关的上下文"而不是"全部上下文"。具体来说，就是根据B的任务描述，从A的输出里筛选出B真正需要的部分。这个筛选动作可以由A来做（A在输出时标注哪些是给B的），也可以由一个专门的"上下文管理智能体"来做。我倾向于后者，因为让执行智能体分心去考虑"我的输出要给谁用"会降低它的执行质量。

4. 实操过程：从零搭一个代理型多智能体系统

4.1 环境准备与基础依赖

假设你要从零开始搭一个代理型多智能体系统，第一步不是写代码，而是把业务流程画清楚。我见过太多人一上来就搭框架、调API，结果搭到一半发现业务流程没理清，推倒重来。正确的顺序是：先画业务流程图，再定角色清单，再设计通信协议，最后才是写代码。

业务流程图画到什么程度？我的标准是，每个方框代表一个明确的动作，每个箭头代表一次明确的信息传递。比如"客户提交需求"是一个方框，"需求传递给对接专员"是一个箭头，"对接专员整理需求"是下一个方框。画完之后，你数一数有多少个方框，大概就知道需要多少个智能体角色；数一数有多少个箭头，大概就知道需要定义多少种消息类型。

技术栈方面，我的建议是不要过度追求新框架。多智能体系统的核心逻辑其实不复杂，用你最熟悉的那套技术栈就行。Python的话，基础的异步框架加上一个HTTP客户端库，足够搭出一个可用的原型。数据库用SQLite起步，规模上来了再换PostgreSQL。消息队列前期可以不用，用数据库轮询也能跑，等并发量上来了再引入。过早引入复杂基础设施是多智能体项目失败的主要原因之一，我见过一个团队，系统还没跑通就先上了Kafka和Redis，结果光调试基础设施就花了两周，业务逻辑一行没写。

4.2 第一个智能体的实现：入口路由

入口路由智能体是整个系统的门面，它的职责是接收外部输入，判断意图，分派给对应的处理智能体。这个智能体看起来简单，但它是整个系统里最需要精心设计的，因为所有外部输入都要经过它，它的判断质量直接影响后续所有环节。

实现上，我一般会把它拆成两步：意图识别和路由决策。意图识别用一次模型调用完成，输入是用户的原始消息，输出是一个意图标签（比如"新需求""进度查询""投诉""闲聊"）。路由决策是一个规则引擎，根据意图标签和当前系统状态，决定把消息发给哪个智能体。为什么要拆成两步？因为意图识别是概率性的，可能出错；路由决策是确定性的，可以审计。拆开之后，如果路由错了，你能快速定位是意图识别错了还是路由规则错了。

这里有个实操细节：意图识别的输出要包含置信度。如果置信度低于某个阈值（我一般设0.7），就不要硬路由，而是转给一个"澄清智能体"去跟用户确认。这个设计能挡掉大量因为意图误判导致的后续混乱。我早期没做这个，结果用户说"我想了解一下你们的服务"，系统把它识别成"新需求"，直接派给了需求收集智能体，收集了一堆信息之后才发现用户只是随便问问，浪费了一轮交互。

4.3 规划智能体的任务分解实操

规划智能体是系统的大脑，它的输入是一个目标，输出是一个任务列表。实现上，我一般用**"先发散再收敛"**的两阶段策略。第一阶段，让模型尽可能多地列出完成目标所需的所有步骤，不设限制，鼓励它想全。第二阶段，让模型对列出的步骤进行合并、排序、去重，形成一个结构化的任务列表。

这个策略的好处是，避免模型过早收敛到某个局部最优解。如果直接让模型输出一个任务列表，它往往会给出一个"看起来合理但不够全面"的方案。先发散再收敛，能逼着模型把各种可能性都考虑一遍，然后再做取舍。

任务列表的格式，我一般要求包含这几个字段：任务ID、任务描述、依赖任务（前置任务ID列表）、预期输出、优先级。依赖任务这个字段特别重要，它是后续调度排序的依据。举个例子，"分析竞品定价"这个任务依赖"确定竞品清单"，那调度的时候就必须先完成"确定竞品清单"。

这里有个坑要注意：模型给出的依赖关系可能是循环的。A依赖B，B依赖C，C又依赖A，这种循环依赖如果不检测出来，调度器就会死锁。我的做法是，在规划智能体输出任务列表后，加一个依赖图校验步骤，用拓扑排序检测是否存在环。如果有环，就把这个任务列表打回去让规划智能体重新生成，并在提示词里明确告诉它"上次生成的依赖关系存在循环，请修正"。

4.4 执行智能体的工具调用与结果校验

执行智能体是干活的手，它的核心能力是调用工具。工具可以是外部API（比如搜索引擎、数据库查询、文件读写），也可以是内部函数（比如格式转换、数据清洗）。工具调用的设计，我总结下来有三个要点。

第一，工具描述要精确。模型决定调不调一个工具、怎么调，完全依赖你对工具的描述。描述里要写清楚：这个工具是干什么的、接受什么参数、参数的类型和取值范围、返回什么、什么情况下会失败。我见过有人写工具描述就一句话"查询数据库"，模型根本不知道查什么库、怎么查、返回什么格式，调用成功率极低。

第二，工具调用要有重试和降级。外部工具不稳定是常态，调用失败不能直接让任务失败。我的做法是，每个工具调用配一个重试策略（重试几次、间隔多久）和一个降级策略（重试都失败了怎么办，是返回部分结果还是转人工）。降级策略尤其重要，它决定了系统在异常情况下的行为是否可接受。

第三，工具返回结果要校验。模型调用工具后拿到的结果，不能直接信，要校验格式和内容是否符合预期。比如你让模型查一个数字，它返回了一段文字，这就是格式不符，要触发重试或报错。校验规则可以写死，也可以让一个专门的"校验智能体"来做。我倾向于写死规则，因为校验逻辑本身不应该有太多不确定性。

4.5 评审智能体的质量把关

评审智能体的职责是对执行智能体的输出进行质量检查，不合格的打回去重做。这个角色的设计，关键在于评审标准要明确、可操作。如果评审标准是"输出质量要高"，那评审智能体只能凭感觉打分，结果不可靠。如果评审标准是"输出必须包含A、B、C三个部分，每个部分不少于X字，且不能出现D类错误"，那评审就有据可依。

我一般会把评审标准拆成硬性规则和软性判断两部分。硬性规则用代码实现，比如检查输出是否包含必填字段、字数是否达标、是否包含敏感词。软性判断用模型实现，比如评估输出的逻辑是否通顺、论据是否充分、语气是否合适。硬性规则先跑，不通过直接打回，不用浪费模型调用；硬性规则通过了再跑软性判断，这样效率最高。

评审不通过怎么办？我的策略是给两次修改机会。第一次不通过，把评审意见附上，让执行智能体重做；第二次还不通过，就升级给人工处理。为什么是两次？因为实践中我发现，大部分问题第一次修改就能解决，少数需要第二次，极少数两次都改不好的，往往不是执行智能体的问题，而是任务描述本身有问题，这时候人工介入是最合理的。

5. 常见问题与排查技巧实录

5.1 智能体"幻觉"导致任务跑偏

幻觉是多智能体系统里最常见的问题，表现形式是智能体编造了不存在的信息，或者对任务的理解出现了偏差。排查幻觉问题，我一般从三个方向入手。

方向一：检查提示词是否有歧义。很多幻觉其实是提示词写得不够明确导致的。比如你写"分析市场数据"，模型不知道你要分析哪些维度、用什么方法、输出什么格式，它就只能猜，一猜就容易猜错。把提示词改写成"分析过去三个月的销售数据，按地区维度计算环比增长率，输出一个包含地区、月份、增长率的表格"，幻觉率会大幅下降。

方向二：检查上下文是否被污染。多智能体系统里，上下文是共享的，如果某个智能体输出了错误信息，这个信息可能会被后续智能体当成事实继续使用，错误就被放大了。排查方法是，在关键节点加"事实校验"步骤，对上游传来的关键信息做一次独立验证。比如上游说"竞品A的定价是100元"，下游在使用这个信息前，先自己去查一遍，确认无误再用。

方向三：检查模型选择是否合适。不同模型的能力边界不一样，有些模型擅长推理，有些擅长生成，有些擅长遵循指令。如果你的任务需要严格遵循格式，就选指令遵循能力强的模型；如果需要复杂推理，就选推理能力强的模型。用错模型，幻觉率会明显偏高。

5.2 任务卡死与死锁的处理

任务卡死是多智能体系统的另一个高频问题，表现为某个任务长时间处于"进行中"状态，既不完成也不报错。排查卡死问题，我一般按这个顺序来。

首先看是不是在等一个永远不会来的消息。多智能体系统里，智能体A等智能体B的输出，但B因为某种原因没有发送，A就会一直等。排查方法是，检查所有"等待中"的任务，看它们等待的消息是否在系统里有对应的发送记录。如果没有，说明发送方出了问题，要去查发送方的日志。

其次看是不是陷入了循环依赖。前面提过，任务之间的依赖关系如果成环，调度器就会死锁。排查方法是，把当前所有未完成任务的依赖关系画成图，看有没有环。有环的话，要么打破环（手动调整依赖关系），要么把环上的任务合并成一个任务。

最后看是不是资源耗尽。如果系统并发跑了很多任务，可能会遇到连接池耗尽、内存不足、API限流等问题，导致任务无法推进。排查方法是，看系统资源监控，确认是否有资源瓶颈。有的话，要么扩容，要么加限流，要么优化资源使用效率。

预防卡死，我的经验是给每个任务设超时，超时后自动触发异常处理流程。这个前面提过，但值得再强调一遍，因为它是最后一道防线。没有超时机制的系统，一旦卡死就是永久卡死，有了超时机制，至少能自动恢复。

5.3 输出质量不稳定的调优

输出质量不稳定，时好时坏，是多智能体系统落地时最让人头疼的问题。我的调优经验可以总结成一张表：

这张表是我踩了无数坑之后总结出来的，基本上覆盖了80%的质量问题。调优的时候，建议一次只改一个变量，改完观察一段时间，确认有效再改下一个。同时改多个变量，你根本不知道是哪个改动起了作用。

5.4 成本控制的实战技巧

多智能体系统跑起来之后，成本是个绕不开的话题。每个智能体每次交互都要调用模型，任务一多，token消耗量很可观。我总结了几条成本控制的实战技巧。

技巧一：分级用模型。不是所有任务都需要用最强的模型。简单的分类、提取、格式化任务，用轻量模型就够了；复杂的推理、规划、创作任务，才用强模型。我一般会把任务按复杂度分成三档，分别对应轻量、中等、强力三档模型，成本能降一半以上。

技巧二：缓存重复结果。很多任务其实是重复的，比如同一个竞品的信息查询，今天查了明天又查。把查询结果缓存起来，下次直接读缓存，能省不少调用。缓存的有效期根据信息的时效性来定，时效性强的设短一点，时效性弱的设长一点。

技巧三：压缩上下文。传给模型的上下文越长，token消耗越大。在传递上下文之前，先做一次压缩，只保留跟当前任务相关的部分。压缩可以用模型做，也可以用规则做，规则做成本更低，但效果可能差一点，看你的取舍。

技巧四：批量处理。如果有一批相似的任务，不要一个一个跑，攒起来批量跑。批量处理能摊薄每次调用的固定开销，整体成本会低一些。当然，批量处理会增加延迟，适合对时效性要求不高的场景。

6. 落地经验：从原型到生产要跨过的坎

6.1 可观测性建设

原型阶段，系统跑在本地，出问题了你直接看日志、打断点，很快能定位。生产阶段，系统跑在服务器上，任务量大了，日志多了，定位问题就没那么容易了。所以可观测性建设是生产化的必修课。

我一般会建三个东西：任务追踪、指标监控、告警机制。任务追踪是给每个任务打一个唯一ID，这个ID贯穿任务的全生命周期，从创建到完成，每一步操作都记录在案。有了这个ID，你查一个任务的历史，就像查快递物流一样，一目了然。指标监控是统计系统的关键指标，比如任务成功率、平均耗时、各智能体的调用次数、token消耗量。这些指标能帮你发现系统的异常趋势，比如成功率突然下降、某个智能体调用量暴增。告警机制是在指标异常时主动通知你，不用你天天盯着监控看。告警规则要设得合理，太敏感了天天误报，太迟钝了出大事才发现。

6.2 人工介入的设计

多智能体系统再智能，也不可能100%自动化，人工介入的通道必须留好。人工介入的设计，关键在于介入时机和介入方式。

介入时机方面，我一般设三个触发点：智能体主动请求（智能体遇到不确定的情况，主动上报请求人工决策）、评审多次不通过（前面提过，两次修改还不通过就升级人工）、超时未完成（任务超时后自动升级人工）。这三个触发点覆盖了大部分需要人工介入的场景。

介入方式方面，我倾向于异步介入而不是同步介入。同步介入是任务停下来等人处理，异步介入是任务继续跑其他部分，等人处理完再合并。异步介入的效率更高，但实现复杂度也更高。如果业务对时效性要求不高，同步介入更简单可靠；如果时效性要求高，就得做异步介入。

6.3 持续迭代的机制

多智能体系统不是搭完就完事了，它需要持续迭代。迭代的依据来自两个方面：运行数据和用户反馈。运行数据告诉你系统哪里跑得不好，用户反馈告诉你用户哪里不满意。

我一般会建一个问题收集-分析-改进的闭环。问题收集是把运行中出现的异常、用户的投诉、评审不通过的案例都记录下来。分析是定期（比如每周）回顾这些问题，找出共性问题，判断是提示词问题、协议问题还是架构问题。改进是针对分析结果做调整，改完上线，观察效果。这个闭环转起来，系统就会越跑越顺。

迭代的时候有个原则：小步快跑，不要大改。多智能体系统是个复杂系统，大改很容易引入新问题，而且出了问题很难定位是哪个改动导致的。小步快跑，每次只改一个点，改完观察，确认没问题再改下一个，这样风险可控。

6.4 团队协作与知识沉淀

最后聊一个容易被忽略但很重要的点：团队协作和知识沉淀。多智能体系统的开发和维护，往往不是一个人能搞定的，需要算法、工程、业务多方配合。配合的过程中，知识沉淀很关键。

我一般会维护三份文档：架构文档（系统有哪些智能体、它们怎么协作、通信协议是什么）、提示词库（每个智能体的提示词、版本历史、修改原因）、问题库（遇到过的问题、排查过程、解决方案）。这三份文档是团队的共同财富，新人来了能快速上手，老人走了知识不会流失。

提示词库尤其重要，因为提示词是多智能体系统里最频繁变动的部分。每次改提示词，都要记录改了什么、为什么改、改完效果如何。这样积累下来，你会形成一套针对自己业务场景的提示词最佳实践，这是花钱都买不来的。

我个人在实际操作中的体会是，多智能体系统的难点从来不在技术本身，而在对业务的理解和对边界的把握。技术方案可以抄，业务理解抄不来。你把业务吃透了，知道哪些环节可以放手让智能体干、哪些环节必须人工兜底，系统就成功了一半。剩下的一半，靠的是持续迭代和耐心打磨，没有捷径。