夜雨聆风
OpenClaw v2026.5.22 beta.1:用 /models 做一个多模型开发台
昨天我整理模型价格和上下文窗口时，有一个很明显的问题：价格表只能回答“哪个模型便宜”，但日常开发真正麻烦的是另一个问题。
我现在到底有哪些模型能用？
它们分别来自哪个 Provider？
上下文多长、输入输出怎么计费、能不能在当前环境调用？
如果这些信息散在不同控制台、文档和环境变量里，多模型开发很快就会变成手工记账。
OpenClaw v2026.5.22 beta.1 这次最值得看的点，就是它把 /models 端点放到了更新重点里。这个方向很适合做一个本地多模型开发台。
/models 解决的不是推理，而是管理先把边界说清楚：/models 不是让模型变聪明，也不是让推理速度突然起飞。
它解决的是模型管理问题。
典型场景是这样的：
1前端选择器需要展示模型列表2脚本需要知道可用模型名称3成本工具需要读取上下文和价格字段4开发者需要在多个 Provider 之间切换如果每个 Provider 都单独适配，代码会很碎。OpenAI 一套，Anthropic 一套，Google 一套，国产模型再来几套，最后你写的不是业务工具，而是 Provider 胶水。
统一 /models 的价值就在这里：把“有哪些模型”这件事先标准化。
我会优先用它做 4 个小工具。
第一，模型选择器。
前端或命令行工具启动时，请求一次 /models，把可用模型展示出来。比硬编码模型名稳，尤其适合经常切模型的开发环境。
第二，价格表导出。
如果返回结构里包含价格、上下文窗口、能力标签，就可以导出成 Markdown 或 JSON，做自己的模型速查表。
第三，Provider 健康检查。
模型能列出来，不代表一定能推理成功，但至少可以先确认配置是否加载、Key 是否存在、Provider 是否被识别。
第四，本地 Agent 的模型路由。
比如写一个简单规则：
1代码审查 -> 走高质量模型2摘要整理 -> 走低成本模型3长文档问答 -> 优先选择长上下文模型这类路由的前提，就是你得先有一份结构化模型列表。
等你要试 OpenClaw beta 版本时，我建议按这个顺序来，不要一上来就把它塞进正式工作流。
第一步，安装 beta 版，并确认版本号。
1openclaw --version第二步，配置 Provider。
API Key 建议只放本地环境变量或 .env，不要写进仓库：
1OPENAI_API_KEY=sk-xxx2ANTHROPIC_API_KEY=sk-ant-xxx第三步，调用 /models。
示例命令可以先按这种思路写：
1curl http://127.0.0.1:PORT/models这里的 PORT 以你本地实际启动端口为准。beta 工具的默认端口、返回字段、启动方式都要以官方 release 和文档为准。
第四步，把结果导出。
如果返回的是 JSON，可以先用 jq 做一次筛选：
1curl http://127.0.0.1:PORT/models | jq '.'下一步再考虑整理字段：
1curl http://127.0.0.1:PORT/models | jq '.models[] | {name, provider, context, input_price, output_price}'这段不是官方固定字段，只是说明我会优先关注哪些信息。真实字段要以 OpenClaw 当前版本返回为准。
这个坑很容易踩。
/models 很快，只说明模型列表查询快；它不代表模型推理快，更不代表所有 Provider 都稳定。
真正评估一个多模型工具，至少要分 3 层：
|
|
|
|
|---|---|---|
|
|
/models
|
|
|
|
|
|
|
|
|
|
所以这篇我不把 OpenClaw 写成“性能实测”。在没有完整跑通多 Provider 调用前，更准确的说法是：这是一个值得关注的多模型管理入口。
第一，beta 版本不要直接进生产。
v2026.5.22 beta.1 适合本地试用、写脚本、看接口设计，不适合直接接正式业务链路。
第二，API Key 不要出现在截图里。
多模型管理工具天然会碰到很多密钥。无论是 .env、配置页还是终端输出，发文章或录屏前都要先脱敏。
第三，国内网络环境要单独测。
模型列表能返回，不代表实际模型调用能稳定连通。Provider 的网络、区域、限速和账单状态都可能影响结果。
第四，不同 Provider 的字段不能硬比。
同样叫“上下文窗口”，不同模型的计费、缓存、输出限制可能完全不同。要做横评，必须统一单位和测试条件。
如果你只固定用一个模型，OpenClaw 这类工具暂时不是刚需。
但如果你有这些需求，就值得试：
-
同时用 OpenAI、Claude、Gemini、国产模型； -
想把模型列表接进自己的前端工具； -
想做一个内部模型价格表； -
想给 Agent 做简单模型路由； -
不想再手动维护一堆模型名。
模型生态越碎，统一管理层越有价值。
昨天的价格表告诉我一个结论：模型选择已经不是“哪个最强”这么简单了。今天这个 /models 方向补上的，是另一半问题：先把可用模型变成结构化数据，再谈选择和优化。
素材来源：
-
OpenClaw 官方发布说明：v2026.5.22-beta.1：https://openclaw-hub.com/blog/release-v2026.5.22-beta.1 -
OpenClaw GitHub Release：https://github.com/openclaw/openclaw/releases/tag/v2026.5.22-beta.1