选模型不是排行榜游戏。在 OpenClaw 里模型要参与真实任务读上下文、调用工具、等待结果、修正计划、把最终回复发回用户。所以你不能只问哪个模型最强你应该问这个任务需要多快 能接受多少成本 需要多长上下文 工具调用稳不稳 失败后有没有 fallback先说结论模型选择是任务约束匹配可以用四个维度做第一轮选择速度 用户是否在等实时回复 成本 是否高频、批量、后台任务 上下文长度 是否要读长历史、大文件、多工具 schema 工具能力 是否要稳定调用 shell、browser、MCP、plugin tools没有全场景最优模型。只有更适合当前任务的模型。速度交互任务优先低延迟消息平台、CLI、Dashboard 交互里用户很容易感知延迟。适合低延迟模型的任务改写一句话 解释一个错误 快速分类 短命令生成 状态问答如果任务要打开浏览器、执行脚本、读文件模型本身速度只是总耗时的一部分。工具时间也要算进去。成本后台任务别默认用最贵模型定时任务、批量分析、长日志总结很容易把 token 用量放大。建议低风险分类 → 小模型 结构化提取 → 便宜但稳定的模型 复杂规划 / 代码修改 → 强模型 最终审核 → 可选强模型二次检查OpenClaw 的 usage tracking、token use 和/usage tokens可以帮你观察真实成本。上下文不是窗口越大越好大上下文很有用但也有代价请求更慢 成本更高 无关信息更多 模型更容易被噪声影响OpenClaw 的 context 文档提醒context 包括系统提示词、会话历史、工具调用结果、附件、compaction summary、tool schemas 等。所以模型窗口要和上下文工程一起看。工具能力Agent 任务的关键指标对 OpenClaw 来说工具能力比纯聊天分数更重要。要看是否支持 tool calls 工具参数是否稳定 能不能处理长 tool result 遇到工具失败是否会修正 是否容易重复调用同一个工具 是否支持需要的媒体输入同一个模型在聊天里很好不代表在工具循环里稳定。推荐选择策略可以按任务分层快速交互 低延迟模型短上下文少工具 一般助手 平衡模型常规工具适中上下文 代码 / 运维 / 浏览器自动化 强工具调用模型较长上下文较高 reasoning 批量后台 成本优先必要时强模型抽检 高风险动作 强模型 明确 approval 人工确认常见误解误解一最大上下文模型一定最好不一定。你还需要控制上下文质量。误解二便宜模型只能做简单聊天不一定。很多结构化、分类、提取任务很适合便宜模型。误解三工具能力只由 OpenClaw 决定不是。OpenClaw 提供工具协议和执行层模型本身也要会正确选择工具和填参数。最后总结模型选择是任务工程不是品牌偏好。一句话总结先看任务约束再选模型先测真实工具链路再决定默认配置。本节作业给“浏览器自动化”“日志分类”“代码修复”分别选一个模型策略。用/context list观察一次 run 的上下文压力。用/usage tokens估算一个批量任务成本。记录一个模型在工具调用中失败的具体原因。下一节预告下一节讲上下文组装文件、历史消息、指令和工具 schema 如何进入模型。参考资料OpenClaw DocsContextOpenClaw DocsModels CLIOpenClaw DocsToken use and costsOpenClaw DocsUsage tracking原文链接模型选择速度、成本、上下文长度和工具能力 | Harries Blog™