LLM 0.37 简化模型接入并扩展多模态嵌入

LLM 0.37 把约两个月积累的功能和修复打包发布：新增模型、简化 OpenAI-compatible endpoint 配置、调整默认模型，并让 embeddings 支持区分不同二进制内容的类型。对使用命令行或 Python 接入模型的开发者，这次更新更像一次接口补齐。

另一处有意思的变化在维护方式上：面对大量 AI 辅助生成的 PR，Simon Willison 用模型协助筛选，再决定合并或自行修复。他的经验值得参考，但还不足以证明所有开源项目都能这样减轻负担。

接入模型更方便，默认选择也变了

LLM 同时是 CLI 工具和 Python 库。0.37 新增了 gpt-6.1-sol 和 gpt-6.1-terra，还加入命令 llm openai endpoint add，方便配置使用 OpenAI-compatible endpoints 的其他模型。

这里的兼容接口，可以理解为其他服务也按 OpenAI 风格提供模型调用入口。新增命令解决的是配置便利性；原文没有给出完整用法，也没有说明各家接口的兼容范围，不能据此推断所有模型都能无差别接入。

默认模型也从 gpt-5.6-luna 换成了 gpt-6-luna。作者给出的理由很直接：后者价格只有前者的一半。这个调整只影响没有自行设置默认模型的用户。

默认模型降价，是成本选择，不是质量结论。

原文没有提供具体单价，也没有比较两款模型在代码生成、推理或响应速度上的表现。已经固定模型的脚本不会因为这条默认设置说明而获得新的性能保证；依赖工具默认值的流程，则需要留意实际调用对象发生了变化。

多模态 embeddings，先要把文件类型讲清楚

这次 embeddings 支持的变化，是允许不同二进制内容具有不同的 content-type。

Embeddings 会把输入转换成便于检索、比较的向量。处理纯文本时，输入类型相对单一；面对音频、图片和视频，仅知道输入是一段二进制数据还不够，调用链需要保留它属于哪种内容的信息。

作者举出的例子是 Gemini Embedding 2，它可以为文本、音频、图片和视频生成 embeddings。LLM 的这项调整，就是为这种多模态模型补齐输入类型表达。

这里要分清工具和模型的职责：LLM 能表达不同内容类型，不代表任意 embedding 模型都能处理这些输入。原文也没有提供调用代码、文件限制或检索效果测试，因此目前能确认的是接口支持有所扩展，不能进一步判断实际效果。

AI 辅助 PR，为什么作者没有觉得难以招架

不少开源维护者抱怨 AI 辅助 PR 大量涌入。作者说，LLM 是他受影响最大的项目，但他并不觉得这构成了明显问题。

他的做法是让 Opus 5.5 或 GPT-6 Astra 帮忙分流，找出更有价值的修复。本次发布包含 12 位作者贡献的修复，几乎全部有 AI 参与；作者认为，审查负担没有预想中那么大。

更关键的是，他没有把每份 PR 都视为必须接收的代码，而是把它们看成「附带示例的 bug 报告」。有时直接合并，有时根据问题自己实现修复。

PR 的价值，可以先体现在把问题讲清楚，而不必等同于补丁值得合并。

这个视角给维护者留下了选择空间：问题复现有用，就保留问题；实现不合适，就重新写。模型在这里协助筛选，最终处理方式仍由维护者决定。

我的判断

我更看好两处务实变化：一是给多模态输入补齐类型信息，二是把外部补丁当作定位问题的材料。前者让接口能表达模型需要的信息，后者避免把「接受问题」和「接受实现」绑在一起。

但 AI 审查这部分仍是经验之谈。作者没有给出 PR 总量、筛选耗时、误判率，也没有提供人工独立审查的对照数据。「12 位贡献者」能说明协作成果，不能单独证明审查效率提高。

相比人工分流，模型协助可能值得尝试；相比直接信任 AI 生成的修复，作者保留了自行实现的环节。能否复制这种体验，还取决于维护者是否熟悉项目、问题是否容易复现，以及修复是否有可靠的验证方式。

能拿来做什么

• 使用 LLM CLI 或 Python 库维护自动化脚本时，明确设置默认模型，避免升级后实际调用对象随工具默认值变化；成本与输出质量分别验证。
• 接入提供 OpenAI-compatible endpoint 的服务时，可以查看 llm openai endpoint add 的帮助信息，再根据服务要求完成配置，原文没有给出可直接复制的完整命令。
• 构建多模态向量检索流程时，把 content-type 作为输入信息保留下来，并核实目标模型支持哪些内容类型。
• 维护开源项目时，可以让模型先整理 PR 的问题描述、复现材料和修复思路，再人工决定合并还是重写；是否节省时间，需要自己记录和比较。