LLM 0.32深度解析：Responses API与Agent工具链升级指南

引言

Simon Willison开源命令行工具llm，最初定位是跨模型统一调用CLI工具，核心能力是通过一套命令行接口对接不同大模型，同时将完整对话持久化存储到SQLite数据库。早期版本的数据模型以字符串作为消息载体，模型输出、工具调用返回结果全部以文本形式处理。随着Agent应用快速发展，推理过程、多工具混合调用、多类型混合输出的场景越来越普遍，纯字符串的数据模型已经无法承载复杂业务的诉求。

2026年8月4日正式发布的llm 0.32是一次偏向底层模型的重大迭代，新版本做到向后兼容的同时，引入Message/Part结构化消息模型，原生对接OpenAI Responses API，新增可暂停、可恢复的工具调用链路，内置WebSearch、CodeInterpreter两类服务端工具；日志存储层也完成重构，切换到基于内容寻址的SQLite存储Schema。这次升级的核心目标，不是简单增加命令行功能，而是把单次模型交互改造成为一套可序列化、可恢复、可审计的事件流，为Agent工程化落地补齐底层数据底座。在多模型多接口的工程项目中，可以借助koalaapi这类API网关统一管理各类模型服务流量。

二、数据模型重构：从纯字符串演进到Message与Part

2.1 模型输出不再局限普通文本

llm 0.32彻底重构内部消息结构，每一条Message由多个不同类型Part片段组成。

片段类型	说明
TextPart	普通文本内容
ReasoningPart	模型推理思考过程，可用于查看推理元数据
ToolCallPart	工具调用信息，包含工具名称、参数、tool_call_id
ToolResultPart	工具执行返回结果，也包含异常报错信息
AttachmentPart	附件、文件等二进制资源

0.32版本做了充分向后兼容，旧版本的prompt=、system=、attachments=、tool_results=参数仍然可以直接运行，内部会自动转换为这套结构化对象，存量业务代码不需要一次性大规模改写。

在代码调用层面，直接迭代response对象，返回的仍然是文本字符串，保证旧业务代码可以直接运行。而新增stream_events()以及异步版本astream_events()接口，会对外吐出完整混合事件流，文本输出、推理过程、工具调用、工具返回结果都会作为独立事件对外抛出，开发者可以单独捕获、处理每一类事件。

2.2 完整回合的序列化与状态恢复

新版本提供response.to_dict()与Response.from_dict()序列化能力，可以完整保存、还原一次完整对话回合，模型推理过程、服务商原始元数据全部被保留。response.prompt.messages保存的是真正发送给大模型的完整消息记录。

对比旧版本仅保存最终输出文本，完整序列化带来三大工程价值：会话回放、调用审计、跨进程会话恢复。开发者可以把一次Agent完整交互全部落盘，程序重启之后，直接加载dict对象，就可以接续上一轮未完成的工具调用继续执行，不需要重新复现全部上下文。

三、OpenAI Responses API与推理轨迹实现

3.1 切换Responses API的底层原因

目前主流支持推理输出的OpenAI兼容模型，默认已经支持/v1/responses接口。对比传统Chat Completions接口，Responses API更适合单次请求内部混合推理、多轮工具调用、多类型输出；并且可以在多轮工具交互的全过程，完整保存推理链路状态，不需要上层业务自己维护状态上下文。

llm 0.32做了接口默认切换，直接调用模型时优先走responses接口；如果业务需要兼容旧Chat Completions，也可以显式指定参数切回旧接口。

# 默认使用responses新接口
llm -m gpt-5.6-luna "分析这个问题"

# 强制切回 chat_completions 旧接口
llm -m gpt-5.6-luna -o chat_completions 1 "分析这个问题"

新版本默认加载GPT‑5.6 Luna，同时内置Sol、Terra、Luna等模型配置，这属于0.32内置目录，后续模型可用性会由服务商侧维护。

3.2 推理摘要输出到stderr标准错误流

当后端模型支持推理输出时，llm会把模型推理思考过程输出到stderr标准错误流，最终模型回答输出到stdout标准输出。这样设计的好处是Shell管道可以直接拿到模型最终输出，而终端控制台仍然能够完整观测推理过程。

示例：

# 输出可见推理摘要，打印到stderr
llm prompt -m gpt-5.6-luna -R "给出三条迁移建议"

# 将最终回答写入文件，推理过程不会混入输出文件
llm -m gpt-5.6-luna "生成发布摘要" > release.txt

需要注意：对外暴露的reasoning摘要，不等于模型完整内部思维链。0.32会完整保存加密推理元数据用于会话接续，但应用程序不能把stderr输出直接当做完整审计证据。

四、服务端工具与可恢复工具链

4.1 WebSearch与CodeInterpreter服务端工具

依托OpenAI Responses API能力，llm命令行可以直接调用服务商托管的WebSearch网页搜索、CodeInterpreter代码解释器两类服务端工具。

# 调用网页搜索工具
llm -m gpt-5.6-luna -T WebSearch "检索今天的数据库产品发布并给出来源"

# 调用代码解释器，设置内存限制
llm -m gpt-5.6-sol \
-T 'CodeInterpreter(memory_limit="4g")' \
"分析附件中的数据并输出结论"

服务端工具运行环境完全交由模型服务商维护，客户端无法感知工具真实运行环境。llm会把工具调用、返回结果统一封装为结构化Part对象存入会话；权限管控、数据留存、调用成本全部由模型服务商侧负责。

4.2 PauseChain实现人工审批状态

每一次工具调用都具备唯一tool_call_id标识。新版本引入llm.PauseChain机制：工具执行途中主动抛出暂停信号，将会话挂起，等待人工审批或者外部事件触发；恢复会话时，从未完成的工具调用位置恢复消息历史，已经执行完成的工具调用不会重复执行。

这套机制对于支付、消息发送、数据删除等高风险操作尤为关键。旧版本需要业务侧手动实现挂起、恢复逻辑；0.32直接把暂停、恢复能力封装进框架内部。完整流程：

1. 模型发起高风险工具调用；
2. 识别风险，抛出PauseChain暂停会话；
3. 持久化完整会话上下文，等待人工审批；
4. 收到外部审批信号，从暂停位置恢复执行；
5. 跳过已经执行完毕的工具，继续向下流转。

五、全新SQLite日志：内容寻址存储方案

5.1 threads、turns与消息存储重构

旧版本SQLite日志会对对话消息进行大量重复写入，相同消息在多轮会话中反复存储，造成存储膨胀。0.32采用内容寻址哈希存储的全新Schema：相同内容消息只保存一次，不同回合通过哈希引用指向这份消息实体。整体存储分为三层：thread会话线程、turn单次交互轮次、message_store消息实体库。

原始服务商返回完整响应json保存在turns.response_json字段，并且支持condense‑json压缩；llm logs --json可以把压缩数据还原为原始JSON结构。新的message_treeSQL视图，方便开发者直接查询会话流转链路。

5.2 升级前备份操作

升级到0.32版本之前，官方强烈建议对旧日志数据库执行备份，避免升级过程数据损坏。

pip install llm==0.32
llm logs backup logs‑backup.db
llm logs status

升级完成后旧的responses数据表不会直接删除，llm logs命令会同时展示新旧两套记录。0.32版本依赖sqlite‑utils>=4.0，插件、自定义日志查询逻辑都需要适配该版本依赖。

六、横向方案对比以及版本升级建议

不同Agent开发方案各有取舍，下表对llm0.32、官方SDK、LangChain、原生curl脚本做横向对比。

方案	优势	适用人群	局限
llm 0.32	多供应商CLI、SQLite本地日志、插件生态、结构化工具链	本地研究、自动化脚本、插件开发	不属于完整Agent平台，跨供应商迁移成本较高
官方SDK	新API迭代最快、原生能力完整	深度绑定单一平台业务	强绑定单一厂商
LangChain/LlamaIndex	组件丰富、工作流抽象成熟	大型应用编排	抽象厚重，日志体系不统一
原生curl脚本	依赖最少、完全透明	单次简单调用	状态管理、恢复、审计全部需要自行实现

升级时需要重点检查三类存量业务代码：

1. 直接读取旧日志SQL数据库的业务；
2. 假设响应输出只有纯文本的业务逻辑；
3. 工具调用逻辑中自定义状态机，没有使用tool_call_id唯一标识。

命令行调用可以向后兼容，但底层数据模型发生改变，自定义扩展插件需要做适配测试。

七、总结

llm 0.32把大模型CLI从简单的提示词收发工具，升级成为一套轻量完整的Agent运行时。它最大的价值，并不是给终端用户增加交互特效，而是把推理过程、工具调用、会话日志全部转化为可检查、可保存、可恢复的标准化数据结构。

结构化Message/Part模型，解决多类型混合输出的数据表达问题；对接Responses API原生承接推理轨迹与服务端工具；PauseChain暂停机制补齐人工介入Agent的工程缺口；内容寻址SQLite存储降低日志存储冗余，完整保留服务商原始响应，方便调试与审计。

同时也要看到版本升级带来的迁移风险：旧的SQL日志读取逻辑、自定义插件、状态机逻辑都需要适配新版本Schema。业务系统上线前，一定要完成备份、完整回归测试。这套开源工具为本地Agent原型、自动化脚本、轻量插件开发提供了低成本底座，非常适合开发者做Agent原型验证。