LLM 0.32：一个命令行工具长成了智能体框架

这一版改了什么

作者自己的定性是：这是 LLM 项目自发布以来最重要的一版。四条主线：

1. 推理轨迹可见，而且打在 stderr 上。 对推理模型运行时，「思考过程」输出到标准错误而不是标准输出——所以你依然可以把标准输出管给下一个程序，思考过程不会混进去（-R / --hide-reasoning 关掉）。
2. 服务端工具。 OpenAI 提供代码执行环境与 WebSearch；llm-anthropic 插件补上 WebSearch、WebFetch、CodeExecution 和 AnthropicMCP——后者意味着由供应商在一次请求-响应之内替你执行对某个远程 MCP 服务器的调用。
3. 内容寻址的消息存储，仿照 Git。 每一轮请求都携带完整历史是 LLM API 的本质，直接记日志会把同一段 JSON 重复写很多遍；按内容寻址之后去重，llm logs 再把它还原成好读的形式。
4. 结构化事件流。 stream_events() 返回 reasoning / text / 工具调用 / 图片附件等分型事件，取代原来「一串字符串」的返回形状。

另有 model.prompt(messages=[]) 取代原先的会话抽象，以及一个能对任意 OpenAI 兼容端点跑一次性提示词的 llm openai endpoint。

最小、但最值得抄的那个设计

可观测性和可组合性通常互相打架：你想看到中间过程，又想把结果干净地交给下一个程序。把推理轨迹放到 stderr、把答案留在 stdout，两件事同时成立，而且不需要任何新概念——这是 Unix 老办法在智能体工具上的一次准确复用。

工具循环正在往供应商那一侧挪

AnthropicMCP 这个工具值得单独看：MCP 调用发生在与供应商的一次 API 往返之内，客户端不再驱动那个循环。把它和 07-31 那版无状态 MCP、以及托管智能体放在一起看，是同一个方向的三种形态——执行、状态与工具接入都在向服务端收敛。

而这条信号的位置恰好在反方向

ChatGPT Work 和 Gemini 托管智能体把运行时搬到平台侧；LLM 0.32 走的是另一条路：一个跑在本机、可审计、能和任意 OpenAI 兼容端点拼接的命令行，外加一个足够写出真实智能体的 Python 库。

两条路线的取舍就是「你必须自己拥有哪一层」。这一版还把工具链可以为人工审批暂停、并从存储的消息历史恢复做进了框架——人在回路成了框架能力，而不是产品层面的一个开关。

作者自己的结论

他一度拒绝使用「智能体」这个词，直到接受了一个足够朴素的定义——智能体就是在循环里调用工具以达成目标。这一版之后他写道：「我猜 LLM 现在是个智能体框架了。」

一个命令行工具长成智能体框架，这件事本身就是当下这一层生态的形状：能力不再靠某个大平台一次性给全，而是靠小工具把模型、工具与循环拼起来。