将 tools/lmstudio/wrapper_generator.py 重构为单文件批处理工具,专用于 LM Studio 本地模型目录。
它需要扫描指定本地模型根目录中的 .gguf,读取可用元数据,跳过 lmstudio-community 相关模型,然后在 ~/.lmstudio/hub/models/<owner>/<name>/ 下生成或补全 LM Studio 可识别的普通模型包元数据,使界面和 API 更准确识别模型能力,例如:
本次工具不再局限于“复制一份官方 reasoning wrapper 并替换 base model key”。
更接近的目标是:
LM Studio 官方普通模型包结构model.yaml 与 manifest.json也就是说,qwen/qwen3.6-35b-a3b 这类官方模型包应被视为模板参考样本,不是固定默认输入;当前脚本中的:
DEFAULT_OFFICIAL_MODEL_YAMLDEFAULT_OFFICIAL_MANIFEST所体现的价值,是说明 LM Studio 官方普通模型包通常已经包含了能力声明、结构字段和模板组织方式。新工具应泛化这种思路,而不是继续绑定单一 Qwen 模型。
LM Studio 使用场景~/.lmstudio/models~/.lmstudio/hub/models 为核心~/.lmstudio/hub/models/<owner>/<name>/--dry-runlmstudio-community 模型包--models-root
~/.lmstudio/models--hub-root
LM Studio Hub 模板根目录~/.lmstudio/hub/models--output-root
~/.lmstudio/hub/models--dry-run
输出目录中的 <owner>/<name> 采用以下规则:
工具需递归扫描 --models-root 下所有 .gguf。
需要过滤或跳过:
lmstudio-community 的模型来源未处理项应出现在 --dry-run 或最终汇总中,不能静默忽略。
模板匹配以 GGUF 元数据中的架构/家族 为主,例如:
qwenllamamistral匹配逻辑应优先寻找 ~/.lmstudio/hub/models 中最接近的普通官方模型包,而不是 reasoning wrapper。
匹配结果至少需要提供:
model.yamlmanifest.json若匹配失败,应在结果中报告该模型未找到模板,不应凭空猜测完整模板内容。
能力判断遵循以下优先级:
重点补全的能力和结构包括:
reasoningvisiontoolsarchitecturescompatibilityTypescustomFieldsconfig.operation.fields规则要求:
每个识别成功的模型输出到:
~/.lmstudio/hub/models/<owner>/<name>/model.yaml~/.lmstudio/hub/models/<owner>/<name>/manifest.json可选输出:
README.mdsummary.json其中:
model.yaml 负责能力声明、元数据覆盖与模板配置manifest.json 负责 LM Studio 模型包标识、依赖和修订信息--dry-run 模式不写入任何文件,只打印汇总 JSON。
每条结果至少包含:
<owner>/<name>最低自动验证要求:
--dry-run 不落盘测试lmstudio-community 的测试手工验证要求:
~/.lmstudio/hub/models 后可被 LM Studio 识别本次不做以下事项:
.internal 状态