团队第一次接大模型时，最容易把注意力全放在模型能力上。
但项目真的往生产环境里走，问题很快就会从"模型够不够强"变成"这套调用链能不能长期稳定跑"。很多看起来像模型问题的故障，最后都会落回到接入层、路由、缓存、fallback 和成本治理。
下面这 7 个坑，基本是工程团队最常撞上的。
1. 业务代码直接绑死模型厂商
这是最常见的技术债。
早期为了快，很多项目会在业务代码里直接写某家 SDK 的调用逻辑。这样做短期很顺，后面一旦要切模型、灰度实验、做 fallback，就会发现调用逻辑已经散到各个服务里。
更稳的思路是先抽一层 provider 或 gateway，把模型差异挡在业务层外面。
2. 单模型路线没有留切换位
单模型不是不能做，问题是很多项目把单模型写成了唯一模型。
这样一来，后面不管是价格变化、能力替换，还是高峰期线路波动，系统都很被动。尤其是在 Agent 或多任务链路里，这种绑定会很快放大。
如果项目从一开始就明确会进入生产环境，至少应该把路由和模型映射写进配置层，而不是写死在代码里。
3. 把兼容接口当成迁移细节
兼容 OpenAI API 这件事，经常被低估。
很多人只看到它能少改几行代码，但工程上它真正值钱的地方，是后续演进更轻。你想把 Claude 接进旧系统，想让老项目平滑切换，想对不同模型做灰度，这层兼容都会明显降低改造范围。
它不是一个"方便迁移的小技巧"，而是系统松耦合的一部分。
4. 只有 happy path，没有异常路径
Demo 阶段最常见的问题是代码只覆盖成功分支。
正式环境里，真正会打人的通常是这些情况：
- 某次请求超时
- 某个模型响应抖动
- 某条链路重试放大了成本
- 某个任务失败后整条工作流中断
如果没有超时、重试、熔断、fallback 和 trace，项目迟早会在峰值时段出问题。
5. 成本只看模型单价
很多团队做预算时，最爱问的是"这个模型贵不贵"。
但线上成本往往不是单价决定的，而是调用结构决定的。长上下文、重复背景、无差别重试、没有任务分层，这些都比单价更容易把账单拉高。
所以真正该看的不是某个模型的报价，而是整条调用链有没有被设计过。
6. 长上下文没有做分层和缓存
知识处理、代码辅助、复杂生成这几类任务，最容易把上下文越堆越长。
一个高频错误是把稳定背景、可复用规则和临时问题混在一起，每次请求都整段重传。这样不仅成本高，延迟也会一起上去。
更合理的做法是拆层：
- 稳定背景
- 半稳定业务上下文
- 当前请求
缓存应该优先打在前两层，而不是只盯最终 prompt。
7. 工程跑通了，交付链路没补
很多技术团队把"接口调通"当成接入完成，实际上企业环境里还差很多。
比如：
- 权限和配额怎么管
- 成本怎么分账
- 日志和审计怎么留
- SLA 怎么承接
- 供应商波动时谁来兜底
这些事情如果前面不设计，后面就会成为系统上线后的持续负担。
更稳的落地顺序
如果现在重做一遍企业大模型接入，我会先做这几件事：
- 抽统一调用层
- 把模型路由和 fallback 配进配置中心
- 接入 token、延迟、错误率和成本监控
- 给长上下文做分层和缓存
- 补齐权限、审计和交付要求
很多团队以为自己在做模型接入，实际上做的是一套会不会被未来变化打穿的系统设计。把底座搭对，后面换模型、控成本和扩业务都会轻很多。
