8月4日,Simon Willison发布了他维护多年的命令行LLM客户端llm 0.32。这不是一次简单的功能叠加,而是一次向后兼容的底层重构:推理轨迹展示、OpenAI Responses API支持、服务器端工具、更智能的日志系统,四样东西凑在一起,说明这个原本定位"脚本化多模型客户端"的工具,正在往Agent化的方向靠。但细看变更清单会发现,Willison这次很克制——他把能力补齐了,却没有把llm变成一个会自己改代码、跑测试的编码Agent。
具体改了什么
最直接的变化是推理摘要默认走stderr,不再混进stdout,这样管道化调用不会被推理过程污染,想关掉也有-R或--hide-reasoning可以选。更底层的变化是,多数支持推理的OpenAI模型现在默认走/v1/responses接口而不是旧的Chat Completions,目的是让跨工具调用的推理能够交错保留;不习惯的人还能用-o chat_completions 1切回旧路径。
服务器端工具也是新增项,内置了OpenAI的WebSearch和CodeInterpreter,模型和插件都能声明由服务商直接执行的工具,不用本地再转一手。配合这个改动的,是输入输出格式换成了带类型的Message和Part对象,文本、推理、附件、工具调用分别归类,再通过stream_events()暴露出不同事件类型给开发者接。
真正有意思的是可暂停恢复的工具循环。用llm.PauseChain可以在工具调用中间停下来等人工审批,再从存储的消息历史里接着跑。这已经很接近Agent工具箱里的"人在回路"设计了。日志这块也重写了SQLite结构,引入thread和turn概念,重复内容按哈希只存一份,原始供应商响应压缩保留。另外新增了一个llm openai endpoint命令,专门用来对任意OpenAI兼容端点发一次性请求,这类调用被有意设计成不写入日志——适合调试,不适合留痕。
发布得挺赶
这次重构不是临时起意。发布追踪Issue #1590写得很直白,目标之一就是解除那些等着新Part机制的插件的阻塞状态——插件生态一直在等这次更新,拖得越久,越多插件停在半适配状态。正式发布前,团队还修了一个推理元数据的bug:流式Responses API调用可能因为元数据来自不同的流事件,给同一个推理项记了两个不同的加密密文,0.32最终版改成从已完成的响应载荷里统一取值。
- 提醒.长推理量的Responses API请求可能触发SDK的十分钟超时叠加两次重试,大约三十分钟后才失败,这条Issue #1504截至检索时依然开着,提的方案是加可配置的timeout和max_retries参数。
发布到现在只过了大约一天,公开反馈窗口很短,还没看到明确的回归性bug报告。这不代表稳,只代表还没来得及暴露问题——想在生产环境批量跑长推理任务的人,这个坑最好自己先踩一遍再上线。
它到底算不算Agent
把llm放进当下的CLI工具谱系里看,位置反而更清楚。一边是Claude Code、OpenAI Codex CLI、Gemini CLI这类具备自主编码能力的Agent,能改多文件、跑测试、修bug;另一边是llm、Aider这类偏工具/脚本化定位的客户端。0.32加了推理轨迹、Responses API、工具循环,这些原本是Agent产品的标志性能力,但llm依然没有仓库编辑权限,没有第一方的Shell操作权限模型,PauseChain暂停的是工具调用,不是替你去写代码。
按Agent自主能力排,业内大致认为Claude Code领先,Gemini CLI其次,llm排在中间,Codex CLI和Aider之后。但换一把尺子,按Python库和插件架构评价,llm的可插拔模型提供商设计、CLI命令扩展能力,可能反而是同类里最强的。两种排名标准直接冲突,说明"谁更强"这个问题本身问错了——llm根本没打算跟Claude Code抢编码Agent的位置。
功能在靠拢,产品哲学没有靠拢。
对插件开发者来说,现实的问题是要不要为结构化Part机制做适配;对靠llm跑批处理和CI脚本的开发者来说,默认切到Responses API、推理摘要改走stderr,意味着管道行为变了,升级前得测一遍现有脚本。至于要不要用llm做主力工具还是转向Claude Code、Codex CLI——这次更新没有改变答案,只是让"llm是什么"这个问题回答得更精确了一点。