你可能遇到过这种情况：任务听着像「让 AI 自己干」，结果接进来发现光是工具注册、循环控制、失败重试就写了一堆代码，效果还不如直接调一个领域模型。反过来，明明是固定领域的分类或抽取活儿，却硬套了 Agent 框架，成本和延迟都不划算。这篇不讨论名词定义，只给判断口径：先看任务结构、再看失败代价、最后看工程预算，三步定下来用哪种。
你可能遇到过这种情况：任务听着像「让 AI 自己干」，结果接进来发现光是工具注册、循环控制、失败重试就写了一堆代码，效果还不如直接调一个领域模型。反过来，明明是固定领域的分类或抽取活儿，却硬套了 Agent 框架，成本和延迟都不划算。这种错配不是模型选错了，而是选型口径用错了。
这篇不讨论名词定义，只给判断口径：先看任务结构、再看失败代价、最后看工程预算，三步定下来用哪种。这里的「垂类专业模型」泛指在特定领域做分类、抽取、打分、生成结构化结果的那一类模型，能力边界窄但输出面稳定；「Agent」则指能自己规划步骤、调工具、根据结果再决策的那一类。分界线不在模型名字上，而在你的任务形状上。
先看任务结构，别先看名词
第一个动作是把任务拆成两类：一类是「一次输入一次输出」，中间不需要外部状态；另一类是「多步依赖外部状态」，后一步得看前一步查回来的东西。前者垂类模型更稳，后者才轮到 Agent。判断的时候先别管用什么框架，把数据流画出来，看有没有需要落库或跨步传递的中间结果。
- 步骤数固定吗：每一步做什么、做几步，如果写需求时能一口气列完，多半不需要 Agent
- 中间结果要不要落库：如果中间产物要存下来给别的系统或下一次调用用，说明状态管理是核心，Agent 更合适
- 失败后能不能原样重跑：能原样重跑的任务，用单次调用的垂类模型加校验就够
- 反例：把「批量给文案打分」做成 Agent，多出来的循环和工具调用只是延迟，不如一次结构化输出
凡是能用一次结构化输出说清楚的任务，别先上循环；循环是用来处理依赖的，不是用来显得高级的。
再看失败代价：错一次是重跑还是赔钱
第二个动作是估错误成本。可逆场景和不可逆场景，自主权的宽度完全不一样。这里最容易犯的错是：因为任务听起来复杂就给了 Agent 完整执行权，结果一次误操作就要人工去擦屁股。判断口径很简单：一次错误的最坏后果能不能靠人工回滚；超过这条线，就别让 Agent 自己闭环。
| 场景类型 | 典型任务 | 自主权建议 | 校验方式 |
|---|---|---|---|
| 可逆 | 草稿生成、内部检索、代码建议 | 可放开多步与工具调用 | 用抽样人工复核兜底 |
| 半可逆 | 总结、标签、工单分类 | Agent 可建议，落库前需闸门 | 规则校验加抽检 |
| 不可逆 | 下单、发信、改生产数据、对外结算 | Agent 只做建议不做执行 | 人工确认或双人复核 |
最后算工程预算：多出来的是代码，不是模型
很多人做预算时只算了模型调用，实际上一上 Agent，成本立刻转移到工程侧：工具注册、鉴权、幂等、步数上限、日志与回放。垂类模型那边反而简单，成本在数据准备和输出校验，链路短，容易做离线评测。小团队尤其要注意，人力是稀缺项。
- 先算人力不是算单价问一句：上线后谁维护工具接口和日志回放。没有明确的人负责，就别先上多步循环。
- 给步数设上限无论哪边，都设一个最大步数或最大重试次数，超了直接转人工，避免跑飞。
- 日志优先级高于步数预算不够时优先砍自主步数，而不是砍日志；没日志的 Agent 出问题只能靠猜。
- 先跑单点再升级比如 5 人小团队，先用垂类模型把业务链路跑通，再考虑把其中一环升级成 Agent。
如果你不确定自己这套链路该按哪档预算配，可以先到站内的工具目录按用途筛一遍，看现成方案能覆盖到哪一步，再决定要不要自己写循环控制。
什么时候该换边：几个可观察的信号
选型不是一锤定音，关键是留好「该换边了」的信号。换边分两个方向：从垂类模型升到 Agent，以及从 Agent 退回垂类模型。两个方向都有可观察的指标，别凭感觉拍脑袋。
- 需要升到 Agent 的信号
- 任务步骤随输入变化、要读写外部系统、要边查边改，这三个里占两个就该考虑。
- 不用升的信号
- 同一套提示词加结构化输出已经覆盖大部分样本，剩下的是数据脏而不是能力不足。
- 退回垂类模型的信号
- 日志里多数失败发生在工具参数与状态衔接，而不是模型理解，说明失败源头在工程侧。
- 切换前的动作
- 先用离线用例集测一遍「多步是否真的提升了准确率」，别只在演示上判断。
各家的模型能力和上下文长度差别很大，具体到某个领域够不够，建议到站内的模型资料库对照字段要求看当时的说明，再决定要不要把它放进 Agent 的一环。
一张选型对照清单（照着填）
下面这张表就是排查顺序：先填任务形状，再填失败代价，最后填工程条件。两项以上指向 Agent 才上 Agent，否则先用垂类模型把业务跑通。
| 判断项 | 填什么 | 指向 Agent 的答案 | 指向垂类模型的答案 |
|---|---|---|---|
| 任务步骤 | 固定还是随输入变 | 随输入变 | 固定可枚举 |
| 外部状态 | 要不要读写外部系统 | 要，且要边查边改 | 不碰，或只读一次 |
| 失败代价 | 可逆还是不可逆 | 可逆或半可逆 | 不可逆，需人工闸门 |
| 工程条件 | 有没有人维护循环与日志 | 有 | 没有，先单点跑通 |
| 换边指标 | 上线后看什么 | 成功率、重试次数、人工介入比例 | 漏检率、结构化输出合规率 |
- 对照结果里两项以上指向 Agent 才上 Agent，否则先用垂类模型把业务跑通
- 上线后固定看两三个指标就够，别铺一堆仪表盘没人看
- 指标恶化先查数据与工具，再怀疑模型能力
- 换边要有离线用例集撑着，不能只靠线上感觉
如果你还拿不准具体某个中转或工具的稳定性和价格，别拍价格数字，到站内的价格追踪页与可信度检测页核对当时的数字和状态，选型结论才不会建立在一周后就过期的前提上。
下一步把你手上那个任务对着上面的对照表填一遍，两项以上指向 Agent 再动手；不确定工具与模型的现状，先去站内目录和价格页核一遍当前情况。→常见问题
垂类模型能不能做多步任务，是不是一定要上 Agent？
不一定。如果步骤固定、中间状态可以放在你自己的代码里，用垂类模型加几次串行调用就够了，比引入 Agent 框架更好排查。只有当步骤数量随输入变化、并且需要模型自己决定下一步调什么时，Agent 的编排才有价值。
Agent 一定比专业大模型贵吗？
通常更贵，但贵在哪要分清：模型调用次数只是其中一部分，工具注册、重试、日志与人工兜底往往占更大比重。反过来，垂类模型的前期数据标注和输出校验也有成本。具体单价到 /official-api 和 /tools/model-cost-calculator 按当时的数字核对。
怎么判断该换边，有没有可量化的信号？
看离线用例集上的成功率与人工介入比例：如果垂类模型已覆盖多数样本，多出来的 Agent 步数只是在补数据脏的窟窿，就不该换；如果失败集中在状态衔接和工具参数，说明瓶颈在流程而非模型，这时该加工程约束而不是换模型。
