小龙虾(OpenClaw)源码分析9：模型与上下文窗口，多Provider如何统一
文章目录
做多模型系统时，最容易踩的坑之一就是：
“同名模型在不同Provider下，能力和上下文窗口并不一样”。
这层为什么复杂
因为真实场景里会混合几种输入：
- 显式
provider/model - 只给
model（provider靠推断） - model id本身还可能带
/
如果解析策略不严谨，就会出现上下文窗口误判、路由错配。
context.ts里值得关注的点
src/agents/context.ts这部分做了不少防御性处理，核心包括：
- provider/model规范化
- 配置层context window覆盖
- 运行时发现结果缓存
- 显式provider优先、隐式推断兜底
一句话：尽量在复杂输入下，给出“最保守且正确”的上下文上限。
为什么强调“保守”
上下文窗口估大了的后果，比估小了严重得多：
- 估大：请求直接爆掉或被Provider拒绝
- 估小：只是截断更多历史，体验略降
所以工程上通常宁可保守，不赌极限值。
配置覆盖的价值
代码和文档都体现了一个思想：
运行时发现很重要，但配置里的显式声明也很重要。
因为有些Provider/代理层场景下，自动发现并不稳定，
你需要人工给出可信边界，系统再按优先级应用。
一条实践建议
生产环境建议做两件事：
- 对核心模型显式配置context window
- 打开关键日志，观察实际输入token和剩余预算
别等线上超长输入失败了才回头补配置。
小结
这一篇核心：
- 多Provider统一不是“字符串拼接”那么简单
- context window决策要优先正确性和稳健性
- 配置覆盖 + 运行时发现两条腿都要走
下一篇进入插件机制，看看OpenClaw为什么能接这么多渠道，还能保持核心相对干净。
