前两篇我们讲了两个核心结论。

第一：

大模型不是写了更多 if-else，而是内部表示空间更大，能同时保留更多细粒度特征，表达更复杂的条件关系。

第二：

小模型更容易学到粗粒度相关性，大模型更容易识别细分场景和问题本质。

那自然会出现一个新问题：

既然大模型更强，复杂 Agent 是不是一定要用大模型？

答案是：

不一定。

复杂 Agent 可以用大模型做，也可以通过任务拆解，让小模型完成其中一部分，甚至完成大部分。

但这里有一个前提：

小模型不是突然变聪明了，而是工程流程替它分担了复杂性。

这篇文章就讲清楚：

1. 复杂 Agent 到底复杂在哪里？
2. 为什么大模型适合直接处理复杂任务？
3. 为什么拆成小任务后，小模型也能做？
4. 小模型拆任务有什么代价？
5. 大模型和小模型应该怎么分工？

---

一、先说结论：复杂 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 分层流程

可以用下面这个流程理解：

用户输入
↓
小模型做意图识别、情绪识别、风险初筛
↓
规则判断是否需要升级
↓
如果简单：小模型或中模型生成回复
↓
如果复杂：大模型分析
↓
如果高风险：固定安全策略 + 大模型/人工兜底
↓
输出前做格式和安全校验
↓
记录日志，用于后续评测

伪代码可以这样写：

def handle_user_input(user_input):
    analysis = small_model.classify(user_input)

    if analysis.risk_level == "high":
        return safety_flow(user_input)

    if analysis.confidence < 0.8:
        return big_model.analyze(user_input)

    if len(user_input) > 1000:
        return big_model.analyze(user_input)

    if analysis.intent in ["simple_emotion_record", "basic_comfort"]:
        return small_or_mid_model.reply(user_input, analysis)

    if analysis.intent in ["deep_analysis", "long_term_review", "product_strategy"]:
        return big_model.analyze(user_input)

    return mid_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 和工具各自处理自己最擅长的部分。