LLM 0.32重构：从文本问答到多模态流式交互的架构升级

Simon Willison 刚刚发布了 LLM 0.32a0 alpha 版本，这是他维护的 LLM Python 库和 CLI 工具的一次重大重构。虽然保持了向后兼容，但底层抽象模型发生了根本性变化——从简单的「文本输入-文本输出」演进为支持消息序列输入和多类型流式输出的现代架构。

Simon Willison 是 Django 框架的联合创始人，也是数据新闻和开源工具领域的知名开发者。他的 LLM 项目定位为一个统一的命令行接口和 Python 库，通过插件架构让用户能以一致的方式调用 OpenAI、Anthropic Claude、Google Gemini、本地 Llama 模型等数千种大语言模型。CLI 工具的设计哲学遵循 Unix 传统——可以通过管道与其他命令组合使用，例如 cat file.txt | llm 'summarize this'。这种设计使其成为开发者日常工作流中的瑞士军刀式工具。

为什么 LLM 库需要这次重构

回溯到 2023 年 4 月 LLM 项目启动时，大语言模型的交互模式还相对简单：发送一段文本，获取一段文本回复。这个抽象足够优雅，也足够实用。

但两年过去，LLM 生态发生了翻天覆地的变化。LLM 库先后增加了附件（attachments）支持图片、音频、视频输入，然后是 schemas 支持结构化 JSON 输出，再到 tools 支持工具调用。另一边，前沿模型不断进化——推理能力、图像生成、音频输出等多模态能力层出不穷。

原有的「文本进、文本出」抽象已经无法承载这些复杂性。LLM 作为一个通过插件系统覆盖数千种模型的抽象层，必须跟上时代。

消息序列 API：更灵活的多轮对话管理

旧模式的局限

在 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 的一部分。

新的消息序列用法

0.32a0 引入了 user() 和 assistant() 构建函数，允许直接传入消息序列：

from llm import user, assistant

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

这与 OpenAI 等主流 API 的消息格式直接对应，大幅降低了构建兼容服务的复杂度。OpenAI 在 2023 年 3 月推出的 Chat Completions API 确立了行业事实标准的消息格式：对话被建模为一个消息数组，每条消息包含 role（system/user/assistant）和 content 字段。这种格式被 Anthropic、Google、Mistral 等几乎所有主流 LLM 提供商采纳或兼容。它的优势在于无状态——每次请求都携带完整对话历史，服务端不需要维护会话状态，这对 API 服务的水平扩展至关重要。

原有的 prompt= 参数依然可用，LLM 会在内部将其升级为单条消息的数组。

此外，新版还支持对响应直接 reply，作为构建对话的替代方式：

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

类型化流式输出：处理多模态混合内容

混合内容带来的挑战

现代大语言模型的输出早已不是纯文本。一次 Claude 调用可能依次返回：推理过程、文本内容、工具调用请求、再接更多文本。OpenAI 的代码解释器、Anthropic 的网页搜索等服务端工具，会在响应中混入工具调用和工具输出。多模态输出模型甚至能在流式响应中穿插图片或音频片段。

流式输出（streaming）是现代 LLM API 的核心特性。由于大语言模型逐 token 生成文本，流式传输允许客户端在生成过程中就开始接收和显示内容，而非等待整个响应完成。这通常通过 HTTP 的 Server-Sent Events（SSE）协议实现。在用户体验层面，流式输出将感知延迟从数秒降低到首个 token 的生成时间（通常几百毫秒），这也是 ChatGPT 等产品采用逐字显示效果的技术基础。

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="")

这个设计的实际效果立竿见影——CLI 工具现在可以用不同颜色显示「思考」文本和最终回复文本，且思考内容输出到 stderr，不会影响管道操作。配合更新后的 llm-anthropic 插件，Claude 模型的推理过程可以灰色流式展示，正式回复则用常规颜色呈现。

工具调用方面，响应结束后可以调用 response.execute_tool_calls() 执行请求的函数，或通过 response.reply() 自动调用工具并将结果回传给模型。工具调用（Function Calling）是 2023 年中期以来 LLM 领域最重要的能力扩展之一。其工作原理是：开发者向模型声明可用的函数签名（名称、参数、描述），模型在推理过程中判断是否需要调用某个工具，如果需要则返回结构化的调用请求（函数名和参数 JSON），由客户端执行实际调用后将结果回传给模型继续推理。这构成了 AI Agent 的基础范式——模型不再只是文本生成器，而是能够规划和执行多步骤任务的智能体。

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

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

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

返回的字典是一个定义在 llm/serialization.py 模块中的 TypedDict，开发者可以自由选择存储后端——无论是 Redis、PostgreSQL 还是文件系统，不再被绑定到 SQLite。TypedDict 是 Python typing 模块中的一个特性，允许开发者为字典定义精确的键值类型约束。与普通字典不同，TypedDict 在静态类型检查工具（如 mypy、pyright）中能提供完整的类型推断和错误检测。在序列化场景中使用 TypedDict 而非自定义类，意味着序列化结果就是标准的 Python 字典，可以直接通过 json.dumps() 转换为 JSON，无需额外的序列化逻辑，同时又保留了类型安全性。

后续版本规划与路线图

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

还有一个重要的待办事项：重新设计 SQLite 日志系统，以更好地捕获新抽象返回的细粒度信息。理想方案是将对话建模为图结构，避免在 OpenAI 风格的 chat completions 场景中重复存储相同的对话历史。传统的对话存储将每次 API 调用的完整消息数组作为一条记录保存，这在多轮对话中会导致大量重复——第 N 轮对话的记录包含了前 N-1 轮的所有内容。图结构（Graph）方案将每条消息作为独立节点，通过边（edge）表示消息间的因果关系。这不仅节省存储空间，还能自然表达对话分支（同一上下文的多次不同回复）和对话合并等复杂拓扑，这在 AI Agent 的多路径探索场景中尤为重要。这个特性可能在 0.32 或 0.33 中实现。

总结：一次值得关注的架构演进

LLM 0.32 的重构体现了一个优秀开源项目如何在保持向后兼容的同时，跟上技术演进的步伐。从「文本问答」到「消息序列 + 类型化流式输出」的抽象升级，不仅解决了当前的痛点，也为多模态输出、服务端工具调用等新兴能力预留了空间。对于依赖 LLM Python 库构建应用的开发者来说，这是一次值得关注的架构演进。

核心要点

• LLM 0.32a0 将输入模型从单一文本提示升级为消息序列（messages），支持直接注入对话历史，与 OpenAI 等主流 API 格式对齐
• 新增 stream_events() 类型化流式输出接口，能区分文本、工具调用、推理过程等不同类型的响应内容
• 引入通用的 to_dict()/from_dict() 序列化机制，解除了对 SQLite 存储的强依赖
• 保持完全向后兼容，原有的 prompt= 参数和迭代式流式读取方式继续可用
• 后续计划将对话日志重新设计为图结构，避免重复存储相同对话历史