LLM 0.32重构详解：消息序列输入与流式多类型响应设计

概述

Simon Willison 发布了其 Python 库 LLM 的 0.32a0 alpha 版本，这是一次重大的向后兼容重构。LLM 是一个用于访问大语言模型的 Python 库和 CLI 工具，通过插件系统支持数千种不同模型。此次重构的核心目标是让抽象层能够更好地适应当今前沿模型日益多样化的输入输出类型。

Simon Willison 是 Django 框架的联合创始人，也是数据新闻和开源工具领域的知名开发者。他创建的 LLM 库采用了类似 yt-dlp 的插件架构思想——核心库提供统一接口，而具体模型的接入通过独立插件实现。目前已有 llm-claude-3、llm-gemini、llm-ollama 等数十个社区插件，覆盖了从 OpenAI GPT 系列到本地运行的开源模型。这种设计使得用户无需修改代码即可切换底层模型提供商，极大降低了供应商锁定风险。

为什么 LLM 库需要这次重构

2023 年 4 月 LLM 项目启动时，"文本输入、文本输出" 的简单抽象完全够用。但两年多来，大语言模型生态发生了巨大变化：

• 多模态输入（图像、音频、视频）通过 attachments 支持
• 结构化 JSON 输出通过 schemas 支持
• 工具调用（tool calls）能力的加入
• 推理（reasoning）输出的出现
• 模型开始能返回图像甚至音频片段

原有的 "一个 prompt 对应一个 text response" 的抽象已经无法承载这些复杂场景。LLM 0.32 的重构正是为了解决这一根本性的架构瓶颈。

消息序列：全新的输入抽象

旧模式的局限

此前 LLM 通过 conversation 对象来管理多轮对话，但这种方式只能从头构建对话，无法直接注入一段已有的对话历史。这使得构建 OpenAI chat completions API 兼容层等任务变得异常困难。

OpenAI 的 Chat Completions API 已成为事实上的行业标准接口格式，几乎所有模型提供商（Anthropic、Google、Mistral 等）都提供了兼容层。该 API 的核心设计是接收一个 messages 数组，每条消息带有 role（system/user/assistant）和 content 字段。此前 LLM 库的 conversation 抽象无法直接映射这一模式，导致构建代理服务器或中间件时需要大量适配代码。新的 messages 接口正是为了弥合这一差距。

新的 messages 接口设计

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())

原有的 prompt= 参数仍然有效，LLM 会在后台将其升级为单条消息数组。此外，新增的 response.reply() 方法提供了一种更自然的对话延续方式，无需手动管理 conversation 对象。

这种设计让开发者可以灵活地构造任意对话上下文，非常适合需要预设对话历史的应用场景，例如构建 few-shot 示例、实现对话分支、或在 API 网关中转发请求。

流式类型化部件：处理混合类型输出

现代大语言模型的混合输出需求

现代 LLM 的单次响应可能包含多种内容类型：推理文本、正文、工具调用请求、工具执行结果，甚至图像和音频片段。OpenAI 的 code interpreter、Anthropic 的 web search 等服务端工具更是让响应内容变得复杂多样。

流式响应（streaming）是现代 LLM 应用的关键用户体验优化。由于大语言模型逐 token 生成文本，流式传输允许用户在完整响应生成前就开始阅读内容，显著降低感知延迟。底层通常基于 HTTP Server-Sent Events（SSE）协议实现，客户端通过持久连接逐块接收数据。LLM 0.32 的 stream_events 设计借鉴了 LangChain 的 astream_events 接口思想，但提供了更轻量、更贴近底层模型 API 语义的实现。

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

这种设计的直接好处之一是 CLI 工具现在可以用不同颜色显示 "thinking" 文本和最终响应文本，且推理文本输出到 stderr 不会影响管道操作。新增的 -R/--no-reasoning 标志可以完全抑制推理 token 的输出。

关于推理输出的背景：推理（reasoning）输出源自 OpenAI 的 o1/o3 系列和 DeepSeek-R1 等模型引入的 "thinking" 机制。这些模型在生成最终答案前会先输出一段内部推理过程（Chain-of-Thought），帮助提升复杂任务的准确性。这些推理 token 通常需要与最终答案区分显示——用户可能想看到思考过程以建立信任，但在程序化处理时又希望只获取最终结果。LLM 0.32 的事件类型系统优雅地解决了这一需求。

工具调用的完整闭环实现

工具调用（Function Calling / Tool Use）是 2023 年下半年以来 LLM 领域最重要的能力扩展之一。模型不再只能生成文本，还能输出结构化的函数调用请求，由应用层执行后将结果返回模型。这构成了 AI Agent 的基础循环：模型思考→请求工具→获取结果→继续推理。OpenAI、Anthropic、Google 都已支持此能力，但各家的 API 格式略有差异——OpenAI 使用 tool_calls 数组，Anthropic 使用 tool_use content block——LLM 库的统一抽象在此处价值尤为突出。

响应结束后，开发者可以调用 response.execute_tool_calls() 直接执行被请求的函数，或使用 response.reply() 将工具返回值自动发送回模型，形成完整的 agent 循环。这让基于 LLM 库构建 AI Agent 变得更加简洁，开发者无需手动拼装多轮消息和处理各提供商的格式差异。

序列化与反序列化机制

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

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

返回的字典是一个定义在 llm/serialization.py 模块中的 TypedDict，为开发者提供了脱离 SQLite 的灵活存储选择。无论是存入 Redis、PostgreSQL 还是直接写入 JSON 文件，都可以轻松实现。

这一设计的背景在于 Simon Willison 对 SQLite 的独特应用哲学。他是 SQLite 的坚定倡导者，创建的 Datasette 项目就是围绕 SQLite 构建的数据探索工具。LLM 库使用 SQLite 存储所有对话日志，符合他"个人数据基础设施"的理念——所有交互记录都保存在用户本地的单个文件中，可随时查询和分析。但随着响应结构日益复杂（包含工具调用链、推理文本、多媒体附件等），原有的关系型表结构已难以优雅地容纳这些嵌套数据类型。新的序列化接口既保留了 SQLite 日志的便利性，又为需要其他存储方案的用户打开了大门。

后续版本计划与路线图

作为 alpha 版本发布后，Simon 计划在真实环境中验证设计几天后发布稳定版 0.32。剩余的主要任务是重新设计 SQLite 日志系统，使其能更精细地捕获新抽象返回的详细信息。

他还在考虑将对话存储建模为图结构，以支持 chat completions API 场景下对话不断扩展但不重复存储的需求。这一特性可能在 0.32 或 0.33 中实现。图结构存储意味着每条消息作为节点存在，对话分支通过边来表示，这样当多个对话共享前缀时（例如同一段系统提示词加不同的用户问题），可以避免重复存储相同的消息内容，同时自然地支持对话树的可视化和回溯。

开源项目演进的设计哲学

这次重构体现了优秀开源项目的演进智慧：在保持向后兼容的前提下，通过引入新的抽象层来适应领域的快速变化。从 "text in, text out" 到 "消息序列输入、类型化流式输出"，LLM 库的抽象层终于追上了大语言模型技术本身的发展速度。

值得注意的是，这种渐进式重构策略在快速演进的 AI 工具生态中尤为重要。与 LangChain 频繁的破坏性变更不同，LLM 库选择了一条更为保守但对用户更友好的路径：新功能通过新接口暴露，旧接口继续工作但在内部被桥接到新实现。这降低了升级成本，也体现了 Simon Willison 作为资深开源维护者对 API 稳定性的重视。

对于正在使用 LLM 库或考虑将其集成到项目中的开发者来说，0.32 版本标志着这个工具从简单的文本交互层进化为能够应对现代 AI 应用复杂需求的成熟框架。

核心要点

• LLM 0.32a0 引入消息序列（messages）作为输入，允许直接注入对话历史而非只能从头构建对话
• 新增 stream_events 接口支持流式类型化部件，可区分文本、工具调用、推理等不同类型的响应内容
• CLI 工具现在能以不同颜色显示推理文本和最终响应，推理输出到 stderr 不影响管道操作
• 新增 to_dict/from_dict 序列化机制，让开发者可以脱离 SQLite 自由选择存储方案
• 重构保持完全向后兼容，原有的 prompt= 参数和迭代式流处理仍然有效