做AI智能体有一段时间的人应该都有过这种体验同样是基于LLM做出来的东西有的又准又稳就像一把趁手的扳手说拧哪颗螺丝就拧哪颗有的则是上来就问你“您需要什么帮助”然后一通操作猛如虎最后还答非所问。问题在哪很多时候不在模型能力而在于你没有把“任务边界”这件事想清楚。今天这篇我想围绕LLM智能体的两种典型形态——单任务代理与多任务代理把它们的结构差异、适用场景和取舍逻辑摊开聊一聊。如果你正在设计自己的第一个AI智能体或者已经做了一个但又觉得哪里不对劲这篇文章应该能帮你找到一个明确的判断框架。我先把结论放在前面单任务代理和多任务代理的区别不仅仅是你给系统指派了“一件事”还是“很多件事”而是整个系统在决策权归属、任务编排方式、状态管理逻辑这三个层面都发生了根本变化。理解不了这层你可能会做出一个看起来很强大、用起来却很崩溃的“伪多任务”系统。1. 从“单个LLM”到“单任务代理”一个专注型执行器是如何构建的在很多人的理解里给一个LLM写一段提示词让它专门做某件事这就叫单任务代理。其实这个理解不算错但只说对了一半。真正的单任务代理要求的是单一目标贯穿整个运行生命周期从接收输入到调用外部工具再到生成最终输出中间不做任何横向发散。1.1 单任务代理的核心运行逻辑一个标准的单任务代理内部通常只有一条固定链路接收用户请求 → 解析请求中的结构化字段 → 判断是否调用工具 → 拿到工具结果 → 生成最终回答。链路很短而且每一步的触发条件都非常明确。举个例子。我做过一个专门处理“商品库存查询”的小型代理输入是“某某商品还有货吗”输出是“有/无 预计补货时间”。这个代理的内部实现里LLM只负责两件事第一从用户话术中抽取商品名和查询意图第二把工具返回的库存数字翻译成人话。其他的一切比如闲聊、推荐商品、解释售后政策都被系统提示词明确禁止了。# 一个典型单任务代理的结构示意 class InventoryAgent: def __init__(self, llm): self.llm llm self.tools {query_stock: query_stock_api} self.system_prompt 你是一个库存查询助手。只处理库存相关查询其他内容一律拒绝回答。 def run(self, user_input): intent self.llm.extract(user_input, schema[product_name, intent]) if intent[intent] ! stock_query: return 抱歉我只负责库存查询。 stock_info self.tools[query_stock](intent[product_name]) return self.llm.generate_answer(stock_info)这段代码去掉了各种复杂的外部依赖但核心链路就长这样。你可以看到每一步的输入输出都是被定义死的LLM没有任何自由发挥的空间。对于“把一件事做极致”的需求来说这种结构几乎是最好的——准确率高、响应快、成本低且几乎没有失控风险。1.2 为什么单任务代理容易给人“很蠢”的感觉但单任务代理也有一个天生缺陷它的能力边界非常僵硬。一旦用户的需求绕过了那道边界哪怕是一句简单的“帮我顺便看看这款商品的评价”代理也会直接拒绝或者报错。于是很多人开始觉得这玩意儿“太笨了”接着就想往里面塞更多能力。一个典型误区是多塞几个工具副本把不同任务塞进同一个提示词里就认为它变成了多任务代理。实际上不是。“既能查库存、又能查物流、又能查退换货政策”的代理如果内部没有真正的任务分发逻辑而只是把所有工具的说明都写进提示词让LLM自己选那它是一个拥有多个工具的单任务代理——因为它同时还是没有任务边界还是凭模型“临场感觉”决定该干什么。这种结构的最大问题在于LLM的工具选择往往会有随机性尤其在工具列表超过五个之后选错工具的概率会明显上浮。这也是我们在项目里反复踩过的一个坑。2. 多任务代理的本质不是“会的多”而是“编排好”理解了单任务代理再看多任务代理就顺理成章了。多任务代理的关键词不是“多”而是编排。它要对一系列子任务进行规划、路由、执行和结果合并最终给用户一个统一完整的响应。2.1 多任务代理的两种主流实现形态我平时接触到的多任务代理大致可以分为两类下面分别说明。一类是单体多任务。整个系统还是一个代理内部有多个任务处理器Handler业务流程通过一个路由器做分发。比如你输入“把这份文档翻译成英文然后提取里面的三个关键观点”代理会先调用翻译Handler等翻译完成后再把结果喂给观点提取Handler最后把两个结果合并输出。这类代理的好处是全局状态统一管理用户感知是和一个“人”在对话劣势在于任务流水线一旦变长上下文会被反复注入Token消耗和新任务的干扰都会明显上升。另一类是多智能体协作。每个子任务由一个独立的代理负责代理之间通过消息或共享状态互相通信。还是上面翻译加提取的场景这里会有一个调度代理把任务拆开分发给一个翻译代理和一个提取代理再回收各自的结果排序输出。这类形态隔离性好可以单独升级某个子代理而不影响其他模块调试起来非常直观但代价是你得额外处理代理之间的通信协议、时间同步和数据一致性问题。在需要十几个子任务协作的复杂场景里这类“分布式”的调试成本会成倍增加。2.2 一个常见的误导性说法“用越大越聪明的模型多任务效果就越好”这个说法部分成立但不全对。大模型的能力确实能提升单步任务的完成质量但多任务系统的整体效果更多取决于任务拆解的合理性和数据流转的完整性。我曾经把一个四任务代理的LLM从普通规模的模型换到顶级规模的模型结果整体效果只提升了大约7%倒是成本翻了近十倍。后来我重新调整了子任务的先后顺序把原本混乱的数据依赖理顺没有换模型整体正确率却提升了近20%。这给我的触动特别深多任务代理的瓶颈往往不在“模型智商”而在“架构设计”。3. 同样的客服场景单任务和多任务的实现差异究竟有多大抽象概念说再多都不如拿一个具体的业务场景来对照。我选大部分人都有感知的“售前咨询智能体”作为例子。同样是一个客服入口用单任务代理怎么做用多任务代理怎么做我实际对比过。单任务代理的做法很直接设置一个主题——售前产品介绍。工具只有商品信息库提示词明确要求只回答产品规格、价格、优惠信息这三类问题。一旦用户问“你们有什么优惠吗”之外的任何问题比如“我的订单到哪里了”单任务代理就只会机械地回复“我只负责产品介绍”。看起来体验很糟糕但它的优点也极其鲜明响应速度稳定在0.8秒左右准确率几乎可以达到99%不会出现自说自话乱回答的情况而且运维成本约等于零出了问题也极其好排查因为路径是固定的。对于企业只需要解决某一个特定问题的场景单任务代理这种“偏科”反而是一种优势。多任务代理的做法完全不同。它内部会有这样一个结构路由层先把用户输入归入N个入口之一——产品介绍、订单查询、物流跟踪、售后政策、人工转接然后分发到各自对应的任务处理器每个处理器完成后结果汇总层再统一整理语气和排版输出给用户。这个系统光是路由器就需要单独调优更不用说五个处理器各自的提示词、工具配置和边界条件。我实测算下来一个完整的五任务客服代理首版调试周期大概是单任务代理的三到五倍响应时长通常会从0.8秒涨到2秒甚至更多。那为什么还要做多任务因为用户满意度数据完全不一样。单任务代理虽然快但“答非所问”的体验会让用户迅速流失多任务代理会绕路但至少每个问题都能被正确分流和响应用户不用在不同入口之间反复跳转。这个取舍本身没有绝对的对错取决于你的业务更看重单点效率还是综合体验。4. 多任务代理内部必现的三个关键机制如果你已经决定要做一个多任务代理那么有三个机制是你绕不开的路由机制、上下文窗口策略、记忆与状态共享。这三个点处理好了系统的稳定性和可扩展性才会起来。4.1 路由机制决定“谁来做”的第一道关路由层是多任务代理最基础、也最容易被低估的部分。很多人图省事直接让LLM自己去判断“用户这句话属于哪个任务”好一点的加一句“如果都不属于回复无法处理”。但实际运行中尤其是存在语义相近的任务时这种自由判断会出现系统性偏差——比如将“退货怎么申请”判到“售后政策”而不是“退货处理”将“还没发货”判到“物流查询”而不是“订单状态”。比较稳妥的做法是对每个任务定义一个分类器先做一次规则匹配再做一次向量召回。常用策略如下规则优先先匹配关键词、实体、正则等强规则命中就不用走模型向量召回把用户输入和每个任务的示例问法做向量相似度计算优先返回相似度最高的前K个LLM兜底前面两步都不确定的才交给LLM做最终判断且要求返回JSON格式的分流结果。我个人的经验是这样叠加之后路由的准确率能做到95%以上而且其中LLM要处理的流量可能只有20%左右成本优势也很明显。你可以看这样一个简单路由表用户输入示例规则匹配向量召回最终路由“怎么退货”命中“退货”关键词退货处理退货处理“衣服小了能换吗”无强规则换货 / 退货处理换货若配置“你们周末上班吗”无强规则售后政策 / 人工人工转接或兜底路由表本身是可以不断迭代的。我建议每个新增的任务都提前准备10条以上示例问法这样向量召回的效果才会稳定。4.2 上下文窗口策略如何避免多个任务互相“污染”多任务代理最常见的翻车场景是上下文污染。举例来说用户在查询订单之后又追问了另一个产品的问题如果系统直接把上一轮的订单信息带进新的产品查询里LLM很可能把订单号误当成产品编号输出一段完全不着调的内容。多任务代理在设计上下文时最需要关注的不是总长度而是隔离性。我习惯的做法是全局上下文只保留用户级基本信息如用户ID、会话ID每个子任务维护一个独立的任务上下文只存储该任务相关的历史信息任务切换后新任务不会读取上一个任务的细节除非显式声明需要。同时任务结果合并阶段要把不同子任务输出放在一个结构化的容器里并且用模板限定合并规则。你完全可以这样理解单任务代理是只有一页纸的记事本多任务代理则是带标签的文件夹——每类任务有自己的子文件夹必要的时候才归档到一起。具体到实现上这个“隔离”就是你在调用LLM时对不同的Handler传入不同的prompt和history片段而不是永远传同一个session数组。当然隔离也不是绝对的长期记忆数据比如用户的偏好标签、历史订单摘要是允许被多个任务共享的那属于“状态共享”层面和“上下文隔离”不能混为一谈。4.3 记忆与状态共享共享什么、不共享什么要有明确清单多任务代理越做越大记忆管理就会变成最缠人的活。共享状态里面到底该放什么我建议只放跨任务都需要的“事实型数据”比如用户名、会员等级、订单编号列表而不是放“上一轮的任务过程和中间推理”。后者通常是性能杀手而且容易造成任务间干扰。有一版我做的多任务客服代理第一次上线时就把所有子任务的中间结果都放进共享状态里结果用户多轮对话一多整个系统的召回准确率就往下掉。后来把所有中间过程全部改成私有上下文只保留最终的结论数据在共享状态问题立刻消失了。共享状态这里宁可多隔离也不要贪多。5. 成本、延迟和调试体验多任务代理被低估的三笔代价说实话多任务代理在业务侧的诱惑力很大因为它显得“灵活、全能”。但在工程落地的过程中有几笔账经常被低估我建议每个准备选型的人都先算清楚。成本方面同样是十个问题单任务代理调用LLM的次数通常等于问题数多任务代理可能每个问题都要调用路由层加子任务处理层再加上结果汇总层。如果你做了二次分类或者重试机制一次用户请求背后可能是三四次甚至更多的LLM调用。这不是危言耸听实测下来同等量级下多任务代理的Token成本往往是单任务代理的2到4倍。延迟方面更复杂的是延迟。多任务代理如果存在串行依赖比如必须先识别意图再查库存最后生成回答那总延迟就是各步骤延迟之和。我在测试中见过一个串联了五个子任务的代理单次全链路延迟轻松超过8秒用户早跑了。解决思路无非两条能把独立任务并行的就并行调用减少串行链路或者给路由器一个超时预算超过指定时间先输出部分结果避免“干等”。这两条建议大家可以优先考虑。调试体验方面单任务代理的排查路径非常简单报错了基本就是提示词问题、工具问题或输入格式问题三选一多任务代理的报错则是“跨模块联调”你得先确认路由是否正确再确认数据有没有正确传递再确认是哪个Handler的问题最后还得确认汇总层的格式冲突。很多时候明明答案是对的汇总层却因为JSON格式解析失败导致整个回复被拦截。这一类问题在真实项目中非常常见。下面放一个简单的对比表方便你快速评估对比维度单任务代理多任务代理单次响应延迟较低链路短偏慢链路叠加Token成本低高常有额外路由开销准确性上限极高领域受限中等依赖路由与编排扩展新能力需要重写可增量添加调试难度简单复杂跨模块定位难适合场景工具型、问题单一客服、助手型、综合入口6. 我的选型建议不要为了“多任务”而上多任务写了这么多最后聊一点实际的体会。很多人在设计智能体时第一反应是“多任务更高级”所以从一开始就奔着多任务去。但如果你仔细复盘业务需求可能会发现其中80%的请求都属于同一类固定问题那这时候上多任务代理就是在给自己的工程和成本增加不必要的复杂度。我个人的一个判断标准是当用户的输入意图类型只有1到2种时毫不犹豫选单任务当意图类型在3到5种时可以先做一个带清晰路由的多任务单体只有当意图类型超过5种而且不同任务之间存在复杂的依赖关系时才值得引入多智能体协作结构。另一个判断依据是如果你的产品天然需要用户在同一段对话里平滑切换多个主题比如综合购物助手那么多任务代理几乎是唯一的正确选项——这时候就算延迟高一点、成本贵一点也只能接受因为单任务根本兜不住这种体验。最后再分享一个我调试多任务代理的习惯每增加一个子任务我都会单独测试它的路由准确率至少要稳定超过95%才放行进入主流程同时我会为每个子任务准备一组“负面测试用例”专门用来确认它不会抢走不该属于它的请求。这样做至少能避免那种几个子任务互相打架、用户输入被反复路由到错误模块的尴尬情况。我踩过很多次坑之后才意识到很多多任务代理不是输在模型不够聪明而是输在没人认真管理“分诊”这件事。如果你正在做类似的系统不妨也从路由和状态隔离这两处入手把基础打稳再谈能力扩张。