资料库 ④ · 本地模型与 LLM 命令行

第 61–80 条 · 共 20 条 · 来源：Simon Willison · 时间跨度 2025-08 至 2026-08

这一卷分两半：

• 第 61–70 条：本地模型与硬件。 重点是 27B–35B 这一档开放权重模型的进步——现在已经能在一台高配笔记本上处理不少实际任务了，这在一年前不成立。
• 第 71–80 条：llm 命令行工具。 Simon Willison 自己写的工具，核心思路是把 LLM 当成 Unix 管道里的一环。

两半的共同主题是减少对单一厂商 API 的依赖：本地模型在模型层独立，llm 的插件架构在接口层独立。

这一卷过期最快

五卷里 会过期 比例最高的就是这一卷——模型型号、硬件性价比、工具版本号都在快速迭代。所以读的重点应该放在方法和坑上：量化怎么选、服务商为什么会不一致、评测怎么搭、插件架构为什么这么设计。这些换几轮型号仍然成立，具体的"哪个模型最好"三个月后就不对了。

2025 年 8—11 月：本地推理的基础设施

61. llama.cpp guide: running gpt-oss with llama.cpp

来源：Simon Willison 介绍的官方指南，2025 年 8 月 19 日。会过期

读它解决什么：用 llama.cpp 跑一个开放权重模型，具体怎么做。

要点：

• llama.cpp 是本地推理最核心的基础设施：支持 CPU 和多种 GPU，覆盖面极广
• 用 GGUF 格式，配合不同的量化等级
• 提供 llama-server——一个 HTTP 服务，方便别的程序接入

我的补充：理解量化的取舍是本地跑模型的第一课，也是最容易搞错的一环。

量化就是把模型权重的精度降低来省内存。常用等级和我的实测感受：

量化	相对体积	质量
F16	100%	基准
Q8_0	~50%	基本无损
Q5_K_M	~35%	很接近，内存够就选它
Q4_K_M	~25%	性价比最好，默认选这个
Q3_K_M	~20%	开始明显退化
Q2_K	~15%	通常不值得用

Q4_K_M 是我的默认选择：体积压到四分之一，质量损失在大多数任务上察觉不到。低于 Q4 之后退化会变得明显——不是"稍差"，而是会开始出现逻辑错误和指令遵循变差。

显存/内存是硬约束，算法很简单：模型体积 + KV cache + 上下文。一个 27B 模型在 Q4 下大约 15–16GB，加上 KV cache，16GB 的机器会很吃力，24GB 才比较舒服。长上下文时 KV cache 的占用可能超出你的预期——这是最容易算漏的一项。

llama-server 的关键价值是它提供 OpenAI 兼容接口：任何支持 OpenAI API 的工具，把 base URL 指向它就能用本地模型，代码一行不用改。这是本地模型能接入现有工具链的原因。

选型建议：想省事用 Ollama 或 LM Studio（它们底层就是 llama.cpp）；需要精细控制量化、上下文长度、GPU 层数分配，直接用 llama.cpp。

阅读原文 →

62. Open weight LLMs exhibit inconsistent performance across providers

来源：Simon Willison，2025 年 8 月 15 日。结构性

读它解决什么：同一个开源模型，为什么在不同服务商那里表现不一样。

要点：

• 实测发现同一份开放权重在不同服务商的托管下表现有差异
• 模型名字相同不代表行为相同

我的补充：这是本地/开源模型这一块最容易踩的坑，而且它完全不会过期。

很多人以为"开放权重模型到处都一样"——权重相同只是必要条件，不是充分条件。差异来源，按影响大小排：

1. 量化方式（影响最大）。 服务商为了降成本可能用 Q4 甚至更低，而你看的 benchmark 用的是 F16。而服务商很少公开自己用的量化等级——这是最不透明的一环。
2. 聊天模板。 模型对 prompt 的格式非常敏感，模板拼错了质量会明显下降，但不会报错——只是变得没那么聪明。这类问题极难排查。
3. 采样参数默认值。 temperature、top_p、top_k、repetition penalty，各家默认值不同，输出风格差别很大。
4. 上下文长度限制。 有的服务商为了省成本截短了最大上下文。
5. 推理引擎实现差异。 vLLM、TensorRT-LLM、llama.cpp 在数值精度和 kernel 实现上有细微不同。
6. 服务商自己加的系统提示或后处理——通常不会告诉你。

实践建议：

• 用你自己的任务做对比测试，不要只看榜单（对应第 74 条讲的最小评测）
• 主动问清量化方式，问不出来就假设是激进量化
• 显式指定采样参数，不要依赖默认值
• 发现变差时，先怀疑服务商改了配置，再怀疑模型——我遇到过好几次是前者
• 关键场景固定一个服务商，或者自己托管

阅读原文 →

63. NVIDIA DGX Spark: great hardware, early days for the ecosystem

来源：Simon Willison，2025 年 10 月 14 日。会过期

读它解决什么：为本地 AI 设计的专用硬件，实际用起来怎样。

要点：

• 硬件本身评价不错
• 但软件生态还很早期：驱动、框架适配、工具链都要花时间摸索

我的补充："硬件好、生态早期"这个模式在 AI 硬件上反复出现，值得当成默认预期而不是意外。

买专用硬件前，我建议算清这几件事：

• 实际使用频率有多高？ 利用率低的话云 API 几乎总是更划算——一台几万块的机器，如果每天只跑两小时，折算下来比 API 贵得多。
• 愿意花多少时间折腾生态？ 驱动、框架版本、量化格式兼容——这部分时间成本最容易被低估，可能是几十小时。
• 需求是否真的需要本地？ 隐私合规、离线、超大量推理这些理由成立；"感觉本地更酷"不算理由。
• 迭代速度。 AI 硬件两年后可能被消费级显卡追上。

我的建议顺序：除非有明确的隐私/合规要求、或者推理成本明显超过硬件成本，先用云 API；需要本地时先用手头现有的机器（Mac 的统一内存对中等模型意外好用，见第 69 条）；专用硬件放到最后考虑。

阅读原文 →

64. NVIDIA DGX Spark + Apple Mac Studio = 4x Faster LLM Inference with EXO 1.0

来源：Simon Willison，2025 年 10 月 16 日。会过期

读它解决什么：能不能把几台不同的机器拼起来跑一个大模型。

要点：

• 用 EXO 把 DGX Spark 和 Mac Studio 组合起来做分布式推理
• 报告的结果是明显的提速

我的补充：分布式本地推理的思路是把模型的不同层放到不同机器上，这样单机装不下的模型也能跑。

它真正解决的问题是"内存容量"，不是"速度"——这一点容易误解。把两台 32GB 的机器拼起来能跑一个需要 50GB 的模型，这是主要收益。速度上，因为层之间的数据要走网络，网络延迟成了新瓶颈。

实际的限制条件很硬：

• 网络带宽是关键——万兆以太网或者雷电直连才有意义，千兆网基本没戏
• 异构硬件的负载分配很难调优，快的机器会等慢的机器
• 配置复杂度不低，出问题难排查
• 只对"模型装不进单机"这个场景有意义

我的判断：这是个有意思的技术方向，但对大多数人不如"买一台内存更大的机器"或者"用更小的量化"实在。真正需要它的场景是"手头正好有几台闲置机器，且要跑一个单机装不下的模型"——这个组合不常见。

阅读原文 →

65. Using Codex CLI with gpt-oss:120b on an NVIDIA DGX Spark via Tailscale

来源：Simon Willison，2025 年 11 月 7 日。会过期

读它解决什么：怎么在一台有算力的机器上跑模型，从别的设备用它。

要点：

• 在 DGX Spark 上跑 gpt-oss:120b，通过 Tailscale 从别的设备访问
• 编程工具（Codex CLI）指向这个本地服务

我的补充：这个架构比"全都在一台机器上"合理得多：推理集中，客户端分散。 一台有算力的机器跑服务，笔记本、平板、手机都能用。

Tailscale 在这里不是可选项，是必需的。 原因很直接：本地模型服务通常没有认证机制——llama-server 默认谁都能连。直接暴露到公网等于把算力和数据都送人，而且会被扫到（这类端口的扫描很活跃）。

我自己的配置要点：

• 服务只监听私有网络接口，不监听 0.0.0.0
• 用 Tailscale / WireGuard 这类虚拟网络，让服务只在信任的设备间可见
• 加一个 API key 作为额外防护（llama-server 支持）
• 注意上传带宽——从外面访问家里的机器，瓶颈通常是家宽的上传速度
• 因为是 OpenAI 兼容接口，任何支持自定义 base URL 的工具都能接（第 61 条）

这个方案的实际体验取决于模型大小和网络：中等模型 + 局域网很流畅；大模型 + 家宽上传，首 token 延迟会比较明显。

阅读原文 →

2026 年：小模型追上来了

66. ggml.ai joins Hugging Face to ensure the long-term progress of Local AI

来源：Simon Willison，2026 年 2 月 20 日。会过期

读它解决什么：llama.cpp 背后的团队加入 Hugging Face，对本地 AI 生态意味着什么。

要点：

• ggml.ai（llama.cpp / ggml 的开发方）加入 Hugging Face
• 目的是保证本地 AI 基础设施的长期发展

我的补充：这条消息解决的是一个此前真实存在的可持续性风险。

风险是这样的：llama.cpp 是整个本地推理生态的地基——Ollama、LM Studio、以及大量应用都建立在它之上。而它此前主要由少数几个人维护。这种"关键基础设施依赖个人"的结构在开源世界里风险很大（同类的例子：core-js、OpenSSL 早期、xz——后者还引出了供应链攻击，见第五卷第 93 条）。

有机构资源之后，通常带来：更稳定的维护、更快的新硬件适配（新 GPU 出来后的支持速度）、更好的文档。

代价是路线图可能更多考虑赞助方的需求——这是这类整合的常见代价，但相比"维护者精力耗尽项目停摆"，我认为这个交换是划算的。

对使用者最实际的好处：可以更放心地把本地推理方案建立在 llama.cpp 和 GGUF 生态上。 一年前如果有人问"这个生态会不会突然没人维护"，答案是"有这个风险"；现在这个风险小了很多。

阅读原文 →

67. Gemma 4: Byte for byte, the most capable open models

来源：Simon Willison 介绍 Google 的发布，2026 年 4 月 2 日。会过期

读它解决什么：Google 新一代开放权重模型。

要点：

• Gemma 4 发布，宣传的卖点是**"按字节算最强"**——即相同体积下的能力
• Gemma 系列覆盖从能在手机上跑的小模型到需要好显卡的中等规模

我的补充："按字节算最强"这个措辞值得注意，因为它强调的是参数效率而不是绝对能力——而对本地部署来说，这才是相关的指标。

理由是：本地部署的真正约束是显存，不是模型的理论上限。 一个需要 80GB 的模型再强，装不进你的机器就等于不存在。

所以选型的正确起点是显存预算，不是榜单排名：

1. 先确定可用显存/内存（留出 KV cache 和系统占用的空间，我一般留 20–25%）
2. 算出能装下的参数量（Q4 下大约是"显存 GB 数 × 1.7 = 可用的 B 数"，粗略估）
3. 在这个范围内选几个候选
4. 用你自己的实际任务测（第 74 条）

一个常见的判断错误：宁可跑激进量化的大模型，也不用高量化的小模型。 我的经验是相反的——一个能稳定跑 Q5 的 12B，通常比勉强跑 Q3 的 27B 体验更好，因为激进量化的质量损失比参数减少的损失更明显、更不可预测。

另外注意 Gemma 的许可：相对宽松但有使用条款限制，不是标准的开源协议。商用前要读一遍。这一点在开放权重模型里很普遍——"开放权重"不等于"开源"。

阅读原文 →

68. Qwen3.6-35B-A3B on my laptop drew me a better pelican than Claude Opus 4.7

来源：Simon Willison，2026 年 4 月 16 日。会过期

读它解决什么：本地小模型和顶级云模型的差距还有多大。

要点：

• Qwen3.6-35B-A3B（总参数 35B，激活参数 3B 的 MoE 模型）在笔记本上跑
• 在他的"鹈鹕骑自行车 SVG"测试里表现超过了 Claude Opus 4.7
• 是单个测试的结果，不代表全面比较

我的补充：这条要点里"单个测试"这个限定很重要，别过度推论。 一次 SVG 生成的胜出不代表整体能力更强——这类对比在别的任务上（长上下文推理、复杂代码、多步 agent 任务）结论通常会反过来。

但真正值得注意的是趋势：本地模型已经从"只能玩玩"进入了"能干实际活"的阶段。 这个变化发生得比多数人预期的快。

MoE 架构对本地部署的价值值得单独说清，因为它改变了性价比：

• 总参数 35B 决定显存占用（要全部加载）
• 激活参数 3B 决定推理速度（每个 token 只用一部分）

这个组合对本地部署特别划算，因为内存相对便宜，算力才是瓶颈。 一个 35B-A3B 的模型：内存需求像 35B，速度像 3B。对于内存大但算力一般的机器（比如统一内存的 Mac），这是最优的架构选择。

我的实际用法：本地模型现在能胜任的——代码补全、格式转换、摘要、分类、简单重构、批量数据处理（隐私敏感的场景尤其值得）。还是明显不如顶级云模型的——复杂的多步 agent 任务、长上下文的整体理解、需要精确遵循复杂指令的场景。

阅读原文 →

69. Nativ: Run AI models locally on your Mac

来源：Simon Willison，2026 年 7 月 21 日。会过期

读它解决什么：Mac 上跑本地模型的图形界面工具。

要点：

• Nativ 让不想碰命令行的人也能在 Mac 上跑模型

我的补充：Mac 在本地模型上有个结构性优势值得理解清楚：统一内存架构。

• CPU 和 GPU 共享同一块内存，所以"显存"就是"内存"
• 一台 64GB 的 Mac 可以跑需要 40GB 的模型；PC 上要做到这一点需要一张 48GB 显存的显卡，成本差好几倍

代价也是明确的：

• 带宽和算力不如同价位的独立显卡
• 长文本的首 token 延迟（prefill）明显慢——这是最容易感受到的短板
• 生成阶段（decode）受内存带宽限制，差距相对小

所以 Mac 适合"模型大但对速度要求不极端"的场景，不适合需要高吞吐的批量推理。日常问答、代码辅助这类交互式使用，体验是够的。

Mac 上的三种选择：

• 图形界面（LM Studio、Nativ 这类）—— 适合直接上手，不想配置
• Ollama —— 命令行 + 简单的模型管理，大多数人的最佳平衡点
• llama.cpp / MLX —— 精确控制。MLX 是 Apple 自己的框架，在 Apple Silicon 上有针对性优化，某些场景比 llama.cpp 快

具体工具可能一年内就换掉，但"统一内存的容量优势 + 带宽劣势"这个判断是硬件架构决定的，不会变。

阅读原文 →

70. Qwen 3.8 27B is excellent, but it defaults to wildly overthinking things

来源：Simon Willison，2026 年 8 月 16 日。结构性

读它解决什么：推理模型"想太多"是个什么样的问题。

要点：

• Qwen 3.8 27B 质量很好
• 但默认会过度思考——简单问题也生成大量推理过程

我的补充："过度思考"是推理模型这一代的普遍问题，不是这个模型独有的，所以这一条我标了结构性。

代价很实在：

• 本地跑：时间。 一个本该一秒回答的问题花了三十秒。
• 云端跑：钱。 思考过程按输出 token 计费。
• 延迟。 交互式使用时体验很差。
• 有时候想太多反而降低质量——模型把自己绕进去，从正确答案改成错的。这是最反直觉的一点，但我确实遇到过好几次。

根本原因是训练目标的偏差：推理模型被训练成"多想能提高难题准确率"，但没有被充分训练"判断这题需不需要多想"。所以它对所有问题都用同一套重型流程。

应对手段，按有效性排：

1. 简单任务用非推理模型。 分类、格式转换、摘要、抽取——用推理模型是纯浪费。这是最有效的一条。
2. 看模型有没有提供思考预算或开关（有些模型支持 /no_think 之类的控制，或者能设思考 token 上限）
3. 本地部署时可以硬性截断思考过程
4. 系统提示里要求简洁——有一定效果但不可靠，属于第三卷第 44 条讲的那类概率性手段

我自己的做法是准备两个模型：一个快的处理日常任务，一个推理型的留给真正难的问题。判断标准很简单：这个问题我自己需要想超过十秒吗？ 不需要就用快的那个。

阅读原文 →

llm 命令行工具：把 LLM 接进 Unix 管道

71. Using LLM in the shebang line of a script

来源：Simon Willison，2026 年 5 月 11 日。会过期

读它解决什么：能不能把一个自然语言指令写成可执行脚本。

要点：

• 在脚本的 shebang 行里用 llm，让文件内容直接成为 prompt
• 于是一个"自然语言指令文件"变成了可执行的东西

我的补充：这个技巧本身是个小玩法，但它体现的设计理念很重要：LLM 应该是 Unix 工具链里的一个普通组件。

这个理念的实际价值在于组合：

# 用管道分析日志
tail -100 error.log | llm "总结这些错误的主要类型"

# 生成提交信息
git diff --staged | llm "写一个简洁的 commit message"

# 结构化输出接给别的工具
cat data.txt | llm --schema '{...}' | jq '.items[]'

这些都不需要为每个需求单独写程序——LLM 只负责需要语义理解的那一步，其余交给已有的工具。

但有个坑必须说清楚：LLM 在管道里的输出是不确定的。 同样的输入可能得到不同的结果和格式。所以：

• ✅ 交互式探索、一次性分析 —— 很适合，输出你自己看
• ⚠️ 放进自动化流程 —— 下游必须能容忍格式变化，或者用 JSON schema 这类结构化约束（llm --schema）
• ❌ CI 里的关键环节 —— 不稳定的环节会导致间歇性失败，而间歇性失败是最难调试的一类问题
• ❌ 幂等性重要的场景 —— 绝对不要根据 LLM 输出决定是否删除数据

阅读原文 →

72. Datasette Agent

来源：Simon Willison，2026 年 5 月 21 日。会过期

读它解决什么：给数据探索工具加上 agent 能力。

要点：

• 给 Datasette（他的开源数据探索工具）加 agent，让自然语言查询和数据探索结合

我的补充：数据库 + agent 是个天然的组合，因为 SQL 对很多人是门槛，而"用自然语言问数据"的需求极其普遍。 但它同时是高风险场景，安全边界必须先划清。

我认为的最低要求：

• 只读连接。 不是"人工审查生成的 SQL"，而是从连接权限上就不可能写（对应第三卷第 45 条的 Supabase 案例）。
• 注意数据库内容本身可能不可信——用户填写的字段是注入入口。
• 查询结果进上下文后，如果包含敏感数据而 agent 又有外发能力，三要素就齐了（第三卷第 43 条）。
• 限制查询开销——防止 SELECT * 拖垮数据库或者塞满上下文。加 LIMIT、加超时。

产品角度最实在的一条做法：把 agent 生成的 SQL 展示给用户。 好处有三个：

1. 用户能验证逻辑对不对——这对自然语言转 SQL 的准确性至关重要，因为错的 SQL 也会返回数据，看起来一切正常
2. 用户能顺便学会 SQL
3. 出错时能定位问题

反过来，"隐藏 SQL 只给结果"是危险的做法——因为错误的数据比没有数据更具误导性，而用户没有任何线索能发现它错了。

阅读原文 →

73. datasette-llm-limits 0.1a0

来源：Simon Willison，2026 年 5 月 15 日。会过期

读它解决什么：给公开部署的 LLM 功能加用量限制。

要点：

• 一个给 Datasette 里的 LLM 功能加限制的插件

我的补充：任何暴露在网络上的 LLM 功能都必须有限流，这不是可选项。 否则你的 API key 会被陌生人的请求烧掉。

我见过的实际案例：一个没加限制的演示站点一晚上花掉几百美元——因为它被当成了免费的 LLM 代理。这类滥用会被自动化脚本发现，速度比你想的快。

需要限制的维度：

• 单用户 / IP 的请求频率
• 单次请求的 token 上限（输入和输出都要限，否则会被超长上下文刷成本——这一条最容易漏）
• 总体预算上限（按天/月）
• 并发数

实现时的坑：

• IP 限流容易被绕过（代理、IPv6 段），重要场景需要登录验证
• 限流状态必须持久化——存内存的话进程重启就清零了
• 限制要在调用 API 之前生效，不是事后统计
• 最关键的一条：设置账单告警作为最后防线。 代码可能有 bug，但账单不会骗人。所有云厂商都支持预算告警，一定要配。

"公开的 LLM 功能必须限流"这个原则是长期有效的，具体插件版本会变。

阅读原文 →

74. smevals—a small eval suite for evaluating models, prompts, and harnesses

来源：Simon Willison，2026 年 7 月 31 日。结构性

读它解决什么：一个足够小、能真的用起来的评测工具。

要点：

• smevals 同时评测三个维度：模型、prompt、harness
• 定位就是"小"——不追求全面，只要能用起来

我的补充："一个能跑起来的小评测，比一个全面但没建起来的评测有用得多。" 这一条我认为是这半卷里最实用的。

同时评测三个变量这一点很关键，因为它们的效果混在一起：换模型、改 prompt、改 harness 都会影响结果。不分开测，你根本不知道某次"感觉变好了"是哪个因素起的作用。

我遇到过的一个具体坑：为老模型精心调过的 prompt，换新模型后反而成了负担——那些"请一步一步思考"之类的引导，在推理模型上是多余甚至有害的。如果不做对照测试，你会以为是新模型不行。

我自己用的最小可用评测方案：

1. 从真实使用里积累 10–20 个案例。 必须是真实的——构造的案例测不出真问题。
2. 每个案例定一个能自动判定的成功标准：包含某字符串 / 通过某测试 / JSON 能解析且字段完整 / 命令返回 0。
3. 每次改动前后各跑三遍比通过率。 三遍是为了看方差——如果方差比你想测的差异还大，结论无效（对应第二卷第 36 条）。
4. 把失败的案例存下来。 这是最有价值的资产——积累到一定数量后，这个集合本身就是你系统的规格说明。

搭这套东西的门槛比大多数人想的低——一个下午就能搞定，之后每次改动都受益。不搭的代价是所有优化都在瞎猜。

阅读原文 →

75. llm-coding-agent 0.1a0

来源：Simon Willison，2026 年 7 月 2 日。会过期

读它解决什么：llm 生态里的编程 agent 插件。

要点：

• 一个早期 alpha 版本的 coding agent 插件

我的补充：这一条真正值得学的不是这个插件，而是 llm 的插件架构本身。

架构是这样的：核心层保持精简——只负责 prompt 构造、模型调用的抽象、对话历史存储、插件加载。所有模型支持都是插件（llm-anthropic、llm-gemini、llm-ollama……），所有功能扩展也是插件。

这带来的实际好处：切换模型只需改一个参数，你的脚本、模板、工作流完全不用改。

llm -m claude-opus-5 "..."
llm -m gemini-3-pro "..."
llm -m ollama/qwen3.8:27b "..."   # 本地模型，同样的接口

最后一行是关键：本地模型和云模型用完全一样的接口。 这把这一卷的前后两半连起来了。

从这个设计里能提取一条通用原则：把"会变的东西"隔离到插件层。

在 LLM 项目里：

• 会变的：模型、API 格式、参数名、定价
• 不变的：你的业务逻辑、prompt 模板、工作流

把这两者混在一起是我见过最常见的架构错误——每次模型换代就得改一遍业务代码。而在这个领域，模型换代是几个月一次的事。

阅读原文 →

76. llm-mcp-client 0.1a0

来源：Simon Willison，2026 年 7 月 31 日。会过期

读它解决什么：让 llm 能连接 MCP 服务器。

要点：

• 一个让 llm 作为 MCP 客户端的插件
• 于是 llm 能用任何 MCP 服务器提供的工具

我的补充：MCP 的真正价值是把"给 agent 加工具"从 M×N 降到 M+N。 M 个客户端、N 个工具服务器，有了统一协议就能互相接，不需要每对组合单独适配。

但在命令行环境里接 MCP，安全风险比在其他环境高，这一点必须说清：

命令行环境的特点是凭证密度极高——~/.aws/credentials、SSH 私钥、各种环境变量里的 token、.env 文件、~/.config 下的各种配置。而且用户通常有完整的文件系统权限。加上配置 MCP 服务器很简单（加几行配置就行），第三卷第 43 条的三要素在命令行场景下特别容易凑齐——比如你同时接了一个"读网页"的 MCP 服务器。

我的做法：

• 按会话需求选择性接入，不要全部常开。这一条最有效。
• 每次接入前检查：有没有同时引入"不可信内容"和"能外发"的工具（第三卷第 54 条的染色规则）
• 明确排除凭证目录不让 MCP 访问
• 处理外部内容时在容器或独立用户账号里跑
• 审查 MCP 服务器的来源——第三方 MCP 服务器本质上是在你机器上执行的代码，和装一个来源不明的 npm 包风险相同

阅读原文 →

77. Stateless MCP has recaptured my interest (and inspired mcp-explorer and datasette-mcp)

来源：Simon Willison，2026 年 7 月 31 日。结构性

读它解决什么：MCP 的无状态用法为什么更好。

要点：

• 无状态的 MCP 用法重新引起他的兴趣
• 启发了 mcp-explorer 和 datasette-mcp 两个项目

我的补充：无状态在分布式系统里已经是成熟结论，MCP 同样受益。 好处逐条说：

• 部署灵活——可以随意水平扩展，任何实例都能处理任何请求
• 调试容易——能单独重放一个请求，这在 agent 开发里价值极高，因为 agent 的问题往往出现在几十步之后
• 避免状态污染——上一个会话的残留状态不会影响下一个
• 测试简洁——不需要构造复杂的前置状态
• 安全性更好——没有跨请求的状态可以被利用

代价是每次请求要携带完整上下文，有重复开销。 但对工具调用这种短交互场景来说，这个成本基本可以忽略——工具调用的参数通常很小。

和第二卷第 40 条（brain/hands 解耦）是同一个思路：让执行层无状态，状态集中管理。这样执行层可以随意扩缩、重启、隔离。

"随意重启"这一点对 agent 系统的稳定性帮助特别大——它让"卡住了就重启"变成一个安全可靠的恢复手段，而不是一个可能丢状态的危险操作。

阅读原文 →

78. llm-chat-completions-server 0.1a0

来源：Simon Willison，2026 年 7 月 30 日。会过期

读它解决什么：让 llm 反过来当服务端。

要点：

• 一个插件，让 llm 提供 OpenAI 兼容的 HTTP 接口
• 于是任何支持 OpenAI API 的客户端都能访问 llm 支持的所有模型

我的补充：这个设计很巧妙，因为它把 llm 的角色反转了——从客户端变成适配层。

效果是：任何只支持 OpenAI API 的工具，突然就能用上 Anthropic、Gemini、本地 Ollama 等所有模型了。

我用这类适配层解决过的实际问题：

• 让某个只支持 OpenAI 的工具能用 Claude（最常见的需求）
• 统一多个模型的调用日志和成本统计——所有请求都过一个点
• 本地开发时指向本地模型省钱，生产时切回云模型
• 给重复的 prompt 加缓存

更大的观察：OpenAI 兼容接口已经事实上成了这个领域的通用协议。 llama.cpp 的 server 提供它（第 61 条）、vLLM 提供它、几乎所有推理框架都提供它。

推论：做 LLM 相关服务时，提供一个 OpenAI 兼容接口能立刻接入整个生态。 这个兼容性的价值远大于设计一套"更好的"接口——接口设计得再好，没有客户端支持就是零。

阅读原文 →

79. condense-json 1.0

来源：Simon Willison，2026 年 8 月 2 日。会过期

读它解决什么：JSON 在 LLM 上下文里太占 token，怎么压。

要点：

• 一个压缩 JSON 的库，1.0 版本

我的补充：JSON 的 token 效率确实很低，在长上下文场景下这个成本很明显。

浪费主要来自重复的字段名——数组里每个对象都要重复一遍所有 key。

一个具体的量级：100 条记录、每条 10 个字段、字段名平均 8 字符 → 仅字段名就重复了 8000 字符，约 2000+ token，而实际数据可能还没这么多。

各种方案的实际效果，按收益排：

1. 只传需要的字段 —— 收益最大且没有副作用。我的经验是数据里通常有一半字段根本不需要。
2. 换成 CSV / TSV —— 字段名只出现一次，省掉所有结构字符。表格数据的最优选择。
3. 紧凑 JSON（去掉缩进和空格）—— 省 10–20%，零成本，应该默认做
4. 压缩工具（如 condense-json）—— 在上面几步做完之后的额外优化
5. 缩短字段名 —— 有效但会降低模型的理解质量，因为 usr_nm 不如 user_name 明确。不推荐。
6. YAML —— 比 JSON 省一点，但生成时容易出格式错误。读可以，写不建议。

优先级建议：先砍字段，再换格式，最后才考虑压缩工具。 大多数人跳过前两步直接找压缩工具，收益反而小。

阅读原文 →

80. New release of LLM adds support for reasoning traces, OpenAI Responses, server-side tools, and smarter logging

来源：Simon Willison，2026 年 8 月 4 日。会过期

读它解决什么：llm 0.32 的新能力，以及它们对应的 API 层变化。

要点：

• 推理轨迹（reasoning traces）支持
• OpenAI Responses API 支持
• 服务端工具（server-side tools）
• 更智能的日志记录

我的补充：这四项各自对应一个实际问题，值得分开说：

推理轨迹：能看到模型的思考过程，用于调试、成本分析（第 70 条讲的过度思考，看轨迹才能知道它浪费在哪）、理解判断依据。

OpenAI Responses API：这一项的副作用是**"OpenAI 兼容"这个事实标准出现了分叉**——现在要问"兼容哪个版本"。对第 78 条讲的适配层生态是个麻烦。

服务端工具：省去自己实现和托管工具的麻烦。代价要想清楚：数据要经过服务商、对工具行为没有控制权、出问题无法调试。而且第三卷第 43 条的判断仍然适用——服务端的搜索工具同样引入不可信内容和外发通道，不因为跑在别人那儿就变安全了。

更智能的日志记录：这一项最容易被忽略但最实用。

原因是：LLM 应用的调试严重依赖日志，因为输出不确定，你无法靠重跑来复现问题。必须记完整的：prompt 原文、所有参数、返回内容、token 数、耗时、模型版本。

日志不全的 LLM 项目基本无法调试——你只能看到"结果不对"，看不到为什么。这是我在实际项目里反复确认的一点：llm 默认把所有对话记进 SQLite，这个设计在排查问题时价值极大。

阅读原文 →

---

本卷小结：61–70 条是本地模型与硬件（第 61 条的量化取舍表和第 62 条的服务商不一致是最实用的两条）；71–80 条是 llm 工具链（第 74 条最小评测和第 75 条插件架构是最有长期价值的两条）。

这一卷过期最快，但有四条不会过期：第 62 条（同名模型跨服务商不一致）、第 71 条（LLM 作为管道一环的不确定性风险）、第 74 条（最小评测怎么搭）、第 75 条（把会变的东西隔离到插件层）。型号和版本号会换，这四条讲的是方法。

---

上一卷： ← ③ Agent 安全与 Prompt Injection · 总览： 工具资料库 · 下一卷： ⑤ 编辑器、工具链与工程实践 →