LLM 0.32重构：消息序列与流式分片如何重塑Python LLM交互

Simon Willison 刚刚发布了 LLM 0.32a0 alpha 版本，这是他维护的 LLM Python 库和 CLI 工具的一次重大但向后兼容的重构。这次更新重新定义了与大语言模型交互的核心抽象层，从简单的"提示-响应"模型演进为支持消息序列输入和类型化流式输出的现代架构。

为什么需要这次重构

2023 年 4 月 Simon 启动 LLM 项目时，"发送文本提示、获取文本响应"的抽象完全够用。但两年多过去了，LLM 生态已经发生了翻天覆地的变化。

LLM 库通过插件系统支持数千种不同模型的统一访问。这套插件架构是 LLM 库的核心竞争力之一——通过 Python 的 entry_points 机制，第三方开发者可以编写插件来接入任意模型提供商，从 OpenAI、Anthropic、Google Gemini 等商业 API，到通过 llm-gguf 插件运行的本地 GGUF 格式模型，再到 Ollama、vLLM 等本地推理框架。用户只需 pip install 对应插件，即可通过统一的 llm.get_model() 接口访问，无需关心底层 API 差异。这种设计借鉴了 Datasette（Simon 的另一个知名项目）的插件哲学：核心保持精简，通过生态扩展能力边界。

随着时间推移，LLM 库陆续增加了处理图像/音频/视频输入的 attachments 功能、输出结构化 JSON 的 schemas 功能，以及执行工具调用的 tools 功能。另一边，前沿模型不断进化——推理能力、图像生成、多模态输出层出不穷。原有的"文本进、文本出"抽象已经无法承载这些复杂场景。

这次 0.32a0 alpha 带来了两个核心变化：输入可以表示为消息序列，输出可以由不同类型的流式分片组成。

消息序列：更灵活的对话建模

旧模式的局限

此前 LLM 通过 conversation 对象来管理多轮对话，但这种方式只能从头开始构建对话，无法直接注入一段已有的对话历史。这让构建 OpenAI 兼容的 chat completions API 等场景变得异常困难。虽然 CLI 工具通过 SQLite 持久化实现了变通方案，但这从未成为稳定的 Python API 的一部分。

新的消息构建器

0.32a0 引入了 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 的消息格式。Chat Completions API 是当前 LLM 行业的事实标准接口格式，它要求输入为一个消息数组，每条消息包含 role（如 system、user、assistant、tool）和 content 字段。这种格式的关键优势在于：开发者可以通过注入 assistant 角色的历史消息来"预填充"对话上下文，实现 few-shot prompting、角色扮演、对话恢复等高级场景。Anthropic、Google、Mistral 等主流提供商也纷纷采用了兼容或类似的消息格式，使其成为跨平台互操作的基础。LLM 0.32a0 的 messages 参数直接对齐了这一行业标准，使得预填充对话历史变得轻而易举。

原有的 prompt= 参数依然有效，LLM 会在后台将其自动升级为单条消息数组。

此外，新版还支持通过 response.reply() 方法直接回复一个响应，作为构建 conversation 对象的替代方案：

response2 = response.reply(\"How about Hungary?\")
print(response2)  # 默认 __str__() 调用 .text()

流式分片：处理混合类型输出

现代模型的输出复杂性

今天的前沿大语言模型返回的内容远不止纯文本。一次 Claude 调用可能依次返回推理过程、文本内容、工具调用请求，然后又是文本。

这里涉及的推理 Token（reasoning tokens）是近年来大语言模型的重要创新，以 OpenAI 的 o1/o3 系列和 Anthropic Claude 的 extended thinking 功能为代表。这些模型在生成最终答案之前，会先产生一段"思维链"（Chain-of-Thought）推理过程，类似于人类解题时的草稿纸。推理 token 通常会消耗额外的计算资源和 API 费用，但能显著提升数学推理、代码生成、复杂逻辑等任务的准确率。在流式输出中，推理 token 和最终响应 token 是交替或分段到达的，这正是 LLM 0.32a0 引入类型化事件流的直接动因之一——需要让客户端能够区分"模型在思考"和"模型在回答"。

与此同时，工具调用（Tool Use / Function Calling）已成为 LLM 从纯文本生成器演变为智能代理（Agent）的关键能力。模型在生成过程中可以决定调用外部工具（如搜索引擎、代码解释器、数据库查询），并将工具返回的结果整合到后续生成中。这里存在两种模式：客户端工具调用（模型输出工具调用请求，由客户端执行后将结果回传）和服务端工具调用（如 OpenAI 的 Code Interpreter、Anthropic 的 Web Search，由服务端自动执行）。服务端工具的响应流中会混合文本片段、工具调用声明、工具执行结果等多种类型，这使得传统的纯文本流式输出完全无法表达响应的完整语义结构。多模态输出模型甚至能在流式响应中穿插图像或音频片段。

类型化事件流

新版 LLM 将响应建模为类型化消息分片的流。通过 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\"\
Tool call: {event.chunk}(\", end=\"\", flush=True)
    elif event.type == \"tool_call_args\":
        print(event.chunk, end=\"\", flush=True)

这种机制带来了直接的用户体验提升——CLI 工具现在可以用不同颜色显示"思考"文本和最终响应文本，且思考文本输出到 stderr，不会影响管道操作。配合更新后的 llm-anthropic 插件，Claude 模型的推理过程可以以灰色文字实时流式展示。

新增的 -R/--no-reasoning 标志可以抑制推理 token 的输出，这也是本次发布中唯一面向 CLI 用户的变化。

响应的序列化与反序列化

针对 LLM 当前将对话持久化到 SQLite 的僵化设计，0.32a0 提供了一个通用的序列化机制：

serializable = response.to_dict()
# 存储到任何你喜欢的地方
response = Response.from_dict(serializable)

Simon Willison 是 SQLite 在应用层使用的积极倡导者。在 LLM CLI 工具中，所有对话历史默认存储在本地 SQLite 数据库（通常位于 ~/.config/io.datasette.llm/ 目录下），用户可以通过 llm logs 命令查询历史对话。SQLite 作为嵌入式数据库，无需额外服务进程，非常适合 CLI 工具的单用户场景。然而，当 LLM 被用作 Python 库集成到 Web 服务或分布式系统中时，SQLite 的单写者限制和文件级锁定就成了瓶颈。

返回的字典实际上是一个在 llm/serialization.py 模块中定义的 TypedDict。TypedDict 是 Python typing 模块提供的类型注解工具，允许开发者为字典的每个键指定精确的值类型。与普通 dict 不同，TypedDict 可以被 mypy、pyright 等静态类型检查器验证，确保序列化和反序列化过程中的字段完整性和类型正确性。这意味着 IDE 可以提供自动补全、类型检查器可以在编译期捕获字段拼写错误或类型不匹配、第三方存储层的实现者有明确的契约可以遵循——比使用普通字典或 JSON schema 提供了更强的开发时保障。

这一设计意味着你不再被绑定在 SQLite 上，可以自由选择 Redis、PostgreSQL 或任何其他存储方案来持久化对话数据。

后续计划

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

剩余的一个大任务是重新设计 SQLite 日志系统，以更好地捕获新抽象返回的细粒度信息。理想方案是将其建模为图结构，以支持 chat completions API 那样不断扩展同一对话的场景，避免数据库中的重复存储。这个特性可能会在 0.32 或推迟到 0.33 中实现。

设计哲学的启示

这次重构体现了一个优秀开源项目的演进智慧：向后兼容的渐进式重构。旧的 prompt= 参数、conversation() 模式、简单的字符串迭代流式输出——这些都继续工作。但新的消息序列和类型化事件流为日益复杂的 LLM 交互场景提供了必要的表达能力。

从更宏观的视角看，LLM Python 库的抽象层演进也是整个行业发展的缩影：从简单的文本补全，到多轮对话，到工具调用，再到多模态混合输出——每一次模型能力的跃迁都在倒逼基础设施层的重新设计。LLM 0.32 的这次重构，为开发者提供了一套更贴合现实需求的交互原语，值得关注其后续稳定版的发布。

核心要点

• LLM 0.32a0 引入消息序列（messages）作为输入抽象，支持直接构造完整对话历史，解决了此前无法预填充对话的限制
• 新增类型化流式事件（stream_events），可区分文本、工具调用、推理过程等不同类型的输出分片，适配现代多模态模型的复杂响应
• 提供 response.to_dict()/from_dict() 序列化机制，让开发者可以脱离 SQLite 自行实现对话持久化
• CLI 工具现在可以用不同颜色区分显示推理文本和最终响应，推理输出到 stderr 不影响管道操作
• 所有变更向后兼容，旧的 prompt= 参数和 conversation() 模式继续工作