LLM 0.32a0 重大重构：消息序列与流式类型化响应全面解析

Simon Willison 刚刚发布了 LLM 0.32a0 alpha 版本，这是他维护的 LLM Python 库和 CLI 工具的一次重大但向后兼容的重构。这次更新从根本上重新设计了模型交互的抽象方式，以适应当今前沿模型日益复杂的输入输出需求。

为什么 LLM 库需要这次重构

LLM 库始于 2023 年 4 月，最初的设计非常简洁：发送文本提示，获取文本响应。这在当时完全够用，但两年多来，大语言模型的能力已经发生了翻天覆地的变化。

Simon Willison 是 Django 框架的联合创始人，也是 Datasette（一个用于探索和发布数据的开源工具）的作者。LLM 库延续了他一贯的设计哲学：通过简洁的 CLI 和 Python API 降低技术门槛。该库的插件系统允许社区为不同的模型提供商（OpenAI、Anthropic、Google、本地运行的 Ollama/llama.cpp 等）编写适配器，用户无需修改代码即可切换底层模型。这种架构类似于数据库领域的 ORM——提供统一接口，屏蔽底层差异。

LLM 通过这套插件系统支持数千种不同模型的抽象访问。随着时间推移，它陆续增加了处理图像、音频和视频输入的 attachments，输出结构化 JSON 的 schemas，以及执行工具调用的 tools 功能。话说回来，LLM 模型本身也在不断进化——推理能力、图像生成、多模态输出等新特性层出不穷。

原有的「文本输入→文本输出」抽象已经无法承载这些复杂场景。0.32a0 带来了两个核心变化：输入可以表示为消息序列，输出可以由不同类型的流式部分组成。

核心变化一：消息序列式提示

旧模式的局限性

在 0.32 之前，LLM 通过 conversation 对象来管理多轮对话：

conversation = model.conversation()
r1 = conversation.prompt("Capital of France?")
r2 = conversation.prompt("Germany?")

这种方式在从零构建对话时可以工作，但无法从外部注入一段已有的对话历史。这使得构建 OpenAI 兼容的 chat completions API 等任务变得异常困难。虽然 CLI 工具通过 SQLite 持久化机制做了变通，但这从未成为稳定的 Python API 的一部分。

新的消息构建方式

新版本引入了 user() 和 assistant() 构建函数，允许开发者直接构造消息序列：

from llm import user, assistant

response = model.prompt(messages=[
    user("Capital of France?"),
    assistant("Paris"),
    user("Germany?"),
])

这种设计直接对齐了 OpenAI Chat Completions API 的消息格式。OpenAI 在 2023 年 3 月推出的这一 API 定义了一种消息角色模型，每条消息都带有 role 字段（system、user、assistant、tool），形成一个有序的消息数组。这种格式已经成为事实上的行业标准，Anthropic、Google、Mistral 等厂商的 API 都采用了类似的消息序列结构。LLM 0.32a0 的 user() 和 assistant() 构建函数正是对这一范式的直接映射，使得开发者可以将从任何来源（数据库、文件、其他 API）获取的对话历史直接注入模型调用，而不必通过库内部的 conversation 对象逐条重放。原有的 prompt= 参数仍然有效，LLM 会在后台将其自动升级为单条消息数组。

此外，新版本还支持通过 response.reply() 直接回复一个响应，提供了构建多轮对话的便捷方式：

response2 = response.reply("How about Hungary?")

核心变化二：流式类型化部分

多类型混合输出带来的挑战

现代大语言模型的响应已经不再是纯文本流。一次 Claude 的调用可能依次返回推理输出、文本内容、JSON 格式的工具调用请求，然后又是更多文本。OpenAI 的代码解释器、Anthropic 的网页搜索等服务端工具意味着结果可以混合文本、工具调用、工具输出等多种格式。多模态输出模型甚至可以在流式响应中穿插图像或音频片段。

要理解这一挑战的技术背景，需要了解两个关键概念。首先是流式响应（streaming）：模型在生成过程中逐 token 返回结果，而非等待完整响应后一次性返回，这通常通过 HTTP 的 Server-Sent Events（SSE）协议实现。其次是服务端工具（server-side tools），这是近一年来各大模型厂商推出的重要特性——Anthropic 的 Claude 支持网页搜索和代码执行，OpenAI 的 Assistants API 提供代码解释器和文件检索。与客户端工具调用不同，服务端工具的执行发生在模型提供商的基础设施上，响应中会混合模型生成的文本和工具执行的结果，这正是 LLM 需要类型化事件流的直接原因。

与此同时，推理模型（reasoning models）是 2024-2025 年大语言模型领域的另一重要趋势。OpenAI 的 o1/o3 系列、Anthropic 的 Claude 扩展思考（extended thinking）、DeepSeek-R1 等模型会在生成最终答案前进行显式的「思考」过程。部分 API 会将这些思考步骤作为单独的内容块返回，与最终回答区分开来，这进一步增加了响应流的复杂性。

stream_events 新接口详解

新版本通过 stream_events() 和 astream_events()（异步版本）提供了类型化的事件流：

for event in response.stream_events():
    if event.type == "text":
        print(event.chunk, end="")
    elif event.type == "tool_call_name":
        print(f"\nTool call: {event.chunk}(", end="")
    elif event.type == "tool_call_args":
        print(event.chunk, end="")

每个事件都带有明确的类型标识（text、tool_call_name、tool_call_args 等），开发者可以根据类型做出不同的处理逻辑。这使得 CLI 工具现在能够用不同颜色显示「思考」文本和最终响应文本。思考文本输出到 stderr 以避免影响管道操作——这是一个精妙的 Unix 哲学设计，确保管道中只传递最终有用的输出，而调试和中间过程信息通过 stderr 呈现给用户。

在工具调用方面，开发者可以在响应结束后调用 response.execute_tool_calls() 执行请求的函数，或使用 response.reply() 自动调用工具并将返回值发送回模型。

序列化与反序列化机制

针对当前 SQLite 持久化方案过于僵化的问题，0.32a0 新增了通用的序列化接口：

serializable = response.to_dict()
# 存储到任意位置
response = Response.from_dict(serializable)

返回的字典实际上是一个 TypedDict，定义在新的 llm/serialization.py 模块中。TypedDict 是 Python 3.8 引入的类型提示特性（PEP 589），它允许为字典的每个键指定预期的值类型，在保持字典灵活性的同时提供静态类型检查支持。LLM 选择 TypedDict 而非 Pydantic 模型或 dataclass 作为序列化格式，体现了对轻量级和互操作性的追求——返回的就是普通 Python 字典，可以直接用 json.dumps() 序列化，也可以存入 MongoDB、Redis、PostgreSQL 的 JSONB 列或任何支持 JSON 的存储系统。这为开发者提供了脱离 SQLite 的灵活性，可以根据项目需求自行选择存储方案。

后续计划与路线图

Simon 将这个版本作为 alpha 发布，目的是在真实环境中验证新设计的可靠性。他预计稳定版 0.32 会与 alpha 非常接近，除非测试暴露出设计缺陷。

剩余的一个重要任务是重新设计 SQLite 日志系统，以更好地捕获新抽象返回的细粒度信息。理想情况下，他希望将对话建模为图结构，以支持 chat completions API 中不断扩展和重复对话的场景，避免数据库中的重复存储。

传统的对话存储将对话视为线性的消息列表，但实际使用中对话往往是树状或图状的：用户可能从某个中间点分叉出新的对话分支（类似 ChatGPT 的「编辑并重新生成」功能），或者将同一段对话历史发送给不同模型进行对比。如果用线性列表存储，每个分支都需要完整复制之前的所有消息，造成大量数据冗余。图结构（具体来说是有向无环图 DAG）可以让多个对话分支共享公共前缀，每个节点只存储一次，通过边关系表达对话的演进路径。这种设计在 Git 的提交历史管理中有成熟的先例。这个特性可能在 0.32 或 0.33 中实现。

总结

这次重构体现了一个成熟开源项目如何在保持向后兼容的同时，从根本上升级其核心抽象。从「文本进文本出」到「消息序列进、类型化流式部分出」，LLM Python 库的新架构为应对多模态输出、工具调用、推理展示等现代大语言模型特性做好了充分准备。对于依赖 LLM 库构建 AI 应用的开发者来说，这是一次值得密切关注的重要升级。

核心要点

• LLM 0.32a0 引入消息序列式提示，支持通过 user() 和 assistant() 构建函数直接注入对话历史，解决了此前无法从外部加载已有对话的痛点
• 新增流式类型化事件机制（stream_events），支持文本、工具调用、推理输出等多种类型的混合流式响应，适应现代多模态模型的复杂输出
• 提供通用的序列化/反序列化接口（to_dict/from_dict），让开发者可以脱离 SQLite 自由选择存储方案
• 所有变更保持向后兼容，原有的 prompt= 参数和迭代式流式输出仍然有效
• 后续计划将 SQLite 日志系统重构为图结构，以高效支持对话扩展和去重存储