复杂 Agent 一定要用大模型吗？小模型拆任务为什么也能做？

前两篇我们讲了两个核心结论。第一大模型不是写了更多 if-else而是内部表示空间更大能同时保留更多细粒度特征表达更复杂的条件关系。第二小模型更容易学到粗粒度相关性大模型更容易识别细分场景和问题本质。那自然会出现一个新问题既然大模型更强复杂 Agent 是不是一定要用大模型答案是不一定。复杂 Agent 可以用大模型做也可以通过任务拆解让小模型完成其中一部分甚至完成大部分。但这里有一个前提小模型不是突然变聪明了而是工程流程替它分担了复杂性。这篇文章就讲清楚复杂 Agent 到底复杂在哪里为什么大模型适合直接处理复杂任务为什么拆成小任务后小模型也能做小模型拆任务有什么代价大模型和小模型应该怎么分工一、先说结论复杂 Agent 不一定全靠大模型很多人一提到 Agent就会默认Agent 大模型比如自动写代码自动分析需求自动调用工具自动拆任务自动生成报告自动处理用户问题这些听起来都很复杂所以第一反应就是必须上大模型。但真实系统里通常不是这么做。更合理的方式是大模型负责规划、判断、兜底 小模型负责分类、提取、格式化、简单生成 规则系统负责稳定约束 RAG 负责提供事实资料 工具负责执行具体动作也就是说一个成熟 Agent 不是只有一个模型。它更像一个系统。这个系统里可能有大模型 小模型 规则 数据库 搜索 RAG 函数调用 缓存 状态机 人工审核所以关键问题不是复杂 Agent 用不用大模型而是哪些复杂性必须交给大模型哪些复杂性可以通过工程流程拆掉哪些步骤可以交给小模型低成本执行二、复杂 Agent 到底复杂在哪里很多人以为 Agent 的复杂点在“会调用工具”。其实这只是表面。真正复杂的是Agent 要在不确定的环境里持续判断下一步该做什么。比如用户说帮我分析这个情绪分析小程序为什么没有留存并给出下一步优化方案。这个任务看起来只是一句话但一个好 Agent 至少要做这些事理解用户目标 判断问题类型 拆解分析步骤 判断需要哪些信息 如果信息不够要不要追问 分析用户场景 分析产品价值 判断留存差的可能原因 排除无效方案 生成优先级 输出可执行计划如果还要更进一步比如让 Agent 真正执行任务它可能还要读取项目代码 查看用户数据 分析日志 生成埋点方案 修改前端页面 修改后端接口 更新数据库表 写测试用例 生成发布计划所以 Agent 的复杂性主要来自五个方面。1. 目标不明确用户经常不会把需求说完整。例如我的产品没有留存怎么办这句话里缺少很多信息什么产品 用户是谁 现在留存数据是多少 用户从哪里来 第一次使用路径是什么 产品核心功能是什么 有没有用户反馈Agent 需要判断现在能不能直接回答 要不要先追问 能不能先给一个分析框架这就是复杂性。2. 任务需要拆解复杂任务通常不能一步完成。比如分析产品没有留存至少可以拆成确定目标用户 分析用户首次使用动机 分析核心功能价值 分析用户第二次回来的理由 分析当前产品闭环 找出留存断点 给出优化方案 设计验证指标拆解本身就是能力。如果拆错了后面每一步都可能错。3. 中间结果会影响后续步骤Agent 不是简单流水线。它需要根据中间结果调整下一步。比如如果发现用户只是娱乐性使用 → 应该分析传播和分享 如果发现用户有长期记录需求 → 应该分析记录、复盘和趋势 如果发现用户只是想被安慰 → 应该分析陪伴和反馈机制这叫动态决策。4. 需要处理异常和边界情况真实任务里经常会遇到数据缺失 用户表达含糊 工具调用失败 搜索结果冲突 代码修改报错 生成结果格式错误 模型理解跑偏Agent 不能只会顺风执行还要会处理异常。5. 需要判断结果是否合理一个真正可用的 Agent 不能只是输出结果。它还要判断这个方案是否解决原问题 有没有遗漏关键约束 有没有自相矛盾 有没有编造事实 有没有执行风险这一步非常吃模型能力。所以复杂 Agent 的核心不是“会调用工具”而是在多步骤、多约束、不确定环境下持续做正确判断。三、为什么大模型适合直接做复杂任务因为大模型的内部表示空间更大能同时保留更多上下文特征。还是用这个任务帮我分析情绪分析小程序为什么没有留存并给出优化方案。一个强模型可能在一次回答里同时考虑情绪分析产品 小程序场景 用户首次体验 长期复访理由 娱乐需求和刚需的区别 记录复盘价值 行动建议闭环 分享传播可能性 商业化方向 当前阶段应该先验证需求它能把这些因素放在一个上下文里综合判断。这就是大模型的优势。它不需要你把每一步都写死。它可以在内部完成很多隐式推理理解目标 拆任务 判断重点 排除低价值方案 组织答案所以大模型路线通常是复杂输入 → 大模型内部理解和推理 → 直接输出结果优点很明显开发简单 上下文理解强 边界判断更好 开放问题处理能力强但缺点也明显成本高 延迟高 并发压力大 结果不一定稳定 私有化部署更难所以大模型强但不是所有步骤都应该用大模型。四、小模型为什么也能做复杂系统关键原因是复杂任务可以被拆成多个简单任务。原来你让模型直接做分析用户反馈并给出产品优化方案这对小模型来说太复杂。因为它要同时完成理解语义 识别意图 抽取信息 判断场景 推理原因 生成方案 组织表达但是你可以把任务拆开。例如第一步判断用户反馈属于哪类问题 第二步提取反馈中的关键词 第三步判断用户情绪 第四步判断是否是留存问题 第五步匹配产品知识库 第六步生成候选原因 第七步根据规则排序 第八步生成最终回复 第九步检查输出格式每一步都变得更简单。原来是一个复杂函数F(x) y拆解后变成多个简单函数f1(x) a f2(x, a) b f3(x, a, b) c f4(x, a, b, c) y这就是小模型可以参与复杂系统的底层原因。不是因为小模型突然具备了大模型的全部能力。而是工程流程降低了每一步的复杂度。五、用一个具体例子说明假设用户输入我这个情绪分析小程序没有留存应该怎么办如果直接交给小模型它可能输出可以增加签到、积分、排行榜、每日提醒。这个答案太泛。但如果你把流程拆开小模型可能就能发挥作用。第一步意图分类输入我这个情绪分析小程序没有留存应该怎么办输出{intent:product_retention_analysis,confidence:0.91}这个任务比较简单小模型可以做。第二步产品类型识别输出{product_type:emotion_analysis_mini_program,domain:mental_emotion,usage_pattern:likely_low_frequency_or_trigger_based}这个任务稍复杂但如果类别提前定义好小模型也可以做。第三步问题归因候选系统根据产品类型和问题类型匹配知识库或规则情绪类产品留存可能原因 1. 单次体验偏娱乐 2. 缺少长期记录价值 3. 用户没有周期性触发场景 4. 分析结果没有行动建议 5. 没有形成个人数据资产这一步不一定要靠模型可以靠规则或 RAG。第四步生成回答小模型拿到结构化信息后再生成你的问题不应该先从签到积分入手而应该先判断用户为什么会第二次回来。情绪分析产品如果只是一次性娱乐留存天然会低。可以从长期记录、趋势复盘、行动建议三个方向重构产品闭环。这时小模型回答会比直接回答好很多。为什么因为前面的流程已经帮它把复杂问题拆开了。小模型不需要自己完整理解所有上下文只需要基于明确中间结果做生成。六、这就是大小模型的本质分工可以用一句话总结大模型用参数容量处理复杂性。小模型用工程流程处理复杂性。大模型路线复杂问题 → 大模型内部建模 → 输出答案小模型路线复杂问题 → 拆成简单步骤 → 小模型/规则/RAG 分别处理 → 汇总结果 → 输出答案这两种路线没有绝对谁对谁错。区别是成本结构不同。七、大模型路线和小模型路线的对比方案本质优点缺点大模型直接做把复杂性放进参数里理解强开发快适合开放问题成本高延迟高结果不一定稳定小模型拆任务把复杂性放进流程里成本低可控容易部署工程复杂拆解成本高容易误差传播混合方案大模型做规划小模型做执行成本和效果平衡架构设计要求更高真实系统最常见的不是纯大模型也不是纯小模型。而是混合方案。八、拆任务不是免费午餐误差会传播很多人一听到“小模型拆任务”会觉得找到省钱方案了。但必须冷静。拆任务有一个严重问题前面一步错了后面可能全错。假设一个流程有 6 步。每一步准确率都是 95%。看起来很高。但如果每一步强依赖前一步整体成功率大约是0.95^6 ≈ 73.5%如果每一步准确率是 90%0.9^6 ≈ 53.1%这就是很多 Agent 系统不稳定的原因。单步看起来都还行。但链路一长错误会不断放大。比如第一步把用户意图判断错 → 第二步匹配错知识库 → 第三步生成错方案 → 第四步还一本正经输出所以小模型拆任务必须配套置信度判断 格式校验 规则校验 大模型兜底 失败重试 人工审核 日志监控 评测集回归测试否则就是把一个大错误拆成多个小错误。九、什么时候适合拆给小模型不是所有复杂任务都适合拆。适合拆给小模型的任务一般有几个特点。1. 子任务边界清楚例如判断情绪类别 提取关键词 判断是否高风险 识别用户意图 输出固定 JSON这些任务输入输出都比较明确。适合小模型。2. 输出可以结构化比如{intent:seek_advice,emotion:anxiety,risk_level:low,confidence:0.87}结构化输出更容易校验。如果模型输出自然语言长文校验难度就高很多。3. 有规则可以兜底比如JSON 不合法 → 重试 confidence 低于 0.8 → 升级大模型 出现高风险关键词 → 固定安全策略 输出包含编造字段 → 拒绝通过有规则小模型才安全。4. 错误成本低例如普通标签分类 普通摘要 普通文案生成 格式转换即使错了也不会造成严重后果。这类任务适合用小模型降成本。5. 数据分布稳定如果用户输入类型比较固定小模型更容易做好。例如客服系统里 80% 问题都集中在退款 发票 物流 账号 会员小模型可以做得很好。但如果用户输入千奇百怪小模型就容易跑偏。十、什么时候不适合只用小模型下面这些场景不建议只靠小模型。1. 用户意图非常模糊例如我也不知道自己想问什么就是感觉哪里不对。这类输入需要更强的上下文理解。2. 任务没有固定答案例如这个创业方向值不值得继续做这不是简单分类。它需要多维度判断。3. 需要长上下文理解例如根据我过去 30 天的情绪记录分析我的主要触发因素。这需要整合多条记录。小模型容易遗漏、混淆、编造。4. 错误成本高例如用户表达强烈痛苦 金融投资建议 医疗法律判断 重要业务决策这些场景不能为了省钱硬用小模型。5. 需要动态规划例如帮我自动分析项目代码、找出问题、修改并测试。这类 Agent 需要持续根据结果调整下一步。小模型很容易中途跑偏。十一、混合架构更现实的 Agent 方案真正实用的 Agent 架构一般是混合的。可以这样设计小模型负责便宜高频的初筛和结构化任务 中模型负责普通生成和简单分析 大模型负责复杂推理、规划、兜底和高风险处理 规则系统负责边界、安全和格式校验 RAG负责提供外部知识和业务资料 工具系统负责真实执行比如情绪分析产品可以这样分工模块推荐方式情绪分类小模型意图初筛小模型高风险关键词初筛规则 小模型普通安慰文案7B / 12B个性化建议12B / 32B长期复盘分析32B / 70B高风险表达处理规则 大模型 固定安全策略产品策略分析大模型这样做的好处是大部分请求便宜处理 少部分复杂请求升级处理 关键风险不靠小模型硬扛 整体成本可控十二、一个简单的 Agent 分层流程可以用下面这个流程理解用户输入 ↓ 小模型做意图识别、情绪识别、风险初筛 ↓ 规则判断是否需要升级 ↓ 如果简单小模型或中模型生成回复 ↓ 如果复杂大模型分析 ↓ 如果高风险固定安全策略 大模型/人工兜底 ↓ 输出前做格式和安全校验 ↓ 记录日志用于后续评测伪代码可以这样写defhandle_user_input(user_input):analysissmall_model.classify(user_input)ifanalysis.risk_levelhigh:returnsafety_flow(user_input)ifanalysis.confidence0.8:returnbig_model.analyze(user_input)iflen(user_input)1000:returnbig_model.analyze(user_input)ifanalysis.intentin[simple_emotion_record,basic_comfort]:returnsmall_or_mid_model.reply(user_input,analysis)ifanalysis.intentin[deep_analysis,long_term_review,product_strategy]:returnbig_model.analyze(user_input)returnmid_model.reply(user_input,analysis)这个结构比“所有请求都用一个模型”更合理。十三、拆任务的关键不是拆得多而是拆得对这里要特别强调。很多人做 Agent 时会犯一个错误把一个任务机械拆成很多步骤以为步骤越多越智能。不是。步骤越多错误传播越严重延迟也越高。好的拆解应该满足每一步都有明确目标 每一步输入输出稳定 每一步结果可以校验 每一步失败可以处理 每一步都真的降低复杂度坏的拆解是为了拆而拆 每一步都很模糊 中间结果无法验证 模型错了也不知道 最后输出看起来很长但没解决问题所以拆任务不是 Prompt 技巧而是系统设计能力。十四、Agent 的核心不是“模型”而是“控制系统”很多人把 Agent 理解成一个大模型 工具调用但更准确地说Agent 是一个围绕模型构建的控制系统。它至少要解决当前状态是什么 下一步做什么 调用哪个工具 结果是否可信 失败如何处理 什么时候停止 什么时候升级 什么时候让人介入模型只是其中一个组件。大模型可以让这个控制系统更聪明。小模型可以让这个控制系统更便宜。规则和工具可以让这个系统更稳定。所以不要迷信只要换一个更大的模型Agent 就能稳定工作。大模型能提高上限。但工程系统决定下限。十五、最终总结复杂 Agent 不一定全靠大模型。大模型强在上下文理解 复杂语义判断 任务规划 边界案例处理 低信息场景推理小模型强在成本低 速度快 适合固定任务 适合结构化输出 适合高频简单环节复杂任务之所以可以交给小模型处理是因为工程流程把一个复杂函数拆成了多个简单函数。原来F(x) y拆成f1(x) a f2(x, a) b f3(x, a, b) c f4(x, a, b, c) y每一步复杂度下降小模型就能参与。但拆任务有代价工程复杂度上升 延迟可能上升 错误会传播 需要校验和兜底所以这一篇的核心结论是大模型用参数容量处理复杂性。小模型用工程流程处理复杂性。真正成熟的 Agent不是全用大模型也不是硬省成本全用小模型而是让不同模型、规则、RAG 和工具各自处理自己最擅长的部分。