做了一阵子 Agent 应用的开发者大概率都遇到过类似的场面一个单体 Agent 接了个“写方案 配图 发布 复盘数据”的连环任务前三步还算正常第四步开始把第二轮的结论当背景资料第五步直接开始编数据你翻看它的日志发现它已经忘了一开始的目标。这种翻车不是偶然而是单体 Agent 这条技术路线自带的极限。今天这篇不聊概念就聊我实际跑项目时的观察单体 Agent 为什么撑不住复杂任务Multi-Agent 究竟在解决哪些真实问题以及从单体往多体迁移时有哪些坑是文档里不会写的。1. 从一次任务翻车聊起单体 Agent 到底卡在哪先还原一个具体场景。我之前做过一个内部数据周报 Agent初始设计很简单一个 LLM 核心配上 SQL 查询工具、Excel 写入工具、邮件发送工具再给它一段很长的 system prompt要求它“先获取数据再生成图表最后写文字结论”。单步问答没有问题真正执行一个完整流程时它表现得像一个越做越疲惫的实习生——每一步之间信息在丢失动作在变形。1.1 单体 Agent 的典型构造单体 Agent 通常不是指“一个程序”而是指一个独立的智能循环一个 LLM 作为推理大脑外面包上记忆模块和工具集再加上一个执行循环。最常用的就是 ReAct 模式推理Reasoning→ 行动Action→ 观察Observation不断循环直到完成目标。这个架构的优势很明显简单、直观、好调试。你在一个会话里和同一个“大脑”对话它能调用多个工具能记住前面的思考过程。很多 MVP 项目都是这么跑通的我当时也这么干过。但它有一个隐藏前提这个循环里的所有状态都挤在一个上下文空间里。思考记录、工具返回结果、用户的原始需求、中间产物全部堆在一起。任务一复杂这里就成了事故高发区。1.2 一次真实翻车全过程我当时给周报 Agent 的指令是从数据库拉出本周销售明细按渠道汇总生成对比上周的图表文件最后写一段分析结论发给团队群。前两步很顺利。但到了第三步它需要先看一眼第二步生成的图表结构再决定结论里怎么描述变化趋势。问题就出在这里它把图表文件里的原始CSV内容当成了“已经分析好的结论”把第一轮的数据筛选条件忘得一干二净最后生成的分析有一半逻辑是错的。这不是模型能力差而是单体架构下的典型症状当上下文长度超过一定阈值Agent 对早期信息的注意力会严重衰减。它并不是没有“记住”那些内容而是那些内容在后续决策中的权重被大量新信息稀释了。简单说它看起来还记得实际上已经不太会用了。2. 五个躲不开的天花板上下文、记忆、工具、状态与单点故障单体 Agent 的问题不是一个单独的技术缺陷而是一组互相叠加的架构上限。我把常见的天花板归纳成五个这五个基本决定了“物理上做不了复杂任务”的原因。2.1 上下文窗口物理上限就是认知上限大模型的上下文窗口再长也不是一个可以无限堆资料的仓库。当任务步骤变多中间产物体积变大你会发现两个问题一是长上下文里的信息检索能力下降。模型面对 30 万 token 的上下文时很难精准找到最关键的那段信息。就像让一个人从一整本流水账里抓出上个月第三周的第二条备注不是不记得是不確定哪个才是关键。二是不同来源的信息互相污染。用户指令、工具返回、推理记录挤在一起模型很容易在后续步骤里把“假设”当成“事实”把“待验证的结果”当成“最终结论”。这个天花板直接决定了单体 Agent 的复杂任务规模上限基本信息量越大犯错的概率越大。2.2 长程规划与记忆衰减复杂任务通常包含长程规划比如“先收集三个月数据再做趋势判断最后给出行动建议”。单体 Agent 在执行这类任务时常常出现规划链断裂。原因是它的记忆不是真正的长期记忆而是每轮对话里的瞬时上下文。如果任务超过 10 个步骤Agent 很容易忘记自己在第 1 步定下的方法论然后第 8 步开始自由发挥。回调到前面的周报案例它的失败序列是“自定义的分析框架被覆盖→退回到通用分析→结论失去针对性”。这个链条在任何单体 Agent 里都有可能发生只是时间早晚的问题。2.3 工具多而杂状态无人统一管理单体 Agent 挂了很多工具时还会出现工具之间的状态冲突。比如一个工具修改了数据库里的记录另一个工具读取的时候还是旧缓存又比如一个工具生成了文件下一个工具不知道文件的路径或格式只能靠猜。状态管理在传统软件里是很基础的问题到了 Agent 这里反而被忽略了。因为 Agent 不是严格的程序它更像一个“概率化的调用者”你不容易保证它每次都按顺序、按约定去读写状态。工具越多这个不确定性就越明显。2.4 单点故障与并行瓶颈单体 Agent 一次只能在一个“大脑”里串行思考。任务再怎么分解它都得一步一步来而且一旦某一步失败整个任务失败。没有回退、没有隔离、没有并行。放到工程视角就很好理解了一个模块崩了整台机器宕机这叫单点故障一个进程只能顺序执行任务这叫并行瓶颈。单体 Agent 把这些问题原封不动地从软件架构带进了 AI 应用架构而复杂任务恰恰要求系统具备协同、容错和并行能力。2.5 调试与评测的“黑盒”成本最后这个天花板很多人没意识到单体 Agent 复杂到一定程度调试成本会非线性上升。因为推理过程是黑盒你看得到它在说“我在回顾之前的分析”但你不知道它实际是在拿哪一段上下文做依据。改一句话 prompt可能提升了一个子任务的表现却破坏了另一个子任务。为了应对这个问题我后来引入了两个工具一是给每轮循环加 trace ID二是把关键决策点输出结构化日志。但单体架构只能缓解不能根治——所有状态都在一个盒子里你想定位到底是哪一步错了就得把整个上下文回放一遍非常耗时。3. Multi-Agent 的底层逻辑把“一个人全能”换成“一支队伍协作”聊完单体 Agent 的天花板我们再来看看 Multi-Agent 是怎么回应这些问题的。它并不是简单地把多个 LLM 拼在一起而是换了一套架构思想。3.1 核心不是“多个LLM”而是上下文隔离Multi-Agent 最有价值的点是上下文隔离。每个 Agent 有自己的上下文窗口、自己的工具权限、自己的目标设定。它们之间通过消息传递信息而不是共享一个巨大的上下文。这就好比一个是让一个全科医生处理所有科室的问题另一个是让每个专科医生只看自己的领域检查报告通过内部系统传递。全科医生容易信息过载专科医生各司其职出错时还能定位到具体科室。上下文隔离最直接的效果是数据分析 Agent 不会被文案 Agent 的长篇大论干扰文案 Agent 也不必加载数据库里的原始数据。每个 Agent 的上下文都更短、更纯、更专注模型的表现自然更稳。3.2 专业化分工解决“什么都懂一点点”的困境单体 Agent 里一个大脑要同时做数据分析、图表生成、文案撰写、消息推送。这意味着它要在一次上下文切换中完成多种能力组合很容易出现“什么都懂一点点但都不深入”的情况。Multi-Agent 可以把目标细化一个数据查询 Agent专注写 SQL一个图表生成 Agent专注处理可视化一个文案 Agent专注写结论一个发布 Agent专注执行发送。每个 Agent 的 system prompt 可以写得很短很准工具只挂自己领域的那几个输入输出格式固定。这种专业化分工不只是提升了每一步的准确率还让每个 Agent 可以被单独优化、单独测试、单独替换。我实测下来单步骤准确率提升不一定非常夸张但整个流程的端到端成功率提升非常明显。原因就是错误不再逐层累积而是被分段隔离了。3.3 编排器不是领导而是路由器Multi-Agent 里通常有个核心角色叫 Orchestrator。很多人把它理解成“管理所有 Agent 的领导”这个类比不完全准确。更准确的说法是路由器或接线员它负责接收用户需求拆解任务分发给对应 Agent再把结果拼装成最终答案。真正复杂的业务逻辑应该在各个专业 Agent 里而不是全部塞给编排器。编排器只做三件事任务分解、路由分发、结果聚合。比如一个周报任务编排器先判断需要查询Agent拿数据然后决定是否需要图表Agent处理展示最后让文案Agent写总结。这个设计的价值在于编排器的上下文只保存任务状态和最新结果不需要承载所有中间过程。它本身也是一个 Agent但它的工作性质是“沟通”而不是“执行”。这个区分非常重要。4. 什么样的复杂任务必须拆任务规模与耦合度Multi-Agent 不是银弹。有些复杂任务拆了反而更慢、更贵、更容易出错。那到底怎么判断我一般用两个维度任务规模和耦合度。4.1 先画一张任务依赖图在动手拆 Agent 之前我会先把这个任务抽象成一张依赖图。不用画得多专业你只需要整理出每一步的输入和输出这一步需要上一步的什么结果这一步的结果会被哪些后续步骤共用哪些步骤其实互不依赖画完之后判断标准就出来了如果两个步骤之间没有强依赖且它们的输入输出量很大适合拆分。如果两个步骤间有强依赖且后续步骤需要前面所有中间状态那拆分的收益就很低。拿调研报告类任务举例数据采集、数据分析、结论撰写这三步是顺序依赖不适合拆成三个完全隔离的 Agent。但数据采集里可以拆一个“爬虫 Agent”因为它的输出是固定的文件路径后续步骤只需要文件路径不需要爬虫的中间推理过程。这种拆分就叫“在接口处切一刀”。4.2 不建议拆的场景不是所有复杂任务都值得 Multi-Agent。我自己踩过一些坑归纳了几个不适合拆的场景第一全局语境高度一致的任务。比如写一篇长篇小说前后风格、人物设定、伏笔都需要全局记忆。拆成多个 Agent 很容易出现风格漂移、设定互相矛盾。这种任务本质上需要的一个深度长上下文而不是多角色协作。第二步骤多但每个步骤之间耦合紧密的任务。比如代码重构改一行可能影响后面所有的逻辑拆成多个 Agent 各自维护一段最后合并时会产生大量冲突。第三单体 Agent 已经跑得很好单纯为了“架构潮”拆。复杂度不是越高越好单体能解决就先用单体。4.3 实用混合架构一个主 Agent 几个专家 Agent我目前的主力架构很朴素一个主 Agent 做整体规划和最终输出几个专家 Agent 做具体执行。主 Agent 不直接处理原始数据而是把任务拆解成“我需要一个数据文件”这样的小需求发给数据 Agent拿到结果后自己再做下一步判断。这种混合架构的好处是保留了单体 Agent 的连贯性又吸收了 Multi-Agent 的上下文隔离优势。它适用于大多数“有一个主要负责人 多个外包专家”型场景也是我建议大家从单体迁移到多体的第一站。5. Multi-Agent 落地时最容易被低估的三个问题Multi-Agent 架构能解决单体的问题但也会带来新的麻烦。在实际落地里我被三个问题反复折磨了很久每个都值得提前规避。5.1 成本像坐火箭Token 消耗翻好几倍Multi-Agent 第一个让老板皱眉的问题就是成本。多 Agent 之间的信息传递、结果解析、异常重试每一个环节都在额外消耗 Token。单体跑一个 10 步任务可能只要 2 万 token多体化之后直接飙到 6 万以上是我见过最小三倍的涨幅。我后来做了几个调整一是在 Agent 之间传递的消息尽量压缩成摘要而不是整段原文二是约定“结果即交付物”每个 Agent 只返回最终结果的关键字段不返回中间推理过程三是能用一个工具调用解决的任务不要拆成两个 Agent。这些调整能把成本控制在单体的 1.5 到 2 倍左右换来的是稳定性的提升从经济账上算是值得的。5.2 消息设计是重灾区Multi-Agent 里的 Agent 之间通信很多人一开始直接用自然语言对话觉得“反正模型都懂”。这个思路前期很爽后期会非常痛苦。因为自然语言对话太自由两轮之后你就不知道 A Agent 到底在给 B Agent 传递“事实”还是“猜测”。这就像两个程序员在代码里用注释交流而不是用接口签名时间一长必然崩。正确做法是给每个 Agent 定义输入输出的结构化格式类似微服务里的 API schema。比如数据查询 Agent 的输出固定为 JSON 格式字段包含 status、data_path、error_code。文案 Agent 的输出固定为 title body tone。这样每个 Agent 的上下文中都只有清晰、确定的信息大幅降低幻觉传递。发布的时候要加上约束指令如果生成的结果不符合 schema必须重试一次重试仍失败则返回错误码而不是硬生成。5.3 死循环、踢皮球和“假装完成”多 Agent 系统里最崩溃的调试场景就是死循环。Agent A 给 Agent B 发了一个请求B 处理不了返回了一个错误结果A 觉得是“结果不够好”修改后又发给 BB 依然处理不了……两个 Agent 就这么互相踢皮球跑到超时。我之前没有限流时系统经常打印几万个 token 的无意义循环。后来给每个 Agent 加了三个硬性配置最大重试次数、单次任务超时时间、无法处理时的固定兜底答复。设置“无法理解请求时必须返回 help_required 并附带原因”而不是继续尝试修正。调试时一定要记得在每个消息里带上链路 ID。Multi-Agent 的失败问题排查难度比单体高一个数量级没有链路追踪你根本不知道任务是停在了 A 的输出还是 B 的解析上。6. 从单体到多体我总结的几条转型建议最后聊点实际怎么迁移的经验。我从单体转到多体的过程不是一次性重写而是渐进式调整这里分享一条我发现很实用的改造路径。6.1 先用单体跑通再拆寿星改造的第一件事不是搭 Multi-Agent 框架而是先用单体把整个流程跑通。记录每个步骤的准确率、耗时、Token 消耗、失败类型。然后把这些数据按步骤列一张表找出最拖后腿、最难调的那个环节。拆分的优先级不是看“这个环节是不是够复杂”而是看“这个环节是不是因为上下文污染导致表现崩坏”。如果某个步骤的问题来自上下文太长、前期信息干扰那它就是一个天然的拆分点。我第一个拆出去的基本都是“数据获取”这种上下文独立、输入输出边界清晰的环节。6.2 每个 Agent 设置明确的退出条件这个经验是我踩了很多坑之后总结出来的。一个 Agent 没有退出条件就等于一个没有下班时间的员工它会一直尝试一直输出直到 Token 耗尽。我给每个 Agent 定义了四个退出条件成功返回结构化结果达到最大重试次数任务超时无法满足需求时返回固定错误码。每个 Agent 的出口都要明确入口也要明确。入参不确定时允许拒绝接收并说明需要什么格式。这在单体 Agent 里不太重要因为只有一个大脑错了可以说“抱歉我重新来”。多体下必须强制否则整个系统会被一个 Agent 的不确定输出拖垮。6.3 观测是第一生产力最后一定要在初期就搭好观测层。多 Agent 不比单体你无法靠“对话回顾”来复盘错误。我现在的标准化做法是每个 Agent 的执行都写结构化日志每条 Agent 间消息都记录 broker tag每个任务都有 trace_id 串联。观测系统建好之后很多 Multi-Agent 的隐藏问题才会浮出水面。比如你可能会发现某个 Agent 的调用频率比预期高十倍或者某个 Agent 经常被重试这些都是架构问题的信号。没有数据之前Multi-Agent 调优基本只能靠猜有了数据才能谈优化。我个人这几年切换过来的最深感受是Multi-Agent 不是更高级的 Agent而是更合理的工作流拆分。它把“一个什么都会但不够稳定的个体”重新设计成了“一个职责清晰、边界明确、可观测协作的团队”。复杂任务走到这里不是必然选择是单体 Agent 自己撑不住了。如果你现在手上正有一个反复翻车的单体 Agent不妨把它最弱的那一环拆出来先跑通一个最小规模的多体协作再决定要不要全面铺开。
单体Agent撑不住复杂任务？Multi-Agent架构的落地实践与避坑指南
做了一阵子 Agent 应用的开发者大概率都遇到过类似的场面一个单体 Agent 接了个“写方案 配图 发布 复盘数据”的连环任务前三步还算正常第四步开始把第二轮的结论当背景资料第五步直接开始编数据你翻看它的日志发现它已经忘了一开始的目标。这种翻车不是偶然而是单体 Agent 这条技术路线自带的极限。今天这篇不聊概念就聊我实际跑项目时的观察单体 Agent 为什么撑不住复杂任务Multi-Agent 究竟在解决哪些真实问题以及从单体往多体迁移时有哪些坑是文档里不会写的。1. 从一次任务翻车聊起单体 Agent 到底卡在哪先还原一个具体场景。我之前做过一个内部数据周报 Agent初始设计很简单一个 LLM 核心配上 SQL 查询工具、Excel 写入工具、邮件发送工具再给它一段很长的 system prompt要求它“先获取数据再生成图表最后写文字结论”。单步问答没有问题真正执行一个完整流程时它表现得像一个越做越疲惫的实习生——每一步之间信息在丢失动作在变形。1.1 单体 Agent 的典型构造单体 Agent 通常不是指“一个程序”而是指一个独立的智能循环一个 LLM 作为推理大脑外面包上记忆模块和工具集再加上一个执行循环。最常用的就是 ReAct 模式推理Reasoning→ 行动Action→ 观察Observation不断循环直到完成目标。这个架构的优势很明显简单、直观、好调试。你在一个会话里和同一个“大脑”对话它能调用多个工具能记住前面的思考过程。很多 MVP 项目都是这么跑通的我当时也这么干过。但它有一个隐藏前提这个循环里的所有状态都挤在一个上下文空间里。思考记录、工具返回结果、用户的原始需求、中间产物全部堆在一起。任务一复杂这里就成了事故高发区。1.2 一次真实翻车全过程我当时给周报 Agent 的指令是从数据库拉出本周销售明细按渠道汇总生成对比上周的图表文件最后写一段分析结论发给团队群。前两步很顺利。但到了第三步它需要先看一眼第二步生成的图表结构再决定结论里怎么描述变化趋势。问题就出在这里它把图表文件里的原始CSV内容当成了“已经分析好的结论”把第一轮的数据筛选条件忘得一干二净最后生成的分析有一半逻辑是错的。这不是模型能力差而是单体架构下的典型症状当上下文长度超过一定阈值Agent 对早期信息的注意力会严重衰减。它并不是没有“记住”那些内容而是那些内容在后续决策中的权重被大量新信息稀释了。简单说它看起来还记得实际上已经不太会用了。2. 五个躲不开的天花板上下文、记忆、工具、状态与单点故障单体 Agent 的问题不是一个单独的技术缺陷而是一组互相叠加的架构上限。我把常见的天花板归纳成五个这五个基本决定了“物理上做不了复杂任务”的原因。2.1 上下文窗口物理上限就是认知上限大模型的上下文窗口再长也不是一个可以无限堆资料的仓库。当任务步骤变多中间产物体积变大你会发现两个问题一是长上下文里的信息检索能力下降。模型面对 30 万 token 的上下文时很难精准找到最关键的那段信息。就像让一个人从一整本流水账里抓出上个月第三周的第二条备注不是不记得是不確定哪个才是关键。二是不同来源的信息互相污染。用户指令、工具返回、推理记录挤在一起模型很容易在后续步骤里把“假设”当成“事实”把“待验证的结果”当成“最终结论”。这个天花板直接决定了单体 Agent 的复杂任务规模上限基本信息量越大犯错的概率越大。2.2 长程规划与记忆衰减复杂任务通常包含长程规划比如“先收集三个月数据再做趋势判断最后给出行动建议”。单体 Agent 在执行这类任务时常常出现规划链断裂。原因是它的记忆不是真正的长期记忆而是每轮对话里的瞬时上下文。如果任务超过 10 个步骤Agent 很容易忘记自己在第 1 步定下的方法论然后第 8 步开始自由发挥。回调到前面的周报案例它的失败序列是“自定义的分析框架被覆盖→退回到通用分析→结论失去针对性”。这个链条在任何单体 Agent 里都有可能发生只是时间早晚的问题。2.3 工具多而杂状态无人统一管理单体 Agent 挂了很多工具时还会出现工具之间的状态冲突。比如一个工具修改了数据库里的记录另一个工具读取的时候还是旧缓存又比如一个工具生成了文件下一个工具不知道文件的路径或格式只能靠猜。状态管理在传统软件里是很基础的问题到了 Agent 这里反而被忽略了。因为 Agent 不是严格的程序它更像一个“概率化的调用者”你不容易保证它每次都按顺序、按约定去读写状态。工具越多这个不确定性就越明显。2.4 单点故障与并行瓶颈单体 Agent 一次只能在一个“大脑”里串行思考。任务再怎么分解它都得一步一步来而且一旦某一步失败整个任务失败。没有回退、没有隔离、没有并行。放到工程视角就很好理解了一个模块崩了整台机器宕机这叫单点故障一个进程只能顺序执行任务这叫并行瓶颈。单体 Agent 把这些问题原封不动地从软件架构带进了 AI 应用架构而复杂任务恰恰要求系统具备协同、容错和并行能力。2.5 调试与评测的“黑盒”成本最后这个天花板很多人没意识到单体 Agent 复杂到一定程度调试成本会非线性上升。因为推理过程是黑盒你看得到它在说“我在回顾之前的分析”但你不知道它实际是在拿哪一段上下文做依据。改一句话 prompt可能提升了一个子任务的表现却破坏了另一个子任务。为了应对这个问题我后来引入了两个工具一是给每轮循环加 trace ID二是把关键决策点输出结构化日志。但单体架构只能缓解不能根治——所有状态都在一个盒子里你想定位到底是哪一步错了就得把整个上下文回放一遍非常耗时。3. Multi-Agent 的底层逻辑把“一个人全能”换成“一支队伍协作”聊完单体 Agent 的天花板我们再来看看 Multi-Agent 是怎么回应这些问题的。它并不是简单地把多个 LLM 拼在一起而是换了一套架构思想。3.1 核心不是“多个LLM”而是上下文隔离Multi-Agent 最有价值的点是上下文隔离。每个 Agent 有自己的上下文窗口、自己的工具权限、自己的目标设定。它们之间通过消息传递信息而不是共享一个巨大的上下文。这就好比一个是让一个全科医生处理所有科室的问题另一个是让每个专科医生只看自己的领域检查报告通过内部系统传递。全科医生容易信息过载专科医生各司其职出错时还能定位到具体科室。上下文隔离最直接的效果是数据分析 Agent 不会被文案 Agent 的长篇大论干扰文案 Agent 也不必加载数据库里的原始数据。每个 Agent 的上下文都更短、更纯、更专注模型的表现自然更稳。3.2 专业化分工解决“什么都懂一点点”的困境单体 Agent 里一个大脑要同时做数据分析、图表生成、文案撰写、消息推送。这意味着它要在一次上下文切换中完成多种能力组合很容易出现“什么都懂一点点但都不深入”的情况。Multi-Agent 可以把目标细化一个数据查询 Agent专注写 SQL一个图表生成 Agent专注处理可视化一个文案 Agent专注写结论一个发布 Agent专注执行发送。每个 Agent 的 system prompt 可以写得很短很准工具只挂自己领域的那几个输入输出格式固定。这种专业化分工不只是提升了每一步的准确率还让每个 Agent 可以被单独优化、单独测试、单独替换。我实测下来单步骤准确率提升不一定非常夸张但整个流程的端到端成功率提升非常明显。原因就是错误不再逐层累积而是被分段隔离了。3.3 编排器不是领导而是路由器Multi-Agent 里通常有个核心角色叫 Orchestrator。很多人把它理解成“管理所有 Agent 的领导”这个类比不完全准确。更准确的说法是路由器或接线员它负责接收用户需求拆解任务分发给对应 Agent再把结果拼装成最终答案。真正复杂的业务逻辑应该在各个专业 Agent 里而不是全部塞给编排器。编排器只做三件事任务分解、路由分发、结果聚合。比如一个周报任务编排器先判断需要查询Agent拿数据然后决定是否需要图表Agent处理展示最后让文案Agent写总结。这个设计的价值在于编排器的上下文只保存任务状态和最新结果不需要承载所有中间过程。它本身也是一个 Agent但它的工作性质是“沟通”而不是“执行”。这个区分非常重要。4. 什么样的复杂任务必须拆任务规模与耦合度Multi-Agent 不是银弹。有些复杂任务拆了反而更慢、更贵、更容易出错。那到底怎么判断我一般用两个维度任务规模和耦合度。4.1 先画一张任务依赖图在动手拆 Agent 之前我会先把这个任务抽象成一张依赖图。不用画得多专业你只需要整理出每一步的输入和输出这一步需要上一步的什么结果这一步的结果会被哪些后续步骤共用哪些步骤其实互不依赖画完之后判断标准就出来了如果两个步骤之间没有强依赖且它们的输入输出量很大适合拆分。如果两个步骤间有强依赖且后续步骤需要前面所有中间状态那拆分的收益就很低。拿调研报告类任务举例数据采集、数据分析、结论撰写这三步是顺序依赖不适合拆成三个完全隔离的 Agent。但数据采集里可以拆一个“爬虫 Agent”因为它的输出是固定的文件路径后续步骤只需要文件路径不需要爬虫的中间推理过程。这种拆分就叫“在接口处切一刀”。4.2 不建议拆的场景不是所有复杂任务都值得 Multi-Agent。我自己踩过一些坑归纳了几个不适合拆的场景第一全局语境高度一致的任务。比如写一篇长篇小说前后风格、人物设定、伏笔都需要全局记忆。拆成多个 Agent 很容易出现风格漂移、设定互相矛盾。这种任务本质上需要的一个深度长上下文而不是多角色协作。第二步骤多但每个步骤之间耦合紧密的任务。比如代码重构改一行可能影响后面所有的逻辑拆成多个 Agent 各自维护一段最后合并时会产生大量冲突。第三单体 Agent 已经跑得很好单纯为了“架构潮”拆。复杂度不是越高越好单体能解决就先用单体。4.3 实用混合架构一个主 Agent 几个专家 Agent我目前的主力架构很朴素一个主 Agent 做整体规划和最终输出几个专家 Agent 做具体执行。主 Agent 不直接处理原始数据而是把任务拆解成“我需要一个数据文件”这样的小需求发给数据 Agent拿到结果后自己再做下一步判断。这种混合架构的好处是保留了单体 Agent 的连贯性又吸收了 Multi-Agent 的上下文隔离优势。它适用于大多数“有一个主要负责人 多个外包专家”型场景也是我建议大家从单体迁移到多体的第一站。5. Multi-Agent 落地时最容易被低估的三个问题Multi-Agent 架构能解决单体的问题但也会带来新的麻烦。在实际落地里我被三个问题反复折磨了很久每个都值得提前规避。5.1 成本像坐火箭Token 消耗翻好几倍Multi-Agent 第一个让老板皱眉的问题就是成本。多 Agent 之间的信息传递、结果解析、异常重试每一个环节都在额外消耗 Token。单体跑一个 10 步任务可能只要 2 万 token多体化之后直接飙到 6 万以上是我见过最小三倍的涨幅。我后来做了几个调整一是在 Agent 之间传递的消息尽量压缩成摘要而不是整段原文二是约定“结果即交付物”每个 Agent 只返回最终结果的关键字段不返回中间推理过程三是能用一个工具调用解决的任务不要拆成两个 Agent。这些调整能把成本控制在单体的 1.5 到 2 倍左右换来的是稳定性的提升从经济账上算是值得的。5.2 消息设计是重灾区Multi-Agent 里的 Agent 之间通信很多人一开始直接用自然语言对话觉得“反正模型都懂”。这个思路前期很爽后期会非常痛苦。因为自然语言对话太自由两轮之后你就不知道 A Agent 到底在给 B Agent 传递“事实”还是“猜测”。这就像两个程序员在代码里用注释交流而不是用接口签名时间一长必然崩。正确做法是给每个 Agent 定义输入输出的结构化格式类似微服务里的 API schema。比如数据查询 Agent 的输出固定为 JSON 格式字段包含 status、data_path、error_code。文案 Agent 的输出固定为 title body tone。这样每个 Agent 的上下文中都只有清晰、确定的信息大幅降低幻觉传递。发布的时候要加上约束指令如果生成的结果不符合 schema必须重试一次重试仍失败则返回错误码而不是硬生成。5.3 死循环、踢皮球和“假装完成”多 Agent 系统里最崩溃的调试场景就是死循环。Agent A 给 Agent B 发了一个请求B 处理不了返回了一个错误结果A 觉得是“结果不够好”修改后又发给 BB 依然处理不了……两个 Agent 就这么互相踢皮球跑到超时。我之前没有限流时系统经常打印几万个 token 的无意义循环。后来给每个 Agent 加了三个硬性配置最大重试次数、单次任务超时时间、无法处理时的固定兜底答复。设置“无法理解请求时必须返回 help_required 并附带原因”而不是继续尝试修正。调试时一定要记得在每个消息里带上链路 ID。Multi-Agent 的失败问题排查难度比单体高一个数量级没有链路追踪你根本不知道任务是停在了 A 的输出还是 B 的解析上。6. 从单体到多体我总结的几条转型建议最后聊点实际怎么迁移的经验。我从单体转到多体的过程不是一次性重写而是渐进式调整这里分享一条我发现很实用的改造路径。6.1 先用单体跑通再拆寿星改造的第一件事不是搭 Multi-Agent 框架而是先用单体把整个流程跑通。记录每个步骤的准确率、耗时、Token 消耗、失败类型。然后把这些数据按步骤列一张表找出最拖后腿、最难调的那个环节。拆分的优先级不是看“这个环节是不是够复杂”而是看“这个环节是不是因为上下文污染导致表现崩坏”。如果某个步骤的问题来自上下文太长、前期信息干扰那它就是一个天然的拆分点。我第一个拆出去的基本都是“数据获取”这种上下文独立、输入输出边界清晰的环节。6.2 每个 Agent 设置明确的退出条件这个经验是我踩了很多坑之后总结出来的。一个 Agent 没有退出条件就等于一个没有下班时间的员工它会一直尝试一直输出直到 Token 耗尽。我给每个 Agent 定义了四个退出条件成功返回结构化结果达到最大重试次数任务超时无法满足需求时返回固定错误码。每个 Agent 的出口都要明确入口也要明确。入参不确定时允许拒绝接收并说明需要什么格式。这在单体 Agent 里不太重要因为只有一个大脑错了可以说“抱歉我重新来”。多体下必须强制否则整个系统会被一个 Agent 的不确定输出拖垮。6.3 观测是第一生产力最后一定要在初期就搭好观测层。多 Agent 不比单体你无法靠“对话回顾”来复盘错误。我现在的标准化做法是每个 Agent 的执行都写结构化日志每条 Agent 间消息都记录 broker tag每个任务都有 trace_id 串联。观测系统建好之后很多 Multi-Agent 的隐藏问题才会浮出水面。比如你可能会发现某个 Agent 的调用频率比预期高十倍或者某个 Agent 经常被重试这些都是架构问题的信号。没有数据之前Multi-Agent 调优基本只能靠猜有了数据才能谈优化。我个人这几年切换过来的最深感受是Multi-Agent 不是更高级的 Agent而是更合理的工作流拆分。它把“一个什么都会但不够稳定的个体”重新设计成了“一个职责清晰、边界明确、可观测协作的团队”。复杂任务走到这里不是必然选择是单体 Agent 自己撑不住了。如果你现在手上正有一个反复翻车的单体 Agent不妨把它最弱的那一环拆出来先跑通一个最小规模的多体协作再决定要不要全面铺开。
