LLM新版本支持推理轨迹、OpenAI Responses、服务端工具及更智能日志

我今早发布了 LLM 0.32，这是自项目启动以来最重要的新版本。新版本包括对可见推理轨迹的支持、服务端 provider 工具、重新设计的内容寻址 SQLite 日志、新模型，以及由 OpenAI Responses API 启用的新功能。我还发布了 llm-anthropic 插件的新版本，该插件本身也有大量更新。

LLM CLI 用户的主要功能

对推理模型运行 LLM 现在会将它们的推理轨迹显示到标准错误输出，这样你可以看到它们在“思考”什么，而不会将这些信息包含在可能通过管道传递给其他工具的标准输出中。添加 -R/--hide-reasoning 可关闭此功能。

LLM 开箱即用地支持 GPT-5.6 模型系列，llm "prompt" 使用的新的默认模型现在是价格低廉但能力不俗的 GPT-5.6 Luna。

LLM 调用现在可以使用来自各种 provider 的服务端工具。OpenAI 提供了一个代码执行环境作为服务端工具；LLM 现在可以运行受益于该工具的 prompt，如下所示：

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 的端点执行 prompt 的单行工具。这些调用不会被记录，这使得它成为针对任何使用 LLM API 世界通用语言的端点运行一次性 prompt 的便捷工具。以下是我如何使用它来针对运行在 localhost LM Studio API 中的 Gemma 4 12B 运行 prompt，通过 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 运行 prompt！

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

这类 API 的更大挑战在于日志记录。如果我们要支持每次请求都追加消息序列的模式，理想情况下可以避免为每一轮记录所有重复的 JSON。解决方案是新的内容寻址消息存储，其设计借鉴了 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 工具，可以在一行命令中混搭来自不同来源的不同工具和不同模型，同时包含一个足够强大的 Python 库来构建像 Datasette Agent 和 llm-coding-agent 这样的系统，这确实很巧妙。也许下一个版本的 LLM 会将“agent”的概念融入核心库。我仍在尝试弄清楚那会是什么样子。

标签：projects、releases、ai、openai、generative-ai、llms、llm、anthropic、llm-tool-use、llm-reasoning、model-context-protocol