LLM 0.32重构解析：消息序列与多模态流式事件流设计

Simon Willison 刚刚发布了其开源项目 LLM 的 0.32a0 alpha 版本，这是一次重大的向后兼容重构。这个 Python 库和 CLI 工具自 2023 年 4 月诞生以来，一直是开发者访问各类大语言模型的重要桥梁。而这次更新，标志着它的核心抽象模型从简单的"文本输入-文本输出"，进化为能够处理当代前沿模型多样化输入输出的全新架构。

Simon Willison 是 Django Web 框架的联合创始人，也是数据新闻工具 Datasette 的作者，长期活跃于开源社区。他的 LLM 项目定位为一个统一的大语言模型访问层——通过一个 CLI 命令或几行 Python 代码，开发者就能调用 OpenAI、Anthropic Claude、Google Gemini、本地 Llama 等数十种模型，而无需为每个提供商编写不同的集成代码。该项目采用插件架构，社区已贡献了覆盖数千个模型的插件生态。

为什么 LLM 库需要这次重构

两年前，LLM 库的世界观很简单：发送一段文本提示，获取一段文本回复。这在 GPT-3.5 时代完全够用。但 LLM 的发展速度远超预期——它先后加入了图像/音频/视频输入的 attachments 支持、结构化 JSON 输出的 schemas 功能、以及函数调用的 tools 能力。

另一边，前沿模型本身也在快速进化：推理能力（reasoning）、图像生成、音频片段输出、服务端工具执行……原有的"文本进、文本出"抽象已经无法承载这些多样化的交互模式。LLM 通过插件系统支持了数千个不同模型，它的核心抽象必须跟上时代。

核心变化一：消息序列取代单一文本提示

旧模式的局限性

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

新的消息构建器 API

0.32a0 引入了 llm.user() 和 llm.assistant() 两个构建函数，允许开发者直接以消息序列的方式构造提示：

from llm import user, assistant

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

这种设计直接对齐了 OpenAI Chat Completions API 的消息格式。OpenAI 的 Chat Completions API 采用消息数组作为输入格式，每条消息包含一个 role 字段（如 system、user、assistant）和 content 字段。这种格式已成为行业事实标准，Anthropic、Google、Mistral 等主要模型提供商都采用了类似的消息序列结构。LLM 库对齐这一格式意味着它可以更自然地作为这些 API 的抽象适配层，开发者可以在不同模型之间无缝切换，使得 LLM 库可以轻松地作为各类 LLM API 的后端适配层。原有的 prompt= 参数依然有效，LLM 会在内部将其升级为单条消息数组。

此外，新版还支持通过 response.reply() 直接回复一个响应，作为构建对话的替代方式，API 设计更加灵活自然。

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

混合内容输出的挑战

当代模型的输出早已不是纯文本。一次 Claude 的调用可能依次返回：推理过程（thinking）、文本内容、JSON 格式的工具调用请求、再接着更多文本。

这里值得展开说明推理模型的工作方式。推理模型（如 OpenAI 的 o1/o3 系列、Anthropic 的 Claude with extended thinking、DeepSeek-R1）在生成最终答案前会先输出一段"思考过程"（thinking tokens）。这些 token 展示了模型的逐步推理链条，类似于 Chain-of-Thought 提示技术的内化版本。区分推理 token 和最终回复 token 在实际应用中非常重要：推理过程通常不应展示给终端用户，且推理 token 的计费方式往往与输出 token 不同。

与此同时，服务端工具（server-side tools）进一步增加了响应的复杂性。服务端工具是指由模型提供商在其基础设施上执行的内置工具，如 OpenAI 的代码解释器（Code Interpreter）和文件搜索、Anthropic 的网页搜索等。与开发者自定义的函数调用（function calling）不同，这些工具的执行不需要客户端参与，但它们的调用过程和结果会穿插在响应流中。这些服务端工具会让响应中混合出现文本、工具调用、工具输出等多种格式。多模态输出模型甚至能在流式响应中穿插图像或音频片段。

stream_events 流式接口详解

新版引入了 response.stream_events() 和异步版本 response.astream_events()，将响应建模为一系列带类型标记的事件流：

for event in response.stream_events():
    if event.type == \"text\":
        print(event.chunk, end=\"\")
    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，不会影响管道操作。新增的 -R/--no-reasoning 标志可以完全抑制推理 token 的输出。

工具调用方面，开发者可以在响应结束后调用 response.execute_tool_calls() 执行请求的函数，或通过 response.reply() 自动执行工具并将结果回传给模型，实现完整的 agent 循环。Agent 循环是指模型发出工具调用请求→客户端执行工具→将结果回传给模型→模型继续生成的迭代过程，这是构建 AI Agent 的核心模式。LLM 库通过 reply() 方法将这一多步骤流程封装为简洁的 API 调用，大幅降低了构建工具增强型 Agent 的复杂度。

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

针对 LLM 当前 SQLite 持久化方案过于僵化的问题，0.32a0 提供了一套通用的序列化接口：

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

返回的字典是一个定义在 llm/serialization.py 模块中的 TypedDict，开发者可以自由选择存储后端，不再被绑定到 SQLite。

SQLite 是一个嵌入式关系数据库，以单文件形式存储数据，无需独立的数据库服务器进程。Simon Willison 是 SQLite 在开发者工具领域的积极推广者，他的 Datasette 项目就是围绕 SQLite 构建的。LLM 库使用 SQLite 记录所有对话历史和模型调用日志，这让用户可以通过 SQL 查询回溯和分析自己的 LLM 使用记录。但这种紧耦合也限制了希望使用其他存储方案（如 PostgreSQL、云存储或内存缓存）的开发者。新的序列化接口正是为了解决这一痛点，让持久化策略成为开发者的自主选择而非框架的强制约束。

未来规划与路线图

Simon 将此版本作为 alpha 发布，目的是在真实环境中验证新设计。他计划在稳定版中重新设计 SQLite 日志系统，以更细粒度地捕获新抽象返回的丰富信息。理想方案是将对话建模为图结构，避免在 chat completions 场景中反复存储重复的对话历史。

将对话建模为图结构是一个值得深入理解的设计思路。传统的对话持久化将对话视为线性的消息列表，每次 API 调用都需要发送完整的历史消息。当对话出现分支（如用户从某个中间点重新提问）或工具调用产生多条并行路径时，线性模型会导致大量重复存储。将对话建模为有向无环图（DAG）可以让多个分支共享公共的历史前缀，既节省存储空间，也能更准确地表达对话的真实拓扑结构。这与 Git 的提交历史模型有异曲同工之处——每个节点指向其父节点，分支和合并都能被自然表达。

向后兼容的渐进式重构：设计哲学启示

这次重构体现了一个优秀开源项目的演进智慧：向后兼容的渐进式重构。旧的 prompt= 参数、conversation() 模式、简单的 for chunk in response 迭代——这些都继续工作。新的消息序列和事件流是增量添加的能力，而非破坏性替换。

在 LLM 能力爆炸式增长的当下，工具层的抽象设计至关重要。LLM 库从"文本管道"进化为"多模态事件流"，本质上是在追赶模型能力的边界。这种抽象层的及时进化，决定了一个工具库能否在快速变化的 AI 生态中保持生命力。

核心要点

• LLM 0.32a0 将核心抽象从"文本输入-文本输出"升级为消息序列输入和类型化流式响应，以适应当代多模态模型的复杂交互需求
• 新增 llm.user() 和 llm.assistant() 构建函数，支持直接注入对话历史，对齐 OpenAI Chat Completions API 的消息格式
• 引入 stream_events() 事件流机制，可区分处理文本、推理过程、工具调用等不同类型的响应内容
• 提供通用的 to_dict()/from_dict() 序列化接口，解除对 SQLite 存储的强依赖
• 整体重构保持向后兼容，旧有 API 继续工作，体现了渐进式演进的设计哲学