工程团队评估一个模型能不能进流程，卡点往往不在「它聪不聪明」，而在几件很具体的事：接口兼容不兼容现有 SDK、结构化输出稳不稳、长流程里多轮调用会不会掉链子、并发和延迟在真实链路上什么样。这篇不讲榜单，只给一套从接口到编排、从验收到回退的核对顺序，每一步都告诉你去站内哪一页拿当时的数字，以及什么情况下这套判断不成立。
工程团队评估一个模型能不能进流程，卡点往往不在「它聪不聪明」，而在几件很具体的事：接口兼容不兼容现有 SDK、结构化输出稳不稳、长流程里多轮调用会不会掉链子、并发和延迟在真实链路上什么样。这篇不讲榜单，只给一套从接口到编排、从验收到回退的核对顺序。
每一步都告诉你去站内哪一页拿当时的数字，以及什么情况下这套判断不成立。评估之前先把目标定清楚：你是要替换现有某个环节，还是要把一整套编排搬到它上面跑，两种目标的验收重点完全不一样。
先看接口层：能不能直接塞进现有调用栈
接口层是成本最低也最容易踩坑的一步。如果你的现有调用栈已经封装好了某套 SDK，先别写业务代码，做一次最小透传：只把请求原样发出去、把返回原样打出来，看看参数名、流式返回和错误结构能不能对上。任何兼容都是「看着像」，实际差异要靠这层才能暴露。
- 调用口径
- 是否提供与主流 SDK 一致的请求字段、鉴权头和返回结构；到 /official-api/providers/deepseek 看当时列出的接入方式
- 流式返回
- 逐块返回的边界条件、结束标记、异常中断时的表现，必须单独跑一遍而不是只看文档
- 错误码体系
- 限流、超时、内容拦截分别返回什么，决定了你的重试逻辑能不能照搬
- 默认超时与重试
- 兼容层常常偷偷帮你重试，长流程里这会放大成本和延迟，要确认清楚
- 先写一个只做透传的最小客户端，跑通再动业务代码
- 把实际返回和文档描述逐字段对上，别只信文档
- 单独测限流和高并发下错误返回的形状
- 确认超时和重试语义后，再决定在哪一层做兜底
结构化输出与函数调用：编排里最容易翻车的一环
编排最怕的不是模型答错，而是模型答得「差不多对」但下游解析不了。结构化输出的判据是稳定率而不是单次成功率：同一个 schema，换不同措辞的输入提示，连跑一批，看有多大比例能直接过解析器。单条演示里几乎看不出问题，一上批量就原形毕露。
| 掉队现象 | 表现 | 排查动作 |
|---|---|---|
| 字段漏填 | 必填项偶尔缺一个 | 统计缺失字段的分布，看是不是集中在某类输入 |
| 类型漂移 | 数字变字符串、布尔变文本 | schema 里显式声明类型，并在解析层做一次强制校验 |
| 包裹文字 | JSON 外面多一层解释 | 在提示里明确只输出 JSON，并在解析前做剥离 |
| 长 schema 截断 | 字段多的时候后半段缺失 | 把 schema 拆小，或分批返回后本地合并 |
批量校验的思路很简单：准备一批覆盖典型边界的输入，跑完之后统计「一次通过解析」的比例，而不是看「有没有成功过」。站内 /tools/quality-check 这类工具的思路可以做本地化改造。什么情况下可以放宽：如果你的下游本来就有人工确认环节，没必要为了接近百分之百的合规去堆重试次数，重试本身会拉高延迟。
长流程表现：多轮调用、上下文管理与中断恢复
长流程要盯三件事：多轮里上下文怎么裁剪、单步失败后能不能只重跑那一步、流程跑到一半换模型会不会前后不一致。前两件是稳定性问题，第三件是版本管理问题，很多团队上线后才被第三件坑到。
- 加步骤级日志把每次调用的输入摘要、耗时、返回标记落盘，出问题时能顺着步骤回放，而不是只看最终输出
- 量延迟基线先用 /tools/speed-test 量出单步延迟基线，再判断是模型慢还是链路慢
- 做单步重跑把流程拆成可独立重放的步骤，失败时只重跑那一步，避免整条链重来
- 锁住模型标识在流程里写死当前使用的模型标识，别用浮动别名，版本与别名的对应关系到 /models 和 /ai-status 核对
| 流程特征 | 是否需要这套 | 原因 |
|---|---|---|
| 步骤少、无状态串联 | 不需要 | 单次成功就够了，上重放机制是过度设计 |
| 跨步骤共享状态 | 需要 | 中间状态丢失后无法重建，必须能回放 |
| 需要回溯重放 | 需要 | 没有步骤级日志就无法定位失败点 |
| 离线批处理 | 部分需要 | 重点放在总吞吐和单位成本，而非首 token |
延迟、并发与成本口径：按你自己的链路算，不看宣传值
延迟要分三项测：首 token 时间、单步总耗时、并发下的吞吐衰减。这三项对不同场景的权重完全不同，所以别用一个笼统的「快不快」下结论。用 /tools/speed-test 建基线，再拿 /tools/model-cost-calculator 和 /tools/token-price-calculator 把单位成本折算到你这套流程的单次执行上，去核对当时的数字。
- 并发从小往大压，找到延迟开始明显抬头的那个点
- 把那个点对照 /usage 里别人的真实用量，判断自己的量级是否合理
- 成本按单次流程执行折算，而不是按单次调用折算
- 首 token 时间在离线批处理里几乎没有参考意义，可以忽略
不适用的情况：如果流程是离线批处理，你只需要看总吞吐和单位成本；如果流程是交互式的，首 token 时间往往比总耗时更影响体验。同一个模型，两种链路的结论可能完全相反，所以评估前先明确你的链路类型。
验收清单与回退方案：上线前必须留下的几条记录
上线前留档四样东西：评估用的任务集与判定标准、当前锁定的模型标识、失败样本的原始请求、回退到旧方案的触发条件。这四样缺一样，出问题时都会变成扯皮。版本与别名的对应关系可以到 /models 和 /ai-status 核对当时的记录。
- 任务集和判定标准：谁写的、覆盖哪些边界、后期怎么更新
- 锁定的模型标识：写死在配置里，不依赖浮动别名
- 失败样本原始请求：能复现，能重跑，能对比
- 回退触发条件：连续多少条解析失败、单步延迟超过基线多少倍、错误率到什么水位
| 留档项 | 记录什么 | 什么时候用 |
|---|---|---|
| 评估任务集 | 输入样本 + 判定标准 | 回退前对比新旧方案 |
| 模型标识 | 当前锁定的具体标识 | 排查前后不一致时 |
| 失败样本 | 原始请求 + 返回 | 复现和定位问题时 |
| 回退条件 | 量化触发阈值 | 自动或手动切换时 |
常见问题
DeepSeek 能不能直接替换掉我流程里现在用的模型？
接口层兼容只是前提，真正决定能不能换的是结构化输出稳定率和长流程下的表现。建议先用你现成的任务集跑一遍批量验收，重点看解析失败比例和多轮一致性，再决定是否切换。具体接入口径到站内模型的官方价格与规格页核对。
流程里调模型，怎么估并发要开多大？
从低并发往上压，记录每个档位的延迟和失败率，找到延迟明显抬头的拐点作为上限，不要按宣传的峰值去配。同时用成本计算器把并发折算成单位成本，确认加并发带来的收益覆盖得住费用增长。
评估重点应该放在模型能力还是工程集成上？
如果你的流程已经有稳定的编排层，重点放在工程侧：结构化输出、重试语义、版本锁定和回退方案，这几项出问题比模型答得不好更致命。只有在流程本身就简单、纯粹靠模型质量吃饭的情况下，才把大部分精力放在能力评测上。
