夜雨聆风一句话总结：当 AI 工具开始服务多个模型、多个任务和多个用户时，最危险的不是调用失败，而是上一轮任务的配置悄悄影响了下一轮。
很多 AI 工具一开始都很简单：选一个模型，设几个参数，输入一段提示词，然后得到结果。
但只要工具进入真实工程环境，配置就会迅速变复杂。
同一个项目可能要切换不同模型；不同任务要使用不同密钥；嵌入模型和生成模型的权限不一定相同；有些任务需要高推理强度，有些任务则更在意速度和成本。
如果这些设置都依赖一个“当前全局状态”，系统迟早会出现一种很难排查的错误：代码没有坏，结果也能返回，但它用的不是你以为的那套配置。
llm 0.33 暴露了一个重要方向
Simon Willison 在介绍 llm 0.33 时提到几个看似细小的变化：嵌入相关命令可以按调用传入 --key，Python API 的嵌入方法也接受 key=，而且不会改变共享模型状态；模板则可以重复组合，把模型和默认选项封装起来，再与具体提示词叠加使用。
这些变化不只是命令行工具的功能更新。
它们共同指向一个工程原则：身份、能力、策略和任务内容，应该在每次调用时清楚地组合，而不是依赖一个隐含的全局设置。
为什么“每次调用”比“全局配置”更可靠
全局配置适合单人、单任务、单模型的早期阶段，因为它足够方便。
但 Agent 运行起来之后，一次调用可能代表一个客户、一个工作流或一个权限边界。此时，把密钥或模型选项留在共享状态里，就会产生三个风险。
风险一：凭证边界不清楚
一个任务切换了密钥，另一个任务可能无意中复用了它。即使最终没有泄露，审计也会变得困难：到底是哪一次调用使用了哪一组凭证？
风险二：参数互相污染
上一轮为了复杂任务打开的高推理选项，可能被下一轮低延迟请求继承。系统表现出来像“模型忽然变慢了”，但根因其实是配置没有隔离。
风险三：重试无法复现
如果调用依赖运行时的共享状态，失败之后很难重现原来的环境。工程师看到的只是“同样的请求”，却无法确认当时的模型、密钥和默认参数是否完全一致。
把一次 AI 调用拆成四层
一个更稳的设计，可以把调用配置分成四层：
身份：这次请求使用谁的密钥、什么权限； 能力：使用哪个模型、哪个嵌入模型或哪个工具； 策略：推理强度、摘要长度、超时和重试方式； 任务：这一轮具体要解决的问题和输入内容。
模板适合承载相对稳定的能力与策略，调用参数负责注入当前身份和任务，最终执行前再把四层配置记录下来。
这样做的好处不是“代码更漂亮”，而是每一次结果都可以回答三个问题：它用的是什么、为什么这样用、出了问题能不能重放。
给 Agent 系统的三个实践建议
不要让共享对象保存临时凭证
凭证应当随着调用传入，并在调用结束后自然失效。这样更容易做权限控制，也更容易测试多租户场景。
用模板封装策略，不要把策略藏进代码
模型、推理强度和输出格式可以被保存成可组合模板，但具体任务应该保持独立。这样，团队能复用经验，也不会把某个项目的特殊要求污染所有请求。
记录“生效配置”，不要只记录用户输入
日志里除了提示词，还应该保存最终使用的模型、调用身份、模板组合和关键选项。出了问题时，真正需要复盘的是生效配置，而不是原始意图。
AI 工具的竞争，正在从“能不能调用模型”进入“能不能可靠地管理调用”。
对个人开发者来说，这是减少隐性错误的工程习惯；对企业 Agent 来说，这是权限、成本和可审计性的基础。
一个小版本里加入的 per-call key 和可组合模板，提醒我们：模型能力越强，配置边界越不能含糊。
参考资料：Simon Willison，《Release: llm 0.33》。