版本表面增加模型，实质改变调用边界

Simon Willison 于 2026 年 9 月 22 日发布了 llm 0.36，这是面向多种大语言模型的命令行工具及其插件生态的一次版本更新。版本新增了 OpenAI 的 `gpt-6-sol` 和 `gpt-6-luna`，分别对应 GPT-6 Sol 与 GPT-6 Luna，同时加入了模型插件对会话能力的声明机制。它还改进了日志中推理痕迹的展示方式，并包含来自五位新贡献者的修复。

如果只看版本说明，最醒目的变化是模型列表多了两个名称。但现有材料没有提供这两个模型的能力基准、价格数据或部署差异，因此不能据此判断它们带来了模型能力跃迁。这个版本更值得技术负责人阅读的地方，是它开始处理一个长期隐藏在统一接口背后的问题：接受一次提示，不等于能够承载一段对话。

单轮模型终于有了明确的接口类型

llm 0.36 允许模型插件声明 `supports_conversation = False`。当这类模型收到助手消息历史或工具调用历史时，LLM 会抛出 `llm.ConversationNotSupported`。如果用户通过 `llm chat` 使用它，命令会在会话启动前直接拒绝，而不是先创建一个看似正常的会话，再等到第二轮请求时暴露问题。

这个机制没有给单轮模型增加任何对话能力，反而把它的限制表达得更准确。模型仍然可以处理一次性的提示与响应，但调用方不能要求它复用此前的状态，也不能默认它理解由助手消息和工具消息组成的历史。对于系统设计者来说，这相当于把一个过去依赖约定的隐藏前提，提升成了可以检查的接口属性。

llm-typesafe 暴露了统一入口的真实风险

第一个使用这一声明机制的插件是 `llm-typesafe`。材料将它描述为接入 TypeSafe 分类与评分模型的插件，而这类模型只接受单轮提示。它们的工作对象是一个待分类或评分的输入，不是需要连续维护上下文的聊天会话。把助手历史或工具历史自动拼接进去，不仅没有明显价值，还可能改变模型所期待的输入形态。

这说明，多模型工具的统一入口不能被理解为所有后端拥有同一种交互语义。插件告诉框架“我可以被调用”，并不足以说明它可以接受会话状态、工具结果或助手历史。`supports_conversation` 的价值，正是把能力声明从模型适配代码中提到框架边界上，让调用方在选择路径时知道自己是在发起单次推理，还是在创建一段真正的会话。

错误前置，改变的是失败的成本

在没有能力声明时，兼容性问题往往会沿着调用链向后传播。一次请求可能看起来已经成功，直到系统附带了助手历史或工具历史，后端才因为输入形态不受支持而失败。此时失败已经接近业务流程的中段，调用方还可能已经写入状态、消耗资源，或者让用户等待了一个不会完成的会话。

新机制把问题前移到两个位置。直接调用时，收到不支持的历史就抛出明确的 `ConversationNotSupported`，通过 `llm chat` 时则在会话启动前拒绝。它不会消除所有模型适配错误，也不能证明插件声明一定准确，但它减少了把单轮接口伪装成聊天接口的空间。对负责接入多家模型的团队而言，这种前置校验比在每个业务调用点手工判断更适合形成一致的治理规则。

日志折叠提醒团队：可观测性也需要边界

llm 0.36 的另一项变化，是 Markdown 格式日志中的 reasoning traces 现在会被包裹在 HTML 的 `<details><summary>` 标签中。推理痕迹并没有被删除，读者仍然可以展开查看，但默认阅读路径会先显示主要结果，而不是让冗长过程占据整份日志。这个改动针对的是信息呈现，不是对模型能力的重新定义。

它与会话能力声明看起来属于不同层面，实际上共享一种工具链思路。前者规定哪些状态可以进入模型请求，后者规定哪些过程信息以什么优先级进入人的视野。技术负责人不应把可观测性简单等同于记录更多内容。更可靠的做法是保留诊断所需的信息，同时明确默认暴露范围、调用前检查和失败方式。llm 0.36 的可执行判断也因此很具体：接入单轮模型时先声明能力并拒绝会话路径，使用日志时保留推理痕迹但不要让它淹没结果。