小龙虾(OpenClaw)源码分析9：模型与上下文窗口，多Provider如何统一
💡
原文中文，约1000字，阅读约需3分钟。
📝
内容提要
文章讨论了在多模型系统中如何统一不同Provider的模型能力和上下文窗口，强调保守估计上下文窗口以避免请求失败，建议在生产环境中显式配置并监控输入。总结指出，统一多Provider并非简单拼接，需兼顾正确性和稳健性。
🎯
关键要点
- 在多模型系统中，同名模型在不同Provider下的能力和上下文窗口可能不同。
- 复杂输入场景可能导致上下文窗口误判和路由错配。
- context.ts中进行了防御性处理，包括provider/model规范化和上下文窗口覆盖。
- 上下文窗口估大可能导致请求失败，而估小则仅会影响体验，因此应采取保守策略。
- 在生产环境中，建议显式配置核心模型的上下文窗口，并监控实际输入和预算。
- 多Provider的统一需要兼顾正确性和稳健性，不能简单拼接。
❓
延伸问答
在多模型系统中，为什么同名模型在不同Provider下的能力和上下文窗口会不同？
因为真实场景中会混合多种输入，解析策略不严谨可能导致上下文窗口误判和路由错配。
上下文窗口估大和估小分别会导致什么后果？
估大可能导致请求失败或被Provider拒绝，估小则会影响用户体验，截断更多历史。
在生产环境中，如何配置核心模型的上下文窗口？
建议显式配置核心模型的上下文窗口，并监控实际输入和预算。
context.ts中有哪些防御性处理措施？
包括provider/model规范化、上下文窗口覆盖和运行时结果缓存等。
多Provider的统一需要考虑哪些因素？
需要兼顾正确性和稳健性，不能简单拼接。
为什么在复杂输入下需要给出“最保守且正确”的上下文上限？
因为复杂输入可能导致误判，保守策略可以避免请求失败。
➡️
