做多模型系统时，最容易踩的坑之一就是：
“同名模型在不同Provider下，能力和上下文窗口并不一样”。

这层为什么复杂

因为真实场景里会混合几种输入：

• 显式provider/model
• 只给model（provider靠推断）
• model id本身还可能带/

如果解析策略不严谨，就会出现上下文窗口误判、路由错配。

context.ts里值得关注的点

src/agents/context.ts这部分做了不少防御性处理，核心包括：

• provider/model规范化
• 配置层context window覆盖
• 运行时发现结果缓存
• 显式provider优先、隐式推断兜底

一句话：尽量在复杂输入下，给出“最保守且正确”的上下文上限。

为什么强调“保守”

上下文窗口估大了的后果，比估小了严重得多：

• 估大：请求直接爆掉或被Provider拒绝
• 估小：只是截断更多历史，体验略降

所以工程上通常宁可保守，不赌极限值。

配置覆盖的价值

代码和文档都体现了一个思想：
运行时发现很重要，但配置里的显式声明也很重要。

因为有些Provider/代理层场景下，自动发现并不稳定，
你需要人工给出可信边界，系统再按优先级应用。

一条实践建议

生产环境建议做两件事：

1. 对核心模型显式配置context window
2. 打开关键日志，观察实际输入token和剩余预算

别等线上超长输入失败了才回头补配置。

小结

这一篇核心：

• 多Provider统一不是“字符串拼接”那么简单
• context window决策要优先正确性和稳健性
• 配置覆盖 + 运行时发现两条腿都要走

下一篇进入插件机制，看看OpenClaw为什么能接这么多渠道，还能保持核心相对干净。

参考链接

• https://github.com/openclaw/openclaw/blob/main/src/agents/context.ts
• https://docs.openclaw.ai/concepts/models