Simon 的 LLM 0.32：为什么命令行 AI 工具也开始变成 Agent 运行时？
Simon Willison 8 月 4 日发布 LLM 0.32，这个更新很适合写给开发者。它表面上是一个 CLI 工具版本更新，实际代表的是 AI 工具形态的变化：命令行 AI 正在从“向模型发一段文本”变成一个轻量 Agent runtime。
LLM 是 Simon 长期维护的命令行和 Python 库，用来访问不同大模型。以前这类工具的核心价值很直接：把 prompt 发给模型，把结果打印出来。但 2026 年的模型已经不只是补全文本。它们有 reasoning traces、tool calls、server-side tools、MCP、Responses API、typed streaming events，也会在一次任务中反复思考和调用工具。
LLM 0.32 的关键更新，正是把这些东西放进开发者工具链。
第一是 visible reasoning traces。推理模型不再只是吐一个最终答案，工具需要能记录和展示模型中间的 reasoning 事件。对开发者来说，这不是八卦模型怎么想，而是调试长任务和工具调用时必须看的运行信息。
第二是 OpenAI Responses API。Simon 之前就强调过，Responses API 更适合新一代模型，因为它天然包含 reasoning、工具调用和多类型事件。LLM 0.32 接上 Responses，说明开发者工具正在从旧的 chat completions 世界迁移到更 agentic 的接口世界。
第三是 server-side provider tools。LLM 0.32 和 llm-anthropic 0.26 支持 WebSearch、WebFetch、CodeExecution、AnthropicMCP 等 server-side tools。过去工具常常由本地 CLI 拦截和执行，现在越来越多能力由模型提供商侧运行，再以 typed event 流回客户端。
第四是日志。Simon 提到 redesigned content-addressable SQLite logs。这个变化很 Simon：他一直重视可追踪、可复现、可查询。AI 工具如果没有日志，就很难回答“这个结果从哪里来、用了什么模型、调用了什么工具、哪些 reasoning 被隐藏、花了多少 token”。
这也是为什么我觉得 LLM 0.32 不只是小版本。它把三个世界连到了一起：命令行、模型 API、Agent 事件流。未来开发者使用 AI，不一定都在庞大的 IDE 或云端产品里；一个足够好的 CLI，也可以成为 Agent 实验、自动化任务、日志分析和工具接入的入口。
它还有一个更大的启发：Agent runtime 不一定一开始就要是复杂平台。它可以从小东西长出来：
- 先支持模型和 provider 抽象。
- 再支持工具调用。
- 再支持 reasoning 和 typed events。
- 再支持日志、回放、检索。
- 最后才长出更明确的 agent 概念。
Simon 在文章里也提到，下一版 LLM 也许会把 agent 概念 bake into core library，但他还在思考那会是什么样。这个谨慎很对。现在行业里很多框架过早把 Agent 定义得很重，而开发者真正需要的可能是更小、更透明、更容易组合的运行时。
对普通开发者来说，LLM 0.32 的价值不是“又多支持几个模型”。真正价值是你可以在自己熟悉的 shell、脚本、SQLite、Python 环境里，把新模型的 reasoning、tool use 和 server-side capability 纳入可检查的工作流。
我的判断是，AI 开发工具会分成两条线。一条是大型 IDE/云端 Agent，适合完整工程任务；另一条是像 LLM 这样的轻量 runtime，适合脚本化、自动化、研究、调试和个人工作流。后者看起来朴素，但会长期存在，因为开发者永远需要一个能看清楚里面发生了什么的入口。