核验清单
- ✓采购国内大模型API商业版/企业版套餐时，是否问清楚了服务协议或商务合同里，"响应时长"和"解决时长"是不是两个分开写的独立条款，而不是想当然地认为写了响应时长就等于承诺了解决时长
- ✓合同或协议里对"解决时长"是否有任何量化承诺（比如具体分钟/小时数），还是只写了"尽力而为""视问题复杂程度而定"这类不作绝对承诺的表述
- ✓自己团队的业务应急预案里，降级方案的触发时间窗口是不是直接套用了厂商的"响应时长"数字来估算，而不是按"响应时长只是客服开始处理的时间起点"这个事实重新核算
- ✓是否已经独立准备了不依赖厂商解决时效的降级方案（比如切换备用厂商API、降级到本地部署的模型），而不是假设厂商能在响应时长内就把批量报错问题彻底解决
- ✓提交工单时是否记录了报错的具体时间段、请求样本和错误码，方便后续核对厂商实际处理耗时与自己应急预案假设之间的差距，为下次调整预案窗口留存依据
1. "响应时长"和"解决时长"，服务协议里最容易被混为一谈的两个词
国内大模型厂商的企业级技术支持服务协议里，通常会明确写出工单的"响应时限"（也叫首次响应时间），指的是客服或技术支持工程师接到工单后，通过电话、工单系统或专属服务群第一次联系用户、确认问题现象的时间承诺；这是一个流程性的时间指标，衡量的是"厂商有没有及时理你"，而不是"问题有没有被解决"。而真正让业务恢复正常调用的，是排查定位、修复或规避故障的"解决时长"（有的厂商内部也叫"处理时限"或"抢修时限"），这一段时间受问题本身的技术复杂度、影响范围、是否需要跨团队协作等因素影响，波动幅度远大于响应时长，很多厂商在服务协议或帮助文档里也明确说明不对处理完成时间作绝对承诺。这两个词字面上都带着"处理工单"的意思，很容易被当成一回事，但在服务协议的实际条款里，它们是两条独立甚至可能完全没有对应关系的时间线。
2. 批量调用报错提工单后，厂商的动作实际分两段：先响应，后处理
企业批量调用API的场景下，某个时间段内大量请求集中返回500错误或超时是比较典型的故障表现，提交工单说明报错时间段、请求样本、错误码之后，厂商这边的处理流程通常分两个阶段：第一阶段是响应，客服或值班工程师核实工单信息、确认故障现象、给出初步反馈，这一步对应服务协议里写明的响应时限；第二阶段才是真正的故障排查与修复，可能涉及查看后端服务状态、扩容、切换节点、代码修复等具体动作，这一步没有统一的完成时间，同一家厂商在不同故障场景下花费的实际处理时间可能差出好几倍。企业提交工单后，收到"已收到您的工单，正在处理"这类首次回复，只代表第一阶段完成，不代表问题已经进入即将解决的倒计时，这中间的落差正是容易被忽略的地方。
3. 应急预案最常踩的坑：把"响应时长"当成"预计恢复时长"来估算降级窗口
不少企业在制定业务应急预案时，会参考厂商合同里写明的响应时长数字，直接当成"故障最多持续这么久"的预估依据，比如看到合同写"2小时内响应"，就在应急预案里假设"最多2小时业务就能恢复正常调用"，据此设定降级方案的触发窗口或者干脆不设降级方案、单纯等厂商处理。一旦实际故障的排查和修复时间大幅超出这个预期——比如响应时长确实在2小时内兑现了，但故障本身用了6小时才彻底解决——原本按2小时窗口设计的应急节奏就会被打乱：该切换备用方案的时间点早就过了，团队却还在等厂商的处理结果，业务持续中断的时间比预案里设想的长得多，造成的影响也随之放大。这个坑的根源就是把两个不同定义的时间概念划了等号。
4. 采购套餐时该问清楚的两件事：响应时长有没有条款，解决时长有没有量化承诺
企业在采购国内大模型API的商业版/企业版技术支持套餐前，建议直接向销售或技术支持团队问清楚两件具体的事：第一，服务协议或商务合同里对工单响应时长是否有明确的量化条款（比如按问题严重级别分别写明多少分钟或小时内响应），这部分通常各厂商都会给出具体数字；第二，对解决时长（即问题实际修复、服务恢复正常调用）是否有任何量化承诺，还是仅以"尽力而为""视具体情况而定"这类不作绝对时限承诺的表述处理——目前没有搜到国内主流厂商对解决时长有统一的公开量化标准，这方面因厂商、因套餐等级而异，需要以自己实际采购时拿到的服务协议原文条款为准，不要凭印象套用其他产品线或其他厂商的经验数字。
5. 自己的应急预案该怎么写：不假设厂商能在响应时长内解决问题
更稳妥的做法是，企业自己的业务应急预案不应该建立在"厂商会在响应时长内把问题解决"这个假设之上，而应该把响应时长单纯理解为"厂商开始处理的时间点"，据此独立准备好不依赖厂商解决时效的降级方案——比如提前配置好备用厂商的API作为容灾切换对象、或者准备一套可以临时顶上的本地部署模型，一旦批量报错的故障持续超过团队能接受的业务影响时间，就按照自己的判断触发降级，而不是被动地一直等厂商给出"已解决"的通知。同时，提交工单时把报错时间段、请求样本、错误码这些信息记录清楚，也方便日后核对厂商实际处理耗时和自己预案假设之间的差距，用真实数据反过来校准下一次应急预案的时间窗口设定，而不是继续凭感觉估算。