1. 为什么AI原生应用离不开多代理系统1.1 单个Agent撑不住的真实场景过去一年里我前前后后参与了几个AI原生应用的落地项目最早的做法和大多数团队一样一个大模型实例接上Prompt和工具希望通过一个Agent搞定所有事情。最初的效果确实惊艳但一旦场景复杂起来问题就接二连三地冒出来。举个例子我们当时做的是一个智能客服加销售助手的AI原生应用要求它不仅回答产品问题还要查库存、算价格、写报价单、跟踪订单状态。第一版用单Agent方案的时候所有功能都堆在一个系统提示词里所有工具也一次性全挂上去。结果就是上下文很快就塞满了不相关的工具说明模型经常在查库存和算折扣之间来回横跳偶尔还会把订单状态的查询结果当成报价依据数据错得离谱。还有一个更隐蔽的坑当单个Agent需要同时承担“理解用户意图”“判断需要哪个工具”“生成回复内容”这三件事时它对每一件事的能力都会打折扣。就像一个人又当前台又当会计又当仓库管理员每件事都知道一点但每件事都做不到精细。我们当时还试过通过修改提示词来提高精度加了很多约束条件结果效果反而更差因为上下文越复杂模型决策的稳定性越低。1.2 拆开之后反而更强后来我们换了一种思路把一个大而全的Agent拆成多个专职的小Agent。这个转变对应的正是“多代理系统”的核心思想。也就是说不是让一个Agent处理所有事情而是让多个Agent各管一段由一套机制负责调度它们之间的协作。拆开之后的第一个变化是上下文变干净了。每个Agent只需要加载和自己职责相关的系统提示词和工具不会被无关内容干扰。比如负责查库存的Agent它的提示词只需要聚焦在库存数据上上下文长度大大缩短模型理解的准确度明显提升。负责写报价单的Agent只需要关心报价规则和模板格式输出的质量也更稳定。实测下来同样的任务拆成多代理后准确率能提升百分之二三十耗时反而因为上下文短而有所下降。第二个变化是容易出现故障的位置变得可控了。单Agent方案里任何一个环节出错整个流程就断了。多代理方案里如果负责查库存的Agent出问题调度层可以重试或者走降级逻辑其他Agent照常工作对用户的整体体验影响更小。1.3 什么场景才值得上多代理当然并不是所有项目都需要多代理系统。我不建议你听到这个名词就立刻把现有的单Agent架构推翻重做。根据我的实践经验这几种场景最适合引入多代理系统流程中涉及三种以上不同类型工具而且这些工具之间的调用顺序经常变化。任务需要多轮状态跟踪比如从“理解需求→查询数据→生成文档→审核发送”每一步的输入依赖前一步的输出。需要针对不同角色做定制化输出比如同一个查询结果给销售人员和给管理层看的摘要要点完全不同。单Agent方案的上下文频繁超过模型窗口的一半Prompt里不得不砍功能才能塞下所有内容。如果只是问答、翻译、简单的文本生成用单Agent就够了。强行上多代理反而会因为调度开销让简单任务变慢得不偿失。2. 多代理系统的整体架构与核心角色2.1 调度者所有Agent的大脑多代理系统里最重要的角色不是那些干活的专业Agent而是最上层那个负责分派任务的调度者也就是常说的协调者或编排器。它的职责可以理解为接收用户请求拆解任务决定调哪些Agent、按什么顺序调、如何汇总结果。在设计调度者的时候我有一个特别深的体会调度者几乎不需要调用业务工具它要做的是一个纯粹的“分诊台”。我们把用户请求先交给调度者由它输出一个结构化的任务清单包含所需Agent的标识、输入参数和期望输出。这一步看似简单却决定了整个系统能否稳定运行。如果调度者自己也要查数据、算结果那它很快就会被细节拖住失去大局判断力。在实际实现的时候调度者的决策方式一般有两种。一种是用大模型来做动态规划也就是每次拿到新请求让模型根据请求内容灵活决定下一步调用谁。另一种是预定义工作流把“先查库存再算价格”这种固定路径固化下来。我个人建议用两者的混合主流程走预定义模板遇到模板覆盖不了的情况再由模型动态扩展。这样既能保证核心路径的稳定性又能保留灵活应变的能力。2.2 专业Agent各司其职的执行单元专业Agent是多代理系统的执行层它们各管一个领域、一个工具集或一类输出。和单Agent方案里那个全能的Agent不同专业Agent的目标很纯粹把一件小事做好。在实际落地时我给专业Agent定的设计原则是“小而专”。比如做一个“翻译Agent”它只负责翻译不负责判断译文风格是否符合客户偏好判断风格这件事留给另一个“审校Agent”。如果让翻译Agent同时干这两件事它的系统提示词就会变长决策就会变乱。另一个需要注意的点是专业Agent的输出格式。调度者要调用它的结果去做下一步判断如果它的输出是自由文本调度者解析起来很费劲。我们通常会让每个专业Agent输出JSON结构并且强制规定字段名称和类型。比如查库存Agent的输出至少包含产品ID、可用数量、预计补货日期这三个字段。这样一来下游Agent和调度者都能稳定地拿到结构化数据。2.3 工具层与记忆层的分工多代理系统的底层还有两个容易被忽略的支撑层工具层和记忆层。工具层负责封装真正的外部系统调用比如数据库查询、第三方API、文件读写、消息发送等。关键是要把工具从Agent的决策逻辑中解耦出来。也就是说Agent只负责决定“我要查库存”通过一个统一的函数调用来完成而不用关心库存数据到底存在MySQL还是存在Redis里。工具层做得好Agent之间的调用就稳定。记忆层则负责保存两种信息长期记忆和短期上下文。长期记忆通常存在向量数据库里存的是用户偏好、历史决策、常见问题等。短期上下文则是当前会话里各Agent之间流转的消息集合。我的建议是长期记忆和短期上下文必须分开存储否则时间一长向量数据库的热查询性能会明显下降而且检索时容易把历史信息误当成当前任务输入。2.4 通信协议与任务编排多代理系统里Agent之间的通信方式直接决定了系统的健壮性。我见过不少项目把Agent之间的消息写成随便的字符串结果下游Agent解析字符串时因为格式不统一频繁报错。更稳妥的做法是所有Agent之间统一使用JSON格式的“消息信封”里面至少包含消息ID、发送者、接收者、消息类型、负载数据、时间戳这几个字段。任务编排方面有三种基本模式需要掌握顺序编排、并行编排和条件编排。顺序编排适合“先查库存再报价”这种依赖关系明确的任务并行编排适合可以同时进行的独立子任务比如同时查不同区域的库存数据条件编排则根据某个中间结果决定后面走到哪个分支适合“如果用户是企业会员则调用折扣计算Agent否则直接进入报价流程”这种场景。我们团队的实践结论是至少要把顺序和条件这两种模式在自己的代码里实现并测试通过然后再考虑并行。因为并行编排涉及并发控制、结果合并调试难度比前两者高不少不适合新手一上来就挑战。3. 核心机制与关键配置经验3.1 任务分解的粒度怎么定多代理系统设计得好不好很大程度取决于任务分解的粒度。太大每个Agent又重新变成小全能选手问题依旧太小Agent数量爆炸调度开销和Token消耗都会猛涨。我的判断标准很简单如果一个子任务不需要依赖其他Agent提供的信息而且能够用工具独立完成那它就适合单独拆一个Agent。反过来说如果两个子任务总是成对出现且必须共享中间结果比如“查外部公开数据→翻译成中文”那宁可合成一个Agent内部做两次处理也别拆成两个否则调度层面反而更复杂。另外任务分解时还要考虑实用粒度——不要设计超过七个Agent。我们做过实验五个以上的Agent工作时调度者做任务分派的准确率明显下降因为选项太多模型容易分错。如果你觉得确实需要更多Agent建议给调度者加一个“Agent选择”的辅助工具让它通过检索而不是靠记忆来选Agent虽然复杂一些但稳定很多。3.2 状态机与循环控制参数多代理系统的编排逻辑本质上是一个有限状态机。无论你的实现是用框架还是自己写脑子里都要有一个清晰的状态流转图初始状态、等待调度者决策状态、执行Agent运行中状态、等待工具结果状态、汇总输出状态、失败重试状态。在状态机的实现上我在代码里配置了几个关键参数这些参数是从实际调试里一点一点试出来的直接分享给大家单Agent最大重试次数一般设为2次。超过2次重试还失败大概率不是偶发错误而是Agent配置或数据出了问题再重试就是浪费资源。调度者决策超时时长45秒到60秒比较合理。大模型推理时间有时候会飘给太短容易误判超时给太长用户等待体验差。工具调用最长等待时间根据第三方API的响应时间定网络良好时10到15秒足够内网API还可以压缩到5秒。整条流程的最大步数建议限制在20步以内。如果超过20步还没出结果说明编排逻辑可能进入了一个无意义的循环此时应该终止并返回兜底文案。3.3 记忆管理与上下文窗口分配多代理系统的上下文管理比单Agent复杂得多因为每一轮交互都可能涉及多个Agent的中间输出。如果不加控制上下文会迅速膨胀。我现在用的方法叫“分层摘要压缩”每当调度者准备接收一个新的子Agent的结果时先让结果进入一个压缩通道由一个小号模型把较长内容压缩成要点摘要只保留“与最终目标相关的关键信息”。这个做法可以把上下文减少到原来的三分之一左右而且对决策质量几乎没有负面影响。另外长期记忆写入的时机也很重要。我踩过的一个坑是在每个Agent执行完就立刻把结果写入长期记忆结果导致待查询记忆库里塞满了临时中间状态。经过重构我们只在以下三种情况下写入长期记忆用户明确表达了长期偏好比如“以后报价都用美元”。一次完整的多Agent流程执行完毕结果验证无误。出现错误决策系统需要记住这个错误以便下次避免。除此之外的中间信息都只留在短期上下文里流程结束就清除。3.4 评估与反馈回路多代理系统上线之后最容易被忽视的是评估机制。因为系统由多个Agent组成任何一个Agent的行为偏差都可能被下游放大。所以我把评估分成两层单Agent评估和整体流程评估。单Agent评估针对每个Agent的输出做校验重点看格式是否正确、字段是否完整、是否出现幻觉式信息。整体流程评估则关注最终结果对用户问题的覆盖率、准确率、以及整个流程消耗的Token数和耗时。我建议每周跑一轮回归测试用固定的测试用例集来对比本周和上周的效果差异。一旦某指标下降超过5%立刻查看是哪一层的Agent出了问题。这套评估体系的价值在我们后来的一次模型升级中体现得特别明显——新模型在单Agent层指标全部正常但整体流程的完成率下降了一大截。后来排查发现是新模型在调度者的工具选择环节出现了偏好偏移经常漏选“折扣计算Agent”。如果不是有整体流程评估这个问题可能要过很久才能在用户投诉中暴露出来。4. 实操从零搭建一个可运行的多代理系统4.1 技术选型与工作环境先说到底用什么来实现多代理系统。目前业界已经有开源的多代理编排框架核心能力就是定义Agent、设置工具、编排流程、管理状态。如果你熟悉Python生态直接基于这类框架做二次开发是最快的一条路。我自己更倾向在框架基础上加上自己设计的调度提示词和消息协议而不是完全依赖框架自带的默认逻辑。如果你所在的团队已经有成熟的AI应用服务不想引入太多新依赖也可以自己手写一个轻量调度层。做法不复杂一个总控制器接收请求并调用大模型API完成任务分解然后依次或并行发起对其他Agent的调用每个Agent本质上也是一段独立的函数或微服务。手写方案的控制力更强但需要自己处理重试、超时、状态存储代码量大约多出一千行左右看团队维护能力来决定。我这里先以一个自定义的调度层为例向大家展示最核心的代码结构方便理清执行逻辑。4.2 定义Agent配置与消息协议第一步定义消息协议。我自己定义了一个简单的消息信封结构同时在配置文件中声明每个Agent的基础信息# message.py from dataclasses import dataclass, field from typing import Any import uuid import time dataclass class AgentMessage: msg_id: str field(default_factorylambda: uuid.uuid4().hex) sender: str receiver: str msg_type: str task # task / result / error / status payload: dict[str, Any] field(default_factorydict) context: dict[str, Any] field(default_factorydict) timestamp: float field(default_factorytime.time) def to_dict(self) - dict[str, Any]: return { msg_id: self.msg_id, sender: self.sender, receiver: self.receiver, msg_type: self.msg_type, payload: self.payload, context: self.context, timestamp: self.timestamp }然后写一个简单的Agent配置文件描述每个Agent的职责、可用工具和系统提示词模板。这里的提示词模板有一个设计要点要明确告诉Agent它需要的输入字段和输出字段以及遇到什么情况应该返回错误而不是乱猜。我在实际项目里发现给Agent定义“不知道就明说”的行为约束比让它硬答更能保护下游流程。# agent_config.py AGENT_REGISTRY { intent_agent: { name: 意图识别Agent, description: 分析用户请求提取关键参数输出结构化的任务元信息, tools: [], prompt_template: 你是一个意图识别引擎。只输出JSON包含intent字段和params字段。不要尝试回答问题。, }, stock_agent: { name: 库存查询Agent, description: 查询商品库存返回产品ID、可用数量、预计补货日期, tools: [query_stock_api], prompt_template: 你是库存查询助手。根据给定的产品ID列表查询库存。如果数据不存在status设为error。, }, quote_agent: { name: 报价计算Agent, description: 基于库存和用户等级计算报价返回最终价格和折扣说明, tools: [calc_discount_api], prompt_template: 你是报价助手。根据库存信息和用户等级计算报价。最终输出JSON包含final_price和discount_detail。, }, }4.3 调度层实现编排与状态流转接下来是调度层。调度层要维护当前的状态决定调用哪个Agent接收哪个任务。下面这段代码是我在实际项目中简化后的骨干重点不是每一行的语法而是它的状态流转思路# scheduler.py from message import AgentMessage from agent_config import AGENT_REGISTRY class MultiAgentScheduler: def __init__(self, llm_call_fn): self.llm_call_fn llm_call_fn # 统一的LLM调用入口 self.max_steps 20 self.max_retries 2 def run(self, user_request: str) - dict: current_step 0 state {status: running, final_answer: , context: {}} # 第一步交给调度者做任务分解 plan self._call_planner(user_request) current_step 1 while current_step self.max_steps: if plan.get(next_action) finished: state[status] finished break agent_name plan.get(agent) if agent_name not in AGENT_REGISTRY: state[status] error break # 执行Agent并处理重试 for attempt in range(self.max_retries 1): result self._execute_agent(agent_name, plan.get(payload, {}), state[context]) if result[status] success: state[context].setdefault(intermediate, []).append(result[data]) break else: if attempt self.max_retries: state[status] error return state # 把Agent执行结果交回调度者规划下一步 plan self._call_planner(f用户请求{user_request}\n当前状态{state[context]}) if not plan: state[status] error break current_step 1 if state[status] ! finished: state[status] stopped return state def _call_planner(self, prompt: str) - dict: # 调用大模型解析JSON决策 raw self.llm_call_fn(prompt, system你是一个任务编排器...) return parse_json_safely(raw) def _execute_agent(self, agent_name: str, payload: dict, context: dict) - dict: # 拼装Agent提示词调用LLM解析结构化输出 agent_conf AGENT_REGISTRY[agent_name] prompt build_agent_prompt(agent_conf, payload, context) raw self.llm_call_fn(prompt, systemagent_conf[prompt_template]) return parse_agent_result(raw)这段代码最值得关注的地方是循环内的两步操作先启动Agent执行然后把最终状态回传给调度者来做下一步决策。这种模式保证了整个过程是“每一步都基于最新状况”的动态编排而不是一条固定的静态流水线。4.4 运行效果与调优记录我当初把上面这套结构运行起来后第一次跑通时还有很多细节不尽如人意。最主要的两个问题一是Agent返回的JSON解析失败频率很高二是调度者偶尔会把本应交给库存Agent的任务发给意图识别Agent。针对第一个问题我加了强制JSON输出的提示词模板同时在解析失败时额外调用一次修复模型专门负责把乱七八糟的返回文本整理成合法JSON。针对第二个问题我给每个Agent的注册信息里加了“输入样例”和“不适合处理的请求示例”调度者参考正反例做选择分错的问题明显减少。调整之后我又跑了一个完整的模拟任务“用户询问某商品今天的售价并催促发货”。系统经过调度者、库存Agent、报价Agent、发货状态Agent四轮协作最终输出的结果格式正确、信息完整整体等待时间从单Agent版本的四十五秒下降到三十秒左右。重要的是这套系统后续加新业务线时只需要新增Agent和对应工具主流程代码一行没改。5. 常见问题与排查技巧实录5.1 Agent陷入死循环多代理系统最常见的问题就是流程卡在循环里出不来。具体表现为调度者反复把任务交给同一个Agent或者两个Agent来回传递相同的信息日志里同一段上下文出现很多次。我排查这类问题的第一招是查看状态流转日志。给每个Agent调用都打上带消息ID的日志沿着ID追踪能很快发现是哪一步开始重复的。如果确认是调度者决策问题优先在调度提示词里加一个限定“只有当前请求需要新的信息时才调用下一个Agent如果已有信息足以作答直接进入输出阶段”。如果循环发生在固定路径上比如A做完给BB做完又触发A那就直接在代码层加去重记录最近N条消息的消息ID如果新消息与最近某条完全一致就阻断执行。5.2 上下文超限与Token浪费上下文窗口超限在多代理系统里几乎是必然遇到的。每个Agent执行结果都拼进上下文几轮下来就超了。我建议用前面说过的分层摘要压缩把中间结果全部做压缩摘要。维护一份“当前最新状态摘要”而不是保留所有原始输出。另外可以给每个工具调用的返回结果加一个截断参数。比如库存查询接口本来返回几百条记录我们规定只返回前50条加一个总数标记。这样既满足Agent做决策的信息需求又不会把上下文撑爆。这个处理让小模型Agent的推理成本下降了大概一半输出速度却快了不少。5.3 Agent间的信息传递丢失不少新手实现多代理时发现下游Agent拿到上游的输出后经常答非所问。原因多半是消息信封里的payload字段设计得不好或者下游Agent的提示词没有说明应该从哪拿关键字段。解决办法是给每个Agent的输入做显式映射在提示词模板里明确写出“你将收到一个JSON对象请使用其中的product_id和sales_channel字段作为输入忽略其他字段”。实测下来加上这句话之后信息传递错误率能降低到原来的四分之一以下。5.4 成本失控多Agent系统的Token消耗有时是单Agent方案的三到五倍因为增加了调度者的多轮调用。我的成本控制经验是调度者使用参数规模较小的模型只做决策不做事。Agent执行阶段用任务复杂度匹配模型大小简单的分类任务用中等模型就够不需要每次都上旗舰模型。开启缓存机制同一用户在同一会话内的重复请求结果直接复用。对流程最大步数做严格限制从源头上防止无意义调用。我们上线优化以后单次会话的平均成本降到了原来的40%左右而任务完成率没有下降效果很明显。6. 一个容易被忽略的工程化要点多代理系统上线容易维护难。多数团队把目光放在Agent的数量和工具数量上却忽略了可观测性设计。我在实际维护中的体会是一个没有日志追踪和指标看板的多代理系统排查问题时就像蒙着眼睛找一颗掉进沙漠里的钉子寸步难行。所以建议在第一天就搭建一套日志链路整个流程有一个全局流程ID每个Agent调用、每次工具调用、每次LLM响应都挂在这个ID下。看到线上用户反馈异常先按流程ID把整条链路捞出来问题在哪个环节基本一目了然。这套机制救过我很多次没有它哪怕是三五个Agent的小系统排查一次问题也能耗费一整天。工具监控也不能缺。不同Agent共用同一个第三方API时如果API出现抖动单看Agent日志很容易误判为Agent本身的问题。我现在的做法是对每个工具都单独记录调用耗时和错误码单独画一张耗时趋势图。如果某一段时间工具调用耗时长且错误多那就是基础设施问题先修接口再调Agent排查顺序对了效率才会高。多代理系统的价值不在于概念有多新而在于怎样把复杂度收拢到可控的范围内。个人经验是先从两三个专职Agent起步把消息协议、状态流转、日志追踪跑顺再逐步增加Agent数量和编排模式。等到框架稳定了你手上这多代理架构就会成为真正能落地的应用新引擎而不再是试错模型。