LLM 0.32重构详解：消息序列与流式分片如何重塑Python LLM库

Simon Willison 发布了其 Python 库 LLM 的 0.32a0 alpha 版本，这是一次重大的向后兼容重构。这个被广泛使用的 LLM 访问工具，终于从「单一文本输入/输出」的简单模型，进化为能够表达当代前沿模型全部能力的新架构。

Simon Willison 是 Django Web 框架的联合创始人，也是数据工具 Datasette 的作者，在开源社区享有极高声誉。他开发的 LLM 库定位为一个统一的命令行工具和 Python API，让开发者通过一致的接口访问 OpenAI、Anthropic Claude、Google Gemini、本地开源模型等数十种大语言模型。该库采用插件架构，社区已贡献了上百个插件来对接不同的模型提供商。这种「一个接口，多个后端」的设计哲学，使得开发者可以在不修改业务代码的情况下自由切换底层模型，极大降低了供应商锁定风险。

为什么LLM库需要这次重构

LLM 库诞生于 2023 年 4 月，当时的世界很简单：给模型一段文本，拿回一段文本。但两年多过去，大语言模型生态发生了翻天覆地的变化。

库本身陆续增加了处理图像、音频、视频输入的 attachments 功能，输出结构化 JSON 的 schemas 功能，以及执行工具调用的 tools 功能。话说回来，模型端也在快速演进——推理能力、图像生成、音频输出等多模态能力层出不穷。2024 年 9 月 OpenAI 发布 o1 模型后，「推理模型」成为行业热点，这类模型在生成最终回复前会先进行一段内部的思维链（Chain of Thought）推理过程。Anthropic 的 Claude 随后也推出了 extended thinking 功能，DeepSeek-R1 等开源推理模型进一步推动了这一趋势。这些推理过程文本在语义上与最终回复有本质区别——它们是模型的「草稿纸」，用户可能希望以不同方式查看或隐藏它们。原有的「文本进、文本出」抽象已经无法承载这些复杂性。

这次重构的核心思路可以概括为两点：输入侧用消息序列替代单一提示词，输出侧用类型化的流式分片替代纯文本流。

消息序列：从单一提示词到灵活的多轮对话

旧模型存在哪些局限

在 0.32 之前，LLM 通过 conversation 对象来管理多轮对话。这种方式在从零构建对话时可以工作，但有一个致命缺陷：无法从外部注入一段已有的对话历史。这让诸如构建 OpenAI 兼容 API 这样的任务变得异常困难。

虽然 CLI 工具通过 SQLite 持久化对话来绕过了这个问题，但这从未成为稳定 API 的一部分，而且很多场景下开发者并不想绑定 SQLite 作为存储层。

新的消息构建器用法

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

import llm
from llm import user, assistant

model = llm.get_model("gpt-5.5")
response = model.prompt(messages=[
    user("Capital of France?"),
    assistant("Paris"),
    user("Germany?"),
])
print(response.text())

这与 OpenAI Chat Completions API 的 messages 数组在概念上完全对齐。OpenAI 在 2023 年 3 月发布 GPT-3.5-turbo 时引入了这种将对话表示为消息数组的设计，每条消息带有角色标签（system、user、assistant）。这种设计已成为行业事实标准，Anthropic、Google、Mistral 等主流模型提供商都采用了类似的消息数组格式。消息数组的优势在于它是无状态的——服务端不需要维护会话状态，每次请求都携带完整的对话上下文，这让负载均衡、重试、对话分叉等操作变得简单直接。LLM 库此前缺乏对这种模式的原生支持，意味着开发者无法轻松地将外部系统（如 Web 应用中已有的聊天记录）直接传入模型调用。如今，在 LLM 库之上构建兼容 API 变得自然而然。

原有的 prompt= 参数依然有效，LLM 会在内部将其升级为单元素的消息数组，保证向后兼容。

此外，新版还支持通过 response.reply() 直接回复一个响应，作为构建对话的替代方式，让代码更加简洁直观。

流式分片：多类型输出的统一事件流

混合输出已成为常态

当代大语言模型的输出早已不是纯文本。一次对 Claude 的调用可能依次返回：推理过程文本、正式回复文本、工具调用的 JSON 请求、工具执行结果、更多文本。OpenAI 的代码解释器、Anthropic 的网页搜索等服务端工具进一步增加了输出类型的多样性。多模态输出模型甚至能在流式响应中穿插图像和音频片段。

大语言模型的推理过程是逐 token 生成的，流式响应允许模型在生成每个 token 后立即将其发送给客户端，而非等待整个回复生成完毕。这种机制通常基于 HTTP 的 Server-Sent Events（SSE）协议实现，能显著降低用户感知的首字延迟（Time to First Token, TTFT），从数秒缩短到几百毫秒。在 LLM 库的旧架构中，流式输出被简单地视为文本片段的序列，无法区分不同语义类型的内容。而随着 Claude 的 extended thinking、OpenAI 的 function calling 等功能的普及，一次流式响应中可能交替出现推理痕迹、正式回复、工具调用指令等多种内容类型，需要一种更精细的事件模型来表达。

stream_events 接口详解

新版本将响应建模为类型化事件流。通过 response.stream_events()（同步）或 response.astream_events()（异步），开发者可以精确区分不同类型的输出片段：

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

这个设计带来了立竿见影的体验改进。CLI 工具现在可以用不同颜色显示「思考」文本和最终回复文本，且思考文本输出到 stderr，不会影响管道操作。配合更新后的 llm-anthropic 插件，Claude 的推理过程以灰色流式显示，正式回复则以常规颜色呈现——这在之前的架构下是无法实现的。

工具调用（Tool Calling / Function Calling）是让大语言模型与外部系统交互的关键机制。模型不直接执行操作，而是生成一个结构化的 JSON 请求，描述它想调用的函数名和参数。应用程序负责实际执行该函数，并将结果返回给模型，模型再基于结果继续生成回复。这种「模型请求 → 应用执行 → 结果回传」的循环是构建 AI Agent 的基础模式。一个完整的 Agent 可能需要多轮工具调用才能完成任务，例如先搜索网页、再读取文件、最后生成报告。

在工具调用方面，开发者可以在响应结束后调用 response.execute_tool_calls() 执行请求的函数，或通过 response.reply() 自动调用工具并将返回值发送回模型，形成完整的 agent 循环。LLM 0.32a0 中 response.reply() 自动执行工具调用并回传结果的设计，正是为了简化这种多轮 Agent 循环的实现。

序列化与反序列化：告别SQLite绑定

针对 SQLite 存储过于僵化的问题，0.32a0 提供了通用的序列化机制：

serializable = response.to_dict()
# 存储到任意后端：Redis、PostgreSQL、JSON 文件等
response = Response.from_dict(serializable)

返回的字典是一个定义在 llm/serialization.py 模块中的 TypedDict。TypedDict 是 Python 3.8 引入的类型注解特性（定义在 typing 模块中），它允许开发者为字典的每个键指定精确的值类型。与普通字典不同，TypedDict 在静态类型检查工具（如 mypy、Pyright）中能提供完整的类型推断和错误检测。LLM 库选择用 TypedDict 定义序列化格式，意味着开发者在使用 to_dict() 返回值时能获得 IDE 的自动补全和类型检查支持，减少运行时错误。这也体现了现代 Python 库设计中越来越重视类型安全的趋势。开发者可以自由选择存储后端，不再被 SQLite 绑定。

后续计划：图结构对话与日志重设计

这次以 alpha 形式发布，是为了在真实环境中验证设计。Simon Willison 表示，除非测试暴露出设计缺陷，稳定版 0.32 将与 alpha 非常接近。

剩余的大任务是重新设计 SQLite 日志系统，使其能捕获新抽象返回的更细粒度信息。理想情况下，他希望将对话建模为图结构，以支持 OpenAI 风格的场景——同一对话不断延伸但无需在数据库中重复存储完整历史。

传统的对话存储通常是线性的——每条消息按时间顺序排列形成一条链。但在实际应用中，对话往往是树状或图状的：用户可能从同一个节点分叉出多个不同的回复方向（类似 ChatGPT 界面中的「重新生成」功能），或者多个对话共享相同的前缀（如相同的系统提示词加不同的用户问题）。图结构存储可以通过节点引用避免重复存储共享的消息历史，既节省空间又能精确表达对话的分支关系。OpenAI 的 Responses API 就采用了类似的设计理念，通过 previous_response_id 链接响应而非重复传输完整历史。这个特性可能在 0.32 或 0.33 中落地。

小结：向后兼容的抽象升级

这次重构体现了一个优秀开源项目的演进智慧：在保持向后兼容的前提下，将抽象层提升到与行业现实相匹配的水平。消息序列和流式分片这两个核心变化，不仅解决了当前多轮对话注入和混合输出解析的痛点，更为未来多模态输出、复杂 agent 工作流等场景预留了充足的扩展空间。对于 LLM 库的插件生态来说，这是一次必要且及时的进化。