Simon Willison 于 2026 年 4 月 29 日发布 LLM 0.32a0，这是其 LLM Python 库和 CLI 工具的 alpha 版本。此次更新不是稳定版正式发布，作者也明确把它放在插件升级和真实环境验证前的测试阶段。

这次变化的核心，不是 LLM 框架突然获得了新的模型能力，而是它承认了一件现实：今天的模型接口早已不只是“给一段 prompt，收一段 response”。推理文本、工具调用、工具参数、结构化输出、多模态内容已经混在一次请求和一次流式返回里，旧抽象开始捉襟见肘。

LLM 0.32a0 把 prompt 改造成 messages，旧 API 仍然能跑

过去的 LLM 以 model.prompt("Capital of France?") 为典型用法，适合 2023 年前后以文本问答为主的模型生态。问题是，OpenAI Chat Completions API 及其后来者早就把输入组织成 messages：user、assistant 轮流出现，调用方每次把历史对话重新交给模型。

LLM 0.32a0 新增 messages 序列，并提供 llm.user()、llm.assistant() 构造历史对话。例如开发者可以直接传入 user 问法国首都、assistant 回答 Paris、user 再问 Germany 的完整上下文。旧的 prompt= 参数没有被废掉，会在内部转换成单条消息，这也是这次重构最关键的工程判断：改底层模型，不砸上层用法。

项目0.32a0 前0.32a0 alpha对开发者的影响
输入抽象单个 prompt 为主messages=[] 表达多轮历史更容易模拟 OpenAI 风格聊天 API
兼容性依赖旧 prompt= 用法prompt= 继续可用并转成单条消息现有代码迁移压力较小
对话恢复CLI 依赖 SQLite 机制较多可由调用方自行序列化和恢复不必把存储层绑定在 SQLite 上

这个设计对做多模型接入层的工程师更有用。很多团队会在 OpenAI、Anthropic、本地模型和第三方推理服务之间切换，最麻烦的不是“发请求”，而是把不同厂商的会话格式压成统一结构。LLM 这次补的正是这一层。

typed parts 流式输出解决了“模型不只吐文本”的问题

输出侧变化更能说明行业背景。LLM 0.32a0 新增 response.stream_events() 和异步版本 response.astream_events()，把返回内容拆成不同类型事件处理，例如 text、reasoning、tool_call_name、tool_call_args 等。

这和传统流式文本有本质差别。过去遍历 response 只是连续拿文本 chunk；现在一次响应里可能先出现 reasoning，再出现正文，再出现工具调用名和 JSON 参数。Anthropic 的 Claude 系列会返回推理相关内容，OpenAI 和 Anthropic 也都提供服务器侧工具能力，比如 code interpreter、web search。这些不是 LLM 新发明的能力，而是它的封装层终于能更贴近这些能力。

CLI 的可见变化反而很小：reasoning 可以用不同颜色显示，并输出到 stderr，避免污染管道结果；新增 -R/--no-reasoning 用于关闭推理 token 展示。对命令行用户来说，这是少数能直接感知的变化；对插件作者来说，真正的工作在于把各家模型返回的复杂事件映射到 LLM 的 typed parts。

插件生态要跟上，SQLite 日志重构才是下一道坎

0.32a0 还加入 response.to_dict() 和 Response.from_dict()。这允许 Python API 用户把响应转换成 JSON 风格字典，存到自己选择的位置，再恢复成 Response。这个点容易被忽略，但它减少了对固定 SQLite 存储的依赖。

限制也在这里。Willison 在原文中说，当前 SQLite 持久化对复杂对话并不够灵活，下一步可能要把日志系统改成更细粒度的结构，甚至用图来表达不断扩展、重复提交的会话。稳定版 0.32 是否包含这项工作仍未确定，也取决于 alpha 测试中是否暴露设计问题。

对使用 LLM Python 库和 CLI 的开发者，现实建议很简单：现有脚本不必急着改，旧 API 仍工作；如果你维护插件、做聊天 API 兼容层，或需要记录工具调用和推理过程，就该开始看 0.32a0 的新事件模型。它还不是生产稳定版，真正要观察的是插件升级速度、跨模型事件映射是否一致，以及新的序列化机制能否承受真实项目里的恢复、审计和日志需求。