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

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

LLM 库的定位与生态背景

LLM 是一个由 Simon Willison（Django 联合创始人、Datasette 作者）维护的开源项目，定位为大语言模型的统一命令行接口和 Python 库。它的核心设计理念是通过插件系统支持任意模型后端——从 OpenAI、Anthropic 等商业 API 到本地运行的开源模型（如通过 llm-gpt4all、llm-ollama 等插件）。这种架构使得开发者可以用统一的接口切换不同模型，而不需要为每个厂商的 SDK 编写适配代码。截至 2025 年，LLM 的插件生态已覆盖数十个模型提供商，成为 AI 工具链中重要的基础设施组件。

为什么 LLM 库需要这次重构？

LLM 库最初诞生于 2023 年 4 月，当时的世界很简单：发送一段文本给模型，拿回一段文本响应。这个"文本进、文本出"的抽象在当时完全够用。

但两年多过去了，大语言模型的能力已经远超当初的设计预期。库先后增加了处理图片、音频、视频输入的 attachments，输出结构化 JSON 的 schemas，以及执行工具调用的 tools 支持。同时，大模型本身也在快速进化——推理能力、图像生成、音频输出等多模态能力层出不穷。

原有的抽象已经无法承载这些复杂性。LLM 通过插件系统支持数千种不同模型，它需要一个更灵活的底层架构来统一表达这些多样化的输入输出类型。

核心变化一：消息序列作为输入

旧模式的局限

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

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

这种方式只能从头开始构建对话，无法直接注入一段已有的对话历史。如果你想基于 LLM 库构建一个兼容 OpenAI Chat Completions API 的服务，这就成了一个棘手的问题。虽然 CLI 工具通过 SQLite 实现了对话持久化，但这从未成为稳定的 Python API 的一部分。

OpenAI Chat Completions API 范式

OpenAI 在 2023 年 3 月推出的 Chat Completions API 确立了一种行业标准的对话交互格式：请求体中包含一个 messages 数组，每条消息标注角色（system、user、assistant）和内容。这种设计将对话历史的管理权完全交给调用方，服务端本身是无状态的。这一范式被 Anthropic、Google、Mistral 等几乎所有主流厂商采纳，成为事实上的行业标准。LLM 0.32 的消息序列设计正是为了与这一范式对齐，使得基于 LLM 库构建兼容服务变得自然。

新的消息序列 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 等主流厂商的 API 范式——消息列表中包含角色标注的对话轮次。原有的 prompt= 参数仍然可用，LLM 会在底层将其自动升级为单条消息数组。

此外，新版还支持通过 response.reply() 方法直接回复一个响应，提供了另一种灵活的对话构建方式：

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

核心变化二：流式类型化响应

混合内容输出的挑战

现代大模型的输出早已不是单一的文本流。一次 Claude 的调用可能依次返回：推理过程、文本内容、JSON 格式的工具调用请求、再接着是更多文本。OpenAI 的代码解释器、Anthropic 的网页搜索等服务端工具更是让响应内容变得异常丰富。多模态输出模型甚至能在流式响应中穿插图片和音频片段。

流式响应的技术背景

流式响应（streaming）是大模型交互中的关键体验优化。由于大模型生成文本是逐 token 进行的，等待完整响应可能需要数十秒。流式输出允许客户端在生成过程中逐步接收内容，大幅降低首字节延迟（Time to First Token, TTFT）。技术上，主流厂商通常使用 Server-Sent Events（SSE）协议实现流式传输——这是一种基于 HTTP 的单向推送协议，服务端通过保持连接持续发送以 data: 为前缀的事件行。LLM 0.32 的 stream_events 接口在此基础上增加了类型标注，使得开发者不仅能逐块接收内容，还能区分每个块的语义类型——这在混合输出场景中至关重要。

stream_events 接口详解

新版 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=\"\")
    elif event.type == \"tool_call_args\":
        print(event.chunk, end=\"\")

这个机制带来的一个直观改进是：CLI 工具现在可以用不同颜色显示"思考"文本和最终响应文本，且思考内容输出到 stderr，不会影响管道传输的结果。配合更新后的 llm-anthropic 插件，Claude 模型的推理过程可以灰色显示，最终回答则以正常颜色呈现。

工具调用（Function Calling）机制

工具调用是 2023 年中期以来大模型最重要的能力扩展之一。其工作原理是：开发者在请求中声明可用的函数签名（名称、参数 JSON Schema），模型在需要外部信息或执行操作时，不直接回答，而是返回一个结构化的函数调用请求。客户端执行该函数后，将结果作为新消息回传给模型，模型再基于结果生成最终回答。这种"模型决策 → 客户端执行 → 结果回传"的循环被称为 Agentic Loop，是构建 AI Agent 的核心模式。

在 LLM 0.32 中，响应结束后可以调用 response.execute_tool_calls() 直接执行被请求的函数，或通过 response.reply() 将工具执行结果自动回传给模型，形成完整的工具调用闭环。这种设计将原本需要开发者手动编排的多步交互简化为几行代码。

序列化与反序列化：摆脱 SQLite 绑定

SQLite 在 LLM 中的历史角色

Simon Willison 是 SQLite 的坚定倡导者，他的多个项目（Datasette、sqlite-utils）都围绕 SQLite 构建。在 LLM CLI 中，SQLite 被用作对话日志的默认存储——每次交互的 prompt、响应、模型参数等都会自动记录到本地数据库文件（默认位于 ~/.local/share/io.datasette.llm/），方便后续通过 llm logs 命令检索和分析。然而，SQLite 的单文件、嵌入式特性虽然适合 CLI 场景，但对于需要分布式部署、多进程并发写入或自定义存储策略的应用场景来说就显得过于僵化。

新的通用序列化机制

针对这一问题，0.32a0 提供了一个通用的序列化机制：

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

返回的字典是一个定义在 llm/serialization.py 模块中的 TypedDict，开发者可以自由选择存储后端——无论是 Redis、PostgreSQL 还是文件系统，不再被绑定到 SQLite。这种设计遵循了"关注点分离"原则：核心库只负责数据的结构化表示，持久化策略完全由上层应用决定。

后续计划与版本路线图

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

剩余的一个大任务是重新设计 SQLite 日志系统，使其能更好地捕获新抽象返回的细粒度信息。理想方案是将对话建模为图结构（有向无环图，DAG），避免在 OpenAI 风格的对话扩展场景中产生重复数据存储。

为什么需要图结构？

传统的对话存储将对话建模为线性序列（链表结构），但在实际应用中，一段对话历史可能被分叉——例如基于同一段前文尝试不同的后续提问（类似 Git 的分支模型）。OpenAI 的 API 设计天然支持这种模式：你可以用相同的前缀消息数组加上不同的最后一条消息来创建分支。如果用线性存储，每个分支都需要重复存储完整的前缀历史，造成大量冗余。图结构则可以共享公共前缀节点，只在分叉点创建新的边，既节省存储空间又能准确表达对话的拓扑关系。这个特性可能在 0.32 或 0.33 中实现。

总结：从文本交互到多模态流式架构的跨越

这次重构体现了一个优秀开源项目的演进逻辑：当底层技术范式发生根本性变化时，抽象层必须跟着进化。LLM 0.32 从"文本进文本出"升级为"消息序列进、类型化流式部件出"，不仅适配了当前的多模态AI与工具调用场景，也为未来更复杂的模型能力预留了扩展空间。更难得的是，这一切都在保持向后兼容的前提下完成——对于依赖这个库的开发者来说，升级几乎没有迁移成本。

从更宏观的视角看，LLM 库的演进也折射出整个 AI 基础设施层的成熟过程：从最初各厂商 SDK 各自为政，到逐渐形成以消息序列、工具调用、流式输出为核心的统一交互范式。像 LLM 这样的抽象层项目，既是这一标准化趋势的受益者，也是推动者。

核心要点

• LLM 0.32a0 引入消息序列（messages）作为输入方式，允许直接注入完整对话历史，取代了此前只能从头构建对话的限制
• 新增流式类型化响应（stream_events），可精确区分文本、工具调用、推理过程等不同类型的输出内容
• 提供通用的序列化/反序列化机制（to_dict/from_dict），让开发者不再被绑定到 SQLite 存储
• CLI 工具现在能以不同颜色区分显示推理文本和最终响应，思考内容输出到 stderr 不影响管道操作
• 整个重构保持向后兼容，原有的 prompt= 参数和迭代式流式输出仍然可用