本文为翻译/转载，原文使用 CC BY-NC-SA 4.0 协议发布。 原文作者：Simon Willison 原文标题：New release of LLM adds support for reasoning traces, OpenAI Responses, server-side tools, and smarter logging 原文链接：https://simonwillison.net/2026/Aug/4/new-release-of-llm/ 原文发布：2026-08-04 本博客不参与任何商业变现（含 ads / 付费 / affiliate），本译文遵循 CC BY-NC-SA 4.0 条款发布。

译者按

这是 Simon Willison 的 LLM CLI 项目自 2023 年启动以来最重要的一次版本更新，涵盖四个中文开发者圈最关心的方向：推理轨迹（reasoning traces）可视化——跑 DeepSeek / Kimi / GPT-5.6 等推理模型时能看到”思考过程”，且输出到 stderr 不污染管道数据；服务端工具与 MCP——OpenAI 代码沙箱、网页搜索，乃至 Anthropic 的 AnthropicMCP 让模型在单次请求内直接调用远程 MCP 服务器，正好衔接我们之前译过的 Stateless MCP 一文；OpenAI Responses API 兼容层——llm-chat-completions-server 让任何 Chat Completions 客户端都能接上 LLM 生态。中文圈做多模型聚合的工具有不少（Chatbox、Cherry Studio 等），但 LLM 以”一行命令 + Python 库 + 插件生态”的 Unix 哲学独树一帜，这篇译文能帮你快速判断它是否值得进入自己的工具链。

正文

今天早上我发布了 LLM 0.32，这是该项目自启动以来最重要的一次新版本。新版本包含对可见推理轨迹（reasoning traces）、服务端提供商工具（server-side provider tools）、重新设计的内容寻址 SQLite 日志、新模型，以及由 OpenAI Responses API 启用的各种新特性的支持。我还发布了新版的 llm-anthropic 插件，它本身也有大量更新。

面向 LLM CLI 用户的核心特性

用 LLM 调用推理模型时，现在会把它们的推理轨迹输出到标准错误（stderr），这样你就能看到模型在”想什么”，而这些内容不会混入你可能要管道（pipe）给其他工具的标准输出。加 -R/--hide-reasoning 可以关掉这个行为。

LLM 开箱即支持 GPT-5.6 模型家族，llm "prompt" 现在使用的默认模型是便宜但能力不俗的 GPT-5.6 Luna。

LLM 调用现在可以使用各提供商的服务端工具。OpenAI 提供了一个代码执行环境作为服务端工具；LLM 现在可以这样运行受益于该工具的提示词：

llm --tool CodeInterpreter 'Show current python and SQLite versions'

OpenAI 还有一个 WebSearch 工具。

llm-anthropic 插件新增了 WebSearch、WebFetch、CodeExecution 和 AnthropicMCP，用法如下：

llm -m claude-sonnet-5 -T 'AnthropicMCP("https://datasette.simonwillison.net/-/mcp")' \
 'how many rows in the blog_blogmark table?'

这会让 Anthropic 在与 API 的单次请求-响应交互中，针对我新写的 datasette-mcp 插件执行 MCP 调用。

新的 llm openai endpoint 命令提供了一种以一行命令对任意 OpenAI 兼容端点执行提示词的方式。这些调用不会被记录，因此它是针对任何讲 LLM API 世界”通用语”的服务运行一次性提示词的便捷工具。

下面是我如何用它在 localhost 的 LM Studio API 上运行 Gemma 4 12B——通过 uvx（无需安装 LLM），并混入 llm-tools-quickjs 工具插件：

uvx --with llm-tools-quickjs \
 llm openai endpoint http://localhost:1234/v1 -m google/gemma-4-12b \
 -T QuickJS 'Use QuickJS to multiply 3434 * 2434' --td

Python API 的新特性

LLM 的 Python API 以前要求你先创建一个会话（conversation），然后一条一条地发送消息。这是对 LLM 真实工作方式的一种抽象——实际上每次请求都携带了此前所有消息的完整历史。对于某些更高级的用例，这种抽象开始碍事了，因此新版本引入了 model.prompt(messages=[]) 参数，可以这样用：

import llm
from llm import user, assistant, system

model = llm.get_model("gpt-5.6-luna")

response = model.prompt(messages=[
    system("You are a helpful pirate."),
    user("What is the capital of France?"),
    assistant("Paris, matey."),
    user("And Germany?"),
])
print(response.text())

LLM 之前每次 prompt 返回的是字符串的可迭代序列。当模型返回纯字符串响应时这很好用，但它没能预见到模型会演化成的奇怪形态。今天许多模型返回的是推理文本、输出字符串、工具调用甚至图片附件的混合体。有了 LLM 0.32，你可以这样处理：

for event in model.prompt("Explain cats").stream_events():
    if event.type == "reasoning":
        print(f"[thinking] {event.chunk}", end="", flush=True)
    elif event.type == "text":
        print(event.chunk, end="", flush=True)
    else:
        print(f"Other event: {event}")

把这些特性组合起来，我们终于能为半标准的 OpenAI Chat Completions API 提供可靠的实现了——我已把它发布为 llm-chat-completions-server 插件：

llm install llm-chat-completions-server
llm chat-completions-server --port 9000
# Server is now running on http://127.0.0.1:9000/v1

现在你可以用新的 llm openai endpoint 命令，通过该服务器对 LLM 运行提示词了！

llm openai endpoint http://127.0.0.1:9000/v1 'hello' -m gpt-5.4-mini

这类 API 面临的更大挑战在于日志。如果我们要支持”每次请求都追加消息序列”的模式，理想情况下应避免为每一轮都记录下所有重复的 JSON。

解决方案是新的内容寻址消息存储（content-addressable message store），其设计仿照 Git。你可以在文档中看到它的新 schema，而 llm logs 和 llm logs --json 命令都已升级，能把该格式转换回易于消费的形式。

还有更多

这次发布里还有更多内容。0.32 的发布说明相当全面，而 0.32rc2、0.32rc、0.32a3、0.32a2 和 0.32a0 的说明可以填补任何空白。

现有 LLM 插件应该都能继续工作，但提供额外模型的插件需要升级到 0.32 才能完全参与新的流式事件系统。文档中有一份使用结构化消息与流式事件实现插件的指南。

我也更新了自己的一些插件：

• llm-anthropic 0.26 增加了对 Claude 5 模型家族的支持，以及 WebSearch、WebFetch、CodeExecution 和 AnthropicMCP 服务端工具。
• llm-gemini、llm-openrouter 和 llm-mistral 也快好了，版本即将发布。

我想 LLM 现在算是一个 agent 框架了

这次发布中相当一部分底层工具改动，是由 Datasette Agent 的需求驱动的。当我开始做 LLM 时，“agent”这个词的定义还非常模糊，所以我拒绝使用它。到了 2025 年 9 月，我逐渐接受了”LLM agent 就是循环运行工具以达成目标”这一定义已经足够成熟，可以不再回避这个词了。

工具链现在可以暂停等待人工批准，并从存储的消息历史中恢复——这两者都是 Datasette Agent 需要的。

看看今天的 LLM，它在我眼里越来越有 agent 的形状了。一个 CLI 工具，能用一行命令把不同来源的不同工具与不同模型混搭在一起，还附带一个强大到足以构建 Datasette Agent 和 llm-coding-agent 这类系统的 Python 库——这感觉挺妙的。

也许下一个版本的 LLM 会把”agent”这个概念烘焙进核心库。我还在琢磨那会是什么样子。

译者注

1. 推理轨迹（reasoning traces）：推理模型（如 OpenAI o 系列、DeepSeek-R1、GPT-5.6 家族）在给出答案前会先生成一段”思考过程”。LLM 0.32 默认把它输出到 stderr，与结果（stdout）分离——这样 llm 'prompt' | jq 之类的管道不会被”思考”污染，这是命令行工具非常讲究的设计。中文用户用 llm 跑 DeepSeek 或 Kimi 的推理模型时，可以直观看到 R1 式思维链。

2. 服务端工具（server-side tools）vs 本地工具：传统 tool use 是模型输出工具调用、客户端本地执行；而服务端工具（OpenAI 的代码沙箱、网页搜索）是在模型提供商侧执行后把结果送回。这降低了客户端复杂度，也让”代码解释器”这类需要受控环境的能力变得可用。它和 MCP（模型上下文协议）是两个互补的方向：MCP 解决”工具如何暴露给模型”，服务端工具解决”工具在哪里执行”。

3. AnthropicMCP：Claude 5 系列支持在 API 请求内直接携带 MCP 服务器地址，由 Anthropic 侧代为执行 MCP 调用——这呼应了 Simon 之前那篇《Stateless MCP》的观点：无状态、按需连接的 MCP 才是主流用法，不必在本地常驻配置一堆 MCP 服务器。

4. OpenAI Responses API：OpenAI 新一代对话接口，支持工具调用、推理内容与多模态事件的统一流式输出。llm-chat-completions-server 的意义在于：它让存量 Chat Completions 客户端（各种基于该协议的 SDK、脚本）能无缝接到 LLM 生态——相当于给”API 通用语”加了一个翻译层。

5. 内容寻址消息存储：类似 Git 的对象模型——每条消息按其内容哈希去重存储，多轮对话中重复携带的历史消息不必重复落盘。对长时间运行的 agent 会话来说，这能把日志体积从 O(n²) 压回 O(n)，llm logs 依旧能还原出可读的历史。

延伸阅读

• Stateless MCP 重新燃起我的兴趣（以及 mcp-explorer 与 datasette-mcp 的诞生）
• 用 LLM 构建一个编码代理：Simon Willison 的 llm-coding-agent 实践
• GPT-5.6 家族面世：Luna、Terra、Sol——Simon Willison 深度评测
• Introducing Claude Opus 5：Anthropic 新一代旗舰模型全解读
• sqlite-utils 4.0rc2：Claude Fable 用约 150 美元写出了一个开源库