文章目录LLM 0.32技术解析结构化推理轨迹、Responses API与可恢复工具链一、引言二、数据模型变化从字符串到Message与Part2.1 一条回答已经不只是文本2.2 完整回合可序列化三、OpenAI Responses API与推理轨迹3.1 为什么切换到Responses API3.2 推理摘要走stderr四、服务端工具与可恢复工具链4.1 WebSearch与CodeInterpreter4.2 PauseChain把人工审批变成一等状态五、新SQLite日志内容寻址而非重复存历史5.1 threads、turns与消息存储5.2 升级前先备份六、横向对比与升级建议七、总结LLM 0.32技术解析结构化推理轨迹、Responses API与可恢复工具链一、引言亲爱的朋友们创作不容易若对您有帮助的话请点赞收藏加关注哦您的关注是我持续创作的动力谢谢大家有问题请私信或联系邮箱jasonai.fngmail.comSimon Willison 的开源命令行工具 LLM 最初解决的是一个朴素问题用统一 CLI 调用不同大模型并把对话记录进 SQLite。随着模型开始输出推理摘要、调用客户端和服务端工具、在一次响应中混合多种内容过去“提示是字符串、回答也是字符串”的抽象已经不够用了。2026 年 8 月 4 日发布的 LLM 0.32 是一次向后兼容但触及底层数据模型的大升级。它引入结构化 Message/Part、采用 OpenAI Responses API 支持推理模型、开放可暂停和恢复的工具链增加 WebSearch 与 CodeInterpreter 服务端工具并把日志迁移到基于内容寻址消息存储的新 SQLite Schema。这次升级的主线不是多几个命令而是让一次模型交互成为可序列化、可恢复、可审计的事件流。二、数据模型变化从字符串到Message与Part2.1 一条回答已经不只是文本Message ├── TextPart 普通文本 ├── ReasoningPart 可见摘要或加密推理元数据 ├── ToolCallPart 工具名、参数、tool_call_id ├── ToolResultPart 结果或错误 └── AttachmentPart 图片、文件等附件LLM 0.32 的提示与输出都表示为 Message 列表每条消息包含带类型的 Part。旧的prompt、system、attachments和tool_results仍可使用并在内部转换到同一结构因此现有脚本不必一次性重写。importllm modelllm.get_model(gpt-5.6-luna)responsemodel.prompt(messages[llm.user(你好),llm.assistant(你好有什么需要),llm.user(总结这段对话。),])foreventinresponse.stream_events():print(event)直接迭代response仍只产生文本兼容旧代码stream_events()和异步版本astream_events()则暴露文字、推理、工具调用和工具结果混合事件。2.2 完整回合可序列化response.to_dict()与Response.from_dict()可以保存和恢复完整回合包含推理与供应商元数据response.prompt.messages成为实际发送给模型的规范记录。相比只记最终文本这为重放、审计和跨进程恢复提供了基础。三、OpenAI Responses API与推理轨迹3.1 为什么切换到Responses API大多数支持推理的 OpenAI 模型现在默认走/v1/responses。与旧 Chat Completions 相比它更适合在一个响应中组合推理、工具调用和多种输出也能在多次工具调用之间保留交错推理状态。# 默认使用对应模型的新接口llm-mgpt-5.6-luna分析这个问题# 针对单次调用回退到Chat Completionsllm-mgpt-5.6-luna-ochat_completions1分析这个问题发布说明称未显式选择默认模型的新用户现在默认使用 GPT-5.6 Luna并加入 Sol、Terra、Luna 等内置模型配置这属于 LLM 0.32 当时的内置目录后续可用性仍以供应商端为准。3.2 推理摘要走stderr支持的模型会把可见推理摘要流式写到标准错误最终答案写标准输出。这样 shell 管道可以只消费答案人仍能在终端观察推理过程。# 隐藏可见推理摘要llm prompt-mgpt-5.6-luna-R给出三条迁移建议# 将最终文本交给下游推理信息不混入文件llm-mgpt-5.6-luna生成发布摘要release.txt需要强调可见 reasoning summary 不等于模型完整思维链。0.32 还会保存加密推理元数据供后续回合继续使用但应用不应把它当作可读审计证据。四、服务端工具与可恢复工具链4.1 WebSearch与CodeInterpreterOpenAI Responses 模型可从 CLI 调用服务端 WebSearch 和 CodeInterpreterllm-mgpt-5.6-luna-TWebSearch\检索今天的数据库产品发布并给出来源llm-mgpt-5.6-sol\-TCodeInterpreter(memory_limit4g)\分析附件中的数据并输出结论服务端工具由模型供应商执行客户端不一定看得到其运行环境。LLM 0.32 将调用和结果统一记录为结构化 Part但权限、数据保留和成本仍由对应平台决定。4.2 PauseChain把人工审批变成一等状态每次工具调用都有唯一tool_call_id。工具可以抛出llm.PauseChain等待人工批准或外部事件再从以未解决工具调用结尾的消息历史恢复并避免重复执行已有结果的调用。模型提出工具调用 │ ▼ 高风险检查 ── 低风险 ─► 执行并记录ToolResult │ 高风险 ▼ PauseChain → 持久化消息 → 人工批准/外部事件 │ ▼ 从未解决调用恢复这对支付、发消息、删除资源等不可重复副作用尤其重要。过去应用要自行拼接状态机现在暂停和恢复进入框架抽象。五、新SQLite日志内容寻址而非重复存历史5.1 threads、turns与消息存储旧日志把大量对话历史重复写进响应记录。0.32 以 thread、turn 和内容哈希消息存储重建 Schema相同消息只存一次回合引用其哈希并保存结构化文字、推理、附件和工具活动。thread ├── turn 1 ─► prompt message hashes ─► message_store │ └► response parts / response_json └── turn 2 ─► prompt message hashes ─┘ └► response parts / response_json原始供应商载荷保存在turns.response_json使用condense-json压缩llm logs --json可展开回原始形状。新message_treeSQL 视图能把会话线程展示为缩进树。5.2 升级前先备份llm logs backup logs-backup.db pipinstall-Ullm llm logs status旧responses表不会被删除llm logs会联合展示两代记录。0.32 要求sqlite-utils4.0升级插件和自定义日志查询时应做兼容测试。六、横向对比与升级建议方案优势适合用户局限LLM 0.32多供应商CLI、SQLite日志、插件、结构化工具链本地研究、自动化、插件开发不是完整托管Agent平台供应商官方SDK新API覆盖最快、原生功能完整深度绑定单一平台跨供应商迁移成本高LangChain/LlamaIndex工作流、检索与集成丰富大型应用编排抽象更重日志体系不同直接curl/脚本最少依赖、完全透明单次简单调用状态、恢复和审计需自建升级时重点检查三类代码直接读取旧日志表的 SQL、假设响应只有文本的插件、以及工具调用没有唯一 ID 的自定义状态机。命令行常规调用向后兼容不代表底层扩展无需测试。七、总结维度核心结论结构化交互Message/Part统一文本、推理、工具、结果与附件旧参数仍兼容OpenAI接口推理模型默认采用Responses API支持交错推理与服务端工具工具控制tool_call_id、PauseChain与恢复机制让人工批准和幂等执行更可靠日志重构内容寻址消息存储减少历史重复并保留供应商原始载荷升级风险自定义插件与SQL需要适配升级前应备份日志并做回归测试LLM 0.32 把大模型 CLI 从“发提示、收文本”的薄封装推进成一个轻量但完整的交互运行时。它最有价值的地方不是替用户隐藏细节而是把推理、工具和日志细节变成明确的数据结构让开发者能检查、保存并恢复每一步。参考资料LLM 0.32发布说明 — GitHubLLM官方文档LLM结构化消息Python API 【LLM 0.32技术解析】结构化推理轨迹、Responses API与可恢复工具链
文章目录LLM 0.32技术解析结构化推理轨迹、Responses API与可恢复工具链一、引言二、数据模型变化从字符串到Message与Part2.1 一条回答已经不只是文本2.2 完整回合可序列化三、OpenAI Responses API与推理轨迹3.1 为什么切换到Responses API3.2 推理摘要走stderr四、服务端工具与可恢复工具链4.1 WebSearch与CodeInterpreter4.2 PauseChain把人工审批变成一等状态五、新SQLite日志内容寻址而非重复存历史5.1 threads、turns与消息存储5.2 升级前先备份六、横向对比与升级建议七、总结LLM 0.32技术解析结构化推理轨迹、Responses API与可恢复工具链一、引言亲爱的朋友们创作不容易若对您有帮助的话请点赞收藏加关注哦您的关注是我持续创作的动力谢谢大家有问题请私信或联系邮箱jasonai.fngmail.comSimon Willison 的开源命令行工具 LLM 最初解决的是一个朴素问题用统一 CLI 调用不同大模型并把对话记录进 SQLite。随着模型开始输出推理摘要、调用客户端和服务端工具、在一次响应中混合多种内容过去“提示是字符串、回答也是字符串”的抽象已经不够用了。2026 年 8 月 4 日发布的 LLM 0.32 是一次向后兼容但触及底层数据模型的大升级。它引入结构化 Message/Part、采用 OpenAI Responses API 支持推理模型、开放可暂停和恢复的工具链增加 WebSearch 与 CodeInterpreter 服务端工具并把日志迁移到基于内容寻址消息存储的新 SQLite Schema。这次升级的主线不是多几个命令而是让一次模型交互成为可序列化、可恢复、可审计的事件流。二、数据模型变化从字符串到Message与Part2.1 一条回答已经不只是文本Message ├── TextPart 普通文本 ├── ReasoningPart 可见摘要或加密推理元数据 ├── ToolCallPart 工具名、参数、tool_call_id ├── ToolResultPart 结果或错误 └── AttachmentPart 图片、文件等附件LLM 0.32 的提示与输出都表示为 Message 列表每条消息包含带类型的 Part。旧的prompt、system、attachments和tool_results仍可使用并在内部转换到同一结构因此现有脚本不必一次性重写。importllm modelllm.get_model(gpt-5.6-luna)responsemodel.prompt(messages[llm.user(你好),llm.assistant(你好有什么需要),llm.user(总结这段对话。),])foreventinresponse.stream_events():print(event)直接迭代response仍只产生文本兼容旧代码stream_events()和异步版本astream_events()则暴露文字、推理、工具调用和工具结果混合事件。2.2 完整回合可序列化response.to_dict()与Response.from_dict()可以保存和恢复完整回合包含推理与供应商元数据response.prompt.messages成为实际发送给模型的规范记录。相比只记最终文本这为重放、审计和跨进程恢复提供了基础。三、OpenAI Responses API与推理轨迹3.1 为什么切换到Responses API大多数支持推理的 OpenAI 模型现在默认走/v1/responses。与旧 Chat Completions 相比它更适合在一个响应中组合推理、工具调用和多种输出也能在多次工具调用之间保留交错推理状态。# 默认使用对应模型的新接口llm-mgpt-5.6-luna分析这个问题# 针对单次调用回退到Chat Completionsllm-mgpt-5.6-luna-ochat_completions1分析这个问题发布说明称未显式选择默认模型的新用户现在默认使用 GPT-5.6 Luna并加入 Sol、Terra、Luna 等内置模型配置这属于 LLM 0.32 当时的内置目录后续可用性仍以供应商端为准。3.2 推理摘要走stderr支持的模型会把可见推理摘要流式写到标准错误最终答案写标准输出。这样 shell 管道可以只消费答案人仍能在终端观察推理过程。# 隐藏可见推理摘要llm prompt-mgpt-5.6-luna-R给出三条迁移建议# 将最终文本交给下游推理信息不混入文件llm-mgpt-5.6-luna生成发布摘要release.txt需要强调可见 reasoning summary 不等于模型完整思维链。0.32 还会保存加密推理元数据供后续回合继续使用但应用不应把它当作可读审计证据。四、服务端工具与可恢复工具链4.1 WebSearch与CodeInterpreterOpenAI Responses 模型可从 CLI 调用服务端 WebSearch 和 CodeInterpreterllm-mgpt-5.6-luna-TWebSearch\检索今天的数据库产品发布并给出来源llm-mgpt-5.6-sol\-TCodeInterpreter(memory_limit4g)\分析附件中的数据并输出结论服务端工具由模型供应商执行客户端不一定看得到其运行环境。LLM 0.32 将调用和结果统一记录为结构化 Part但权限、数据保留和成本仍由对应平台决定。4.2 PauseChain把人工审批变成一等状态每次工具调用都有唯一tool_call_id。工具可以抛出llm.PauseChain等待人工批准或外部事件再从以未解决工具调用结尾的消息历史恢复并避免重复执行已有结果的调用。模型提出工具调用 │ ▼ 高风险检查 ── 低风险 ─► 执行并记录ToolResult │ 高风险 ▼ PauseChain → 持久化消息 → 人工批准/外部事件 │ ▼ 从未解决调用恢复这对支付、发消息、删除资源等不可重复副作用尤其重要。过去应用要自行拼接状态机现在暂停和恢复进入框架抽象。五、新SQLite日志内容寻址而非重复存历史5.1 threads、turns与消息存储旧日志把大量对话历史重复写进响应记录。0.32 以 thread、turn 和内容哈希消息存储重建 Schema相同消息只存一次回合引用其哈希并保存结构化文字、推理、附件和工具活动。thread ├── turn 1 ─► prompt message hashes ─► message_store │ └► response parts / response_json └── turn 2 ─► prompt message hashes ─┘ └► response parts / response_json原始供应商载荷保存在turns.response_json使用condense-json压缩llm logs --json可展开回原始形状。新message_treeSQL 视图能把会话线程展示为缩进树。5.2 升级前先备份llm logs backup logs-backup.db pipinstall-Ullm llm logs status旧responses表不会被删除llm logs会联合展示两代记录。0.32 要求sqlite-utils4.0升级插件和自定义日志查询时应做兼容测试。六、横向对比与升级建议方案优势适合用户局限LLM 0.32多供应商CLI、SQLite日志、插件、结构化工具链本地研究、自动化、插件开发不是完整托管Agent平台供应商官方SDK新API覆盖最快、原生功能完整深度绑定单一平台跨供应商迁移成本高LangChain/LlamaIndex工作流、检索与集成丰富大型应用编排抽象更重日志体系不同直接curl/脚本最少依赖、完全透明单次简单调用状态、恢复和审计需自建升级时重点检查三类代码直接读取旧日志表的 SQL、假设响应只有文本的插件、以及工具调用没有唯一 ID 的自定义状态机。命令行常规调用向后兼容不代表底层扩展无需测试。七、总结维度核心结论结构化交互Message/Part统一文本、推理、工具、结果与附件旧参数仍兼容OpenAI接口推理模型默认采用Responses API支持交错推理与服务端工具工具控制tool_call_id、PauseChain与恢复机制让人工批准和幂等执行更可靠日志重构内容寻址消息存储减少历史重复并保留供应商原始载荷升级风险自定义插件与SQL需要适配升级前应备份日志并做回归测试LLM 0.32 把大模型 CLI 从“发提示、收文本”的薄封装推进成一个轻量但完整的交互运行时。它最有价值的地方不是替用户隐藏细节而是把推理、工具和日志细节变成明确的数据结构让开发者能检查、保存并恢复每一步。参考资料LLM 0.32发布说明 — GitHubLLM官方文档LLM结构化消息Python API