大模型使用经验与模型分工
我是怎么用大模型的——任务分工、模型选型与多 Agent 编排的实战经验
这篇是个人经验分享，内容来自我在 10+ 个 AI 项目中反复踩坑后的判断。不讲"大模型能做什么"，只讲"我实际怎么做、为什么这么做"。
引子：我每天在多个模型之间切换
先交代一下背景：我手上同时在用多个大模型服务，不是炫技，是真的不同场景需要不同的工具。
| 模型 / 服务 | 我给的定位 | 日常干什么 |
|---|---|---|
| Claude（App） | 强推理 + 长上下文主力 | 聊天、项目复盘、前端设计、架构设计 |
| Gemini（免费层） | 第二意见 | 聊天二号选手、同一个问题对比不同模型输出，交叉验证 |
| DeepSeek V4（API） | 低成本施工主力 | 代码生成、接口实现、批量任务、第一版快速落地 |
| ChatGPT 5.4（中转） | 第二推理引擎 | 复杂逻辑复核、Claude 不可用时的替代推理 |
| 小米 AI Pro | 免费送的快领 | 免费送的要啥自行车 |
| Ollama qwen3:4b（本地 RTX 3060） | 离线 / 开发测试 | 本地快速原型、断网时的兜底、轻量编辑 |
切的逻辑不是看心情，是看任务类型。 下面具体讲我怎么判断。
一、核心框架：四大层级
大模型使用中最常见的误区，是把"模型能力强"等同于"什么场景都该用它"。我的教训是反过来的：越强的模型越要省着用，用在刀刃上。
我把日常的 AI 任务分成了四大层级：
1. 全知全能→ Claude（强推理）
特征： 长上下文、多信息源、需要判断"什么该保留、什么该合并、什么该删"
我的真实场景：
- 聊天 — 5 小时额度用完拉倒，找资料、推荐小软件这类随手问
- 项目探讨 — 总有创造性思维，会结合你的资料提出可行的新点子，不是那种"你说 A 它回 A"的复读机
- 前端 — Claude 出的 UI 我基本不用改，别的模型出来的总要调好几轮
- 框架设计 — 想得全面，会主动推演扩展方向和边界条件，好的框架施工赢一半
为什么是 Claude： 这类任务的难点不在"写出来"，而在"判断取舍"。我让轻量模型做过项目复盘——技术决策的推理过程全丢了，只剩正确的废话。Claude 在 100K+ token 上下文里对细节的敏感度确实更好。总结类任务当然也能用别的大模型，但"创造性判断"这件事——什么该保留、什么该砍、哪里需要重构——Claude 的判断力就是更靠谱。
前端： 我一般让 Opus、GPT、DeepSeek V4 Pro 各出一版，然后自己挑。别的也不是难看，但 Claude 的就是更顺眼——说不清楚为什么，反正不用改。多出几个方案，挑就完了。
框架设计： 好的框架施工赢一半。Claude 不会只盯着当前需求写，会多想一步，追问"以后加 XX 会不会有问题"。施工型模型没这个习惯。我现在基本是 Opus + Ultra 对齐架构，看清楚路了，再切 Flash 施工。
许愿级场景： 当事情真的解决不了了——那种"搞了三天还不对、越改越乱、所有轻量模型都试过一轮全翻车"的时候，我会直接上核武器：Opus 4.7 拉满，GPT 拉满，最大模型、最大思考级别、最大预算，全部梭哈。 不是理性决策，是信仰充值。但说真的，这种级别的模型确实能在"所有人都看不懂"的时候找到那条正确的路——它看见的不是代码，是因果链。每次梭完都觉得这钱花得值。
一个例子： 我写 [[多Agent协作架构原则]] 那份文档时，原始材料散落在当日日记、项目总览、各子项目的设计文档里——时间跨度好几天、文件数量十来个。Claude 一次性读完所有材料，不仅能保留每个项目的技术细节，还能判断哪些内容应该升为全局原则、哪些只适合放在具体项目里。这种"结构判断力"是施工型模型做不到的。
2. 大模型用途 → DeepSeek V4 Pro / GPT 5.5
特征： 量大管饱、需要结构化输出，V4 Pro 和 GPT 5.5 各有主场
DeepSeek V4 Pro 的主力场景：
- 把一整天的 Obsidian 日记整理成结构化复盘
- 把散落在多个项目文件中的信息重组成一篇架构文档
- 多轮对话后的沉淀总结
- 写技术文章、通用内容
- 第一波修 Bug — 先把明显的问题筛一轮，跑通再说
GPT 5.5 的主力场景：
- 写更专业、更有外国味道的文章 — 那种需要"GPT 味"的东西，V4 Pro 写出来总感觉差一口气
- 行业研究、专业分析 — 逻辑链条更紧密，不是"信息汇总"而是"分析 + 论证"
- 修 Bug 二把手 — Claude 不在或者 Bug 没那么深的时候顶上
两句话总结：
- V4 Pro = 干活主力，便宜量大，写文章、做总结、第一波修 Bug 全包
- GPT 5.5 = 专业输出，要拿出去给人看的、要有"GPT 味"的、V4 Pro 搞不定的第二波
3. 小模型施工 → DeepSeek V4（低成本 + 高频）
特征： 目标明确、步骤清楚、需要快速出活
我的真实场景：
- "给 FastAPI 补一套 CRUD 接口"
- "Vue3 组件改成响应式布局"
- "生成一个 LangGraph StateGraph 骨架"
- "Docker Compose 模板 + Nginx 配置"
为什么用 DeepSeek： 目标已经非常清楚了，不需要"全局理解"和"结构判断"。我要的是快、便宜、可以反复调用。我的 P1 SlimTrack 项目从 0 到上线，大部分 CRUD 代码都是 DeepSeek 生成的，如果用 Claude 也能做，但成本高出几倍，代码质量并没有成比例提升。
什么时候又切回 Claude： 涉及跨文件逻辑的时候。比如 LangGraph 的条件路由 + 错误恢复链路——函数 A 的异常处理会影响函数 B 的状态流转。DeepSeek 在这个场景下容易"修一个 Bug 引出另一个 Bug"。我的做法是：Claude 做根因分析 → DeepSeek 执行修复。
修 Bug 和写代码是两种完全不同的能力。
修 Bug 需要"怀疑精神"——同时考虑多个可能的根因，而不是拿着第一个猜测就开修。施工型模型容易修完表面又出新问题。P4 多 Agent 系统的状态传播 Bug，DeepSeek 修了 3 次都没解决根因；Claude 一次就定位到是 State 字段粒度不够导致两个 Agent 对同一个 key 有歧义。
4. 修 BUG 专项
不管前面怎么分工，修 Bug 这件事值得单独拎出来说。
三层火力配置：
| 层级 | 模型 | 什么场景 |
|---|---|---|
| 第一波 | DeepSeek V4 Pro | 先筛一轮，明显的问题直接修掉，跑通再说 |
| 二把手 | GPT 5.5 | Claude 不在或 Bug 没那么深的时候顶上，逻辑推理仅次于 Claude |
| 终极武器 | Claude + Ultra 思考拉满 | 跨模块因果链 Bug、搞了几天没修好的——所有可能路径全跑一遍，不漏根因 |
为什么 Bug 修复要分层： 大部分 Bug 不需要终极武器。先让 V4 Pro 扫一遍，剩下的疑难杂症往上升级。这和医院分级诊疗一个道理——不是每个感冒都要挂专家号。
5. 本地做实验 → Ollama 本地（附）
特征： 学习目的为主，搞清楚本地模型能干什么、不能干什么。RTX 3060 6GB 显存，跑 qwen3:4b 刚好，再大就卡。
我的真实场景：
- 改标题层级、统一 Markdown 格式
- 调语气、翻译小段文字
- 生成 JSON Schema、yml 配置
- 给笔记批量加 frontmatter
- 断网或者 API 挂了的时候兜底
体会： 本地模型跟云端差距还是挺明显的。4b 这个量级，简单的格式活能干，但稍微需要"理解"的东西就容易跑偏。比如让它总结一段文字，出来的东西经常抓不住重点。好处是零延迟、零成本、无限调用——改个标题、调个格式这种事，不需要云端 100K 上下文的模型来干。
为什么不能"杀鸡用牛刀"： Claude 当然也能做，但它的上下文窗口是稀缺资源——在 100K token 里翻找一个改标题只需要的信息，效率极低。我现在有意识地把轻任务分流到本地，保持 Claude 的窗口只装真正需要深度处理的内容。能在本地跑的本地跑，能批量处理的丢 DeepSeek。
二、一个我每天都在用的判断流程
基于上面的四大层级，我内化了一套快速决策流程：
▼text复制代码拿到一个任务 │ ▼ Q1: 需要创造性思维 / 架构审美 / 复杂推理吗？ （聊天探讨 / 前端设计 / 框架设计 / Bug 排查） │ ├── 是 → Claude（全知全能 + 终极 Bug 修复） │ └── 否 → Q2: 是写文章 / 做总结 / 修 Bug 吗？ │ ├── 是 → 要拿出去给人看 / 要"GPT 味"吗？ │ ├── 是 → GPT 5.5（专业文章 / 二把手修 Bug） │ └── 否 → DeepSeek V4 Pro（复盘 / 笔记 / 第一波修 Bug） │ └── 否 → Q3: 是写代码 / 施工吗？ │ ├── 是 → DeepSeek V4（小模型施工） │ └── 否 → Ollama 本地（轻量编辑 / 实验）
这个框架背后的四个洞察
洞察 1：长上下文理解才是强模型的真正壁垒。 不是所有"难"任务都需要强模型——只有那些需要跨段落、跨文件、跨时间线理解的任务才真的需要。一个 CRUD 接口再复杂，它需要的也只是"写代码"，不是"理解上下文"。
洞察 2：施工型模型的定位是"先跑通，再优化"。 大多数功能的第一版不需要完美。用 DeepSeek 快速出 MVP，验证方向对了再用 Claude 精修关键路径。这个节奏比"每个版本都用 Claude 慢慢雕"快得多。
洞察 3：上下文窗口比算力更稀缺。 Claude 的 100K 上下文窗口不要用来做"改个标题"。我现在有意识地把轻任务分流到本地 Ollama 或 DeepSeek，保持 Claude 的上下文窗口"干净"——只装真正需要它深度处理的内容。
洞察 4：模型人格是试出来的。 上面这个流程图看着清楚，但真正内化靠的不是背——是每个模型都用过几十次之后，你自然就知道什么任务该找谁。比如 Claude 前端出得顺眼、GPT 写的英文邮件就是地道、DeepSeek 批量施工不用心疼——这些都不是 Prompt 能描述的，是自己一遍遍对比出来的肌肉记忆。
三、一个类比：大模型是领导，小模型是兵
用久了之后，我对模型分工有一个越来越清晰的直觉：
模型小 → 拿来干活。模型大 → 拿来统筹、总结。
非常像一个公司。大模型是大领导——不做具体执行，但决定方向、判断取舍、在关键时刻拍板。小模型是大头兵——执行力强、便宜、可以铺量，但不会主动思考"这件事该不该做"。
| 角色 | 模型 | 干什么 |
|---|---|---|
| 大领导 | Claude | 定方向、判取舍、架构决策、创造性突破、终极 Bug 修复 |
| 中层干部 | GPT 5.5 | 专业分析、行业报告、"GPT 味"文章、二把手修 Bug |
| 技术骨干 | DeepSeek V4 Pro | 总结复盘、文档重构、通用写作、第一波修 Bug |
| 大头兵 | DeepSeek V4 | 代码施工、批量任务、第一版快速落地 |
| 实习生 | Ollama 本地 | 格式调整、局部替换、不花钱的实验 |
这个类比的本质是：不是所有问题都需要 CEO 亲自下场。但 CEO 下场的时候，一定是因为头兵搞不定了。
用久了还会发现，每个模型都有自己的"人格"：
- Claude — 有主见，会反驳你，审美挑剔。不是那种你说什么它就做什么的助手，更像一个敢跟你争论的搭档。出的东西经常让你觉得"我靠这也行"。
- GPT 5.5 — 洋气，写东西有股"外国味"，逻辑严密但偶尔啰嗦。适合拿出去撑场面。
- DeepSeek V4 Pro — 老实人。不挑活、不废话、给什么干什么，出来的东西稳但不惊艳。第一波修 Bug 的可靠选择。
- DeepSeek V4 — 快枪手。便宜到可以随便造，代码一把梭，行就行不行拉倒，不行再改。
- Ollama 本地 — 憨。慢，笨，但免费。改个标题、调个格式这种事，它干得比谁都踏实。
这些感觉不是看文档看来的，是反复用、反复翻车、反复对比之后攒出来的。多试，多总结。最后一条：看好钱包，梭哈的时候想想月底账单。
四、实战：三个项目里的模型分工
上面说的是理论框架，下面是它在真实项目里的落地。
P2 学习助理：一条链路上的三种模型
P2 的核心流程是：视频 → 转录 → 知识点提取 → 结构化笔记 → 知识库入库。每个环节需要的模型能力不一样。
▼text复制代码B站/YouTube 视频 │ ▼ Whisper large-v3（本地 GPU） ← 专用模型，不是 LLM 的活 │ 转录文本 + 时间轴 ▼ DeepSeek V4 ← 施工型：提取关键概念、生成搜索词 │ 关键概念列表 ▼ Claude ← 强推理：补充资料搜索 + 知识结构整合 │ 结构化 Markdown 笔记 ▼ Ollama qwen3:4b（本地 Embedding） ← 轻量：向量化入库 │ ▼ Chroma / Milvus 知识库
为什么不在一个节点用 Claude 包办所有？
成本只是一方面。更关键的原因是：如果让 Claude 既做提取又做整合，它的注意力会被分散，整合质量反而下降。拆开之后，每个模型只关注一件事——DeepSeek 提取不关心结构，Claude 整合不关心提取。整体质量比"单模型全包"更高。
P4 电商 Copilot：Supervisor 用 Claude，Specialist 用 DeepSeek
P4 是 Supervisor + Specialist 架构：Supervisor 负责意图识别和路由，Order / Product / 售后三个 Specialist 各管一摊。
▼text复制代码用户："退单重拍，地址换了" │ ▼ Supervisor（Claude） ← 意图识别 + 任务拆解 + 路由决策 │ ├──→ Order Agent（DeepSeek） ← 查订单、退单、退款 ├──→ Product Agent（DeepSeek） ← 查库存、推荐替代品 └──→ 汇总（Claude） ← 整合结果，生成回复
为什么 Supervisor 必须是 Claude： "退单重拍，地址换了"这句模糊请求，需要拆成"退款 + 查库存 + 重新下单 + 改地址"四个子任务，还要判断执行顺序。这是典型的"理解全局"——施工型模型容易漏掉隐含的子任务。
为什么 Specialist 用 DeepSeek 就够了： Order Agent 收到的是"查 ORD-123 订单状态"——确定性操作，不需要推理。
成本对比： 1 次 Claude 推理 + 3 次 DeepSeek 执行，比 4 次全部 Claude 便宜 60%，效果几乎一样。
P9 CoreAI：三层 Agent 的分层选型
P9 是我最复杂的项目——感知层、思考层、执行层三层架构。
| 层级 | Agent | 模型 | 原因 |
|---|---|---|---|
| 感知层 | 转录 Agent | Whisper（专用） | 语音识别不是 LLM 的活 |
| 感知层 | 抓取 Agent | DeepSeek | 网页结构化提取，目标明确 |
| 思考层 | 研究 Agent | Claude | 多轮搜索反思，需要强推理 |
| 思考层 | 规划 Agent | Claude | 复杂任务拆解，需要全局判断 |
| 执行层 | 工具 Agent | DeepSeek | 调 API、查数据库，确定性操作 |
| 执行层 | 推送 Agent | 规则引擎 | 不需要 LLM |
规律很明显：越靠近"理解与决策"，越需要强模型；越靠近"执行"，越可以用施工型甚至规则引擎。
五、多 Agent 编排：模型分工的架构升级
模型分工解决了"一个任务用什么模型"，但复杂系统还有更深的问题：多个任务之间怎么协作？
我现在的原则是：新项目默认考虑多 Agent 架构。 不是每个项目都需要，但每个项目的架构设计必须回答——"如果以后需要多 Agent，当前设计是否支持？"
为什么单 Agent 不够用
▼text复制代码单 Agent 的问题： 一个 Prompt 塞所有场景 → Prompt 越来越厚、越来越难维护 所有 Tool 对同一个 Agent 可见 → 客服 Agent 能调退款 API，误调用风险高 LLM 幻觉 / Tool 选错 / 参数传错 → 三种错误混在一起，定位困难 多 Agent 的解法： 每个 Agent 的 Prompt 短而专注 → 只干一件事 每个 Agent 只看自己的 Tool → 不会越界 哪个 Agent 出问题一目了然 → 独立调试、独立测试
本质是关注点分离（Separation of Concerns）——这是软件工程的经典原则，在多 Agent 架构里同样适用。
三条核心设计原则
1. Supervisor 用强模型，Specialist 用施工型。 这是"模型分工 + Agent 分工"的自然延伸：Supervisor 做意图理解和路由决策（理解全局），Specialist 做明确任务执行（施工）。
2. Agent 间不直接通信，所有中间结果写 State。 这不是技术洁癖，是调试需求。当系统出问题时，可以回放 State 的每一次变更，精确定位哪个 Agent 的哪一步出了问题。Agent-to-Agent 直接通信会让调用链不可追踪。
3. 一个 Agent 挂了不影响其他。 工程上的"降级优雅"。Product Agent 超时了，Supervisor 标记"商品信息暂不可用"，其他 Agent 继续跑——而不是整个请求卡死。
面试价值
多 Agent 是 2026 年 AI 工程面试的高频考点。这套经验对应几个高频问题：
| 面试问题 | 我的回答框架 |
|---|---|
| "多 Agent 之间怎么通信" | 不搞 Agent-to-Agent，所有中间结果写 LangGraph State |
| "单 Agent 和多 Agent 怎么选" | 关注点分离四维评估：场景复杂度 / 权限边界 / 测试独立性 / 迭代成本 |
| "一个 Agent 挂了怎么办" | 分层处理：Agent 级重试 → Supervisor 降级 → 用户通知 |
| "Tool 权限怎么管" | 每个 Agent 只看自己职责范围的 Tool，重叠 > 30% 说明职责没划清 |
一句话记住：多 Agent 不是把 LLM 调用拆成多个——是把职责拆开、把状态收拢、把错误隔离。拆是手段，收敛和隔离才是目的。
六、五条可复用的原则
1. 先判任务类型，再选模型
不要问"哪个模型最强"，要问"这个任务是什么类型，最适合什么模型"。判断核心就两个维度：是否需要创造性与全局判断、是否需要长上下文理解。
2. 大模型做领导，小模型做兵
强模型定方向、判取舍、做架构决策。施工模型做执行、铺量、快速落地。不是所有问题都需要 CEO 亲自下场——但 CEO 下场的时候，一定是因为头兵搞不定了。
3. 保护强模型的上下文窗口
100K token 的上下文窗口不要用来改标题。轻任务全部下放——本地 Ollama 或 DeepSeek 批量处理。保持 Claude 的上下文窗口只装真正需要深度处理的内容。
4. 复杂系统用多 Agent 做关注点分离
不要把不同职责塞进同一个 Prompt。拆成多个 Agent，每个 Agent 独立的 Prompt + Tool 集。Supervisor 负责路由，Specialist 负责执行。State 统一管理，错误逐层降级。
5. 建立成本追踪习惯
不知道钱花在哪，就没办法优化模型选型。至少记录：每个模型每月花多少、调用量多少、主要用在哪些任务上。数据是最好的选型依据。
写在最后
回头看，我使用大模型的方式经历了三个阶段：
第一阶段： 只用一个模型，所有任务都丢给它，能用但效率低、成本不可控。
第二阶段（4月）： 开始有意识按任务类型选模型——Claude 做重活，DeepSeek 做轻活。效率和成本都明显改善。
第三阶段（未来）： 引入多 Agent 编排。不只是模型级别的分工，而是架构级别的关注点分离。每个 Agent 有明确的职责边界，出问题能精确定位。
如果只记住一句话：大模型使用经验的关键，不是"用了多少个模型"，而是"有没有把每个模型放在它最擅长的位置"。 分工清楚之后，大模型才会从一个对话工具，变成真正可复用的生产力系统。
那么，可以猜一下，这个文章用了哪个大模型？
最后更新： 2026-05-03 关联文档： [[多Agent协作架构原则]] · [[01 项目总览]] · [[02 项目说明]] · [[10 PP4-API用量面板]]
