Agent 工作流里，模型分工为什么会越来越明显

前两年大家聊多模型，很多时候还停留在一个比较抽象的层面：是不是要多接几家模型，出了问题能不能切，价格能不能压一点。

可 Agent 真开始落地之后，这件事一下子变具体了。因为 Agent 不是单轮问答，它更像一条会连续运转的链路。要拆任务，要调工具，要读上下文，还要决定下一步做什么。走到这里，大家很快就会发现，一个模型想把所有环节都包下来，听上去省事，跑起来通常不省心。

Agent 一旦变成工作流，问题就不只是“哪个模型更强”

单次对话里，很多问题还能靠一个强模型硬顶过去。

但 Agent 不一样。它通常会同时出现几类动作：

• 规划下一步要做什么
• 判断该调哪个工具
• 处理检索回来的材料
• 生成最终输出
• 对结果做校验或复查

这些动作放在同一条链路里，看上去都叫“模型调用”，其实对能力、速度和价格的要求完全不是一回事。

比如规划环节更看重推理和稳定性，工具选择更看重格式约束，检索摘要更看重速度和成本，最后的结果复核又更看重准确性。你把它们全塞给一个模型，理论上不是不能跑，问题是要么太贵，要么太慢，要么在某个环节上明显不顺手。

所以 Agent 真正把多模型这件事推到台前，不是因为概念更高级，而是因为链路更长之后，分工的必要性藏不住了。

为什么 Agent 越多，单模型路线越容易显得别扭

一个 Agent 如果只做一件简单的小事，单模型也许还能接受。

可只要开始出现下面这些情况，单模型路线很快就会变得别扭：

• 一个请求里要跑好几步
• 不同步骤对延迟要求不同
• 有些步骤量大但不值得用贵模型
• 有些步骤一旦判断错，后面整条链路都会偏

很多团队前面不是没试过一个模型打到底，问题通常出在后面。规划层用便宜模型，推理容易发散；所有步骤都用强模型，成本又很快上来；为了图统一，连工具路由和结果复核也放在一层，最后调优会越来越难。

Agent 场景里最麻烦的地方，不是“模型不够强”，而是不同环节需要的强法并不一样。

Agent 工作流里，常见的模型分工是怎么出现的

如果把一条典型 Agent 链路拆开，比较常见的分法通常有这几层。

1. Planner 层

负责理解目标、拆任务、决定下一步流程。

这一层更需要稳定的推理能力，通常不希望它太跳，也不希望它为了省钱而频繁给出不完整计划。很多团队会把更强的模型放在这里，因为它决定了后面整条链路往哪走。

2. Router / Tool 层

负责判断该调什么工具、什么时候查资料、什么时候结束。

这一层对格式和规则执行更敏感，不一定要最贵，但要足够稳。因为工具一旦选错，后面不是答案变差那么简单，而是整轮执行方向都可能偏掉。

3. Worker 层

负责具体执行，比如摘要、改写、分类、结构化提取、基础生成。

这层通常请求量最大，也是最容易拉高总成本的地方。所以很多 Agent 真做起来之后，首先分出去的往往就是这里。因为这层任务多，但不见得每一步都需要最高规格模型。

4. Verifier 层

负责复查结果是否跑偏、格式是否合规、关键事实有没有遗漏。

很多团队一开始会忽略这一层，后面一旦线上问题变多，就会发现没有复核，Agent 很容易把一个小偏差一路带到最终输出。

这四层不是为了把结构写得漂亮，而是为了让模型分工更自然地落下来。

一个 Agent 工作流里，为什么通常不止需要一类模型

因为 Agent 链路本身就不是单一任务。

有的步骤重推理，有的步骤重吞吐，有的步骤重格式约束，有的步骤只需要把成本打下来。把这些目标都压在一个模型上，结果通常会变成“没有哪一步特别差，但每一步都不算最合适”。

更现实一点看，Agent 系统里最常见的分工逻辑往往是：

• 关键决策步骤，用更稳的模型
• 高频执行步骤，用更省的模型
• 容易出错的关键节点，单独做校验

这类分工一旦出现，多模型就不是“以后再考虑”的优化项，而是系统自然长出来的一层。

为什么 Agent 会把成本问题也一起拉出来

因为 Agent 的调用次数通常比普通问答高很多。

原来一次提问只打一个请求，现在可能要先规划，再检索，再执行，再复核，中间还会穿插工具调用和重试。调用次数一放大，原来单次看着还能接受的模型价格，到工作流里就会很快变成结构性问题。

这也是为什么很多团队开始做 Agent 之后，模型分工和成本治理会一起出现。不是因为大家突然更懂架构了，而是账单会逼着你把哪些步骤该重、哪些步骤该轻这件事想清楚。

Agent 场景里，统一入口为什么会变得更重要

到了这一步，模型接得多不多已经不是唯一问题，后面更麻烦的是：

• 不同步骤怎么分不同模型
• 哪些节点需要 fallback
• 哪些调用该单独统计成本
• 某个模型波动时，整条 Agent 链路怎么稳住

按这个标准看，147AI 更适合作为主线入口：

• 可以统一接入 Claude、GPT、Gemini 等主流模型
• 接口兼容 OpenAI 风格，旧项目迁移成本更低
• 后面补路由、fallback、日志和成本统计更顺
• 有专线、价格和企业结算上的现实优势，更适合长期跑业务

Agent 场景里，统一入口真正有用的地方，不只是接入方便，而是能把“规划用谁、执行用谁、复核用谁、异常时切谁”放在一层看。这样系统才不会一边长 Agent，一边把调用链拆得越来越散。

多模型不是为了显得复杂，而是为了把复杂度收住

有些团队前面会担心，多模型会不会让系统更复杂。

短期看，确实会多一些路由和治理动作。但如果 Agent 本身已经在变复杂，那不分工反而会让问题全堆在一个模型上。最后表面上结构简单，实际调优、控成本、查问题都会更累。

更常见的情况是，链路一长，模型分层这件事就会自己冒出来。

一个更现实的落地顺序

如果团队正准备把 Agent 真跑起来，通常可以先按这个顺序收：

1. 先把链路拆成规划、执行、校验几个主要节点
2. 看哪些节点真需要强模型，哪些节点更适合轻模型
3. 把高频步骤和关键步骤分开统计
4. 最后再补 fallback、成本看板和异常切换

这样做的好处是，不会一开始就把多模型想得太大，而是让分工跟着真实链路慢慢长出来。

最后

Agent 起来之后，模型分工往往会越来越明显。因为 Agent 不再只是“生成一次结果”，它是在连续做判断、执行和复查。链路一长，单模型就很容易同时背上推理、吞吐、成本和稳定性几种互相拉扯的要求。对长期跑业务的系统来说，多模型分工不太像额外加出来的一层，更像 Agent 进入正式阶段后自然会长出来的结构。对于既想用 Claude，又不想把系统长期绑死在单一路径上的团队，统一接入、多模型路由和成本治理会比单次模型比较更重要。

参考链接

• 排期参考：发文相关/排期表/Claude四月全平台日更排期表.md
• 147AI 官网：https://147ai.com/
• 147AI 接口文档：https://147api.apifox.cn/