小林的投屏求助已经能在演示循环里走完“追问—查指引—回答”。试点时，团队却遇到一个常见变化：同一套服务台，有些请求需要较强的理解能力，有些只需完成简单分类；某个模型接口维护时，还需要切换到备用服务。如果业务代码里到处都是某家模型的请求字段、消息格式和错误码，更换模型就会牵动工具、页面与测试。本篇继续这个故事，把模型调用收束到一个可替换的适配层。适配层不是为了把所有模型“抹成完全一样”，而是给业务循环提供稳定、可验证的最小契约：发送任务上下文，得到候选决策或失败原因。它不拥有工单权限，也不直接执行工具。文中使用演示传输层，不连接真实模型；真实接入时应按所选服务的当前接口文档实现并测试。文章目录小林的任务为什么会遇到模型切换画出模型与业务程序的边界定义稳定而克制的输入输出适配器需要把错误说清楚如何验证“可替换”不是一句口号总结小林的任务为什么会遇到模型切换假设服务台白天的常见问题由一个低成本模型处理，复杂的多轮求助才转到更强的模型。某天上午，低成本模型响应变慢。运营同事希望新会话能切到备用模型，同时已进行到“等待小林补充连接方式”的任务不丢失。这个要求意味着业务状态不能藏在某个厂商专有的对话对象里，更不能把工单创建权交给模型接口。变化来源如果没有适配层期望的业务表现模型请求格式变化循环代码到处修改字段只调整对应适配器主模型超时对话卡住，员工无反馈返回可识别的超时状态，按策略降级模型返回无效结构把错误文本当动作执行拒绝候选动作，记录错误并有限重试切换备用模型上下文和状态迁移困难复用服务端任务卡，重建标准请求计量字段不同难以比较成本统一记录可取得的使用量，缺失则标明未知这里有一个关键取舍：适配层不应为了“统一”而悄悄改变业务语义。比如一个接口支持结构化响应，