是时候使用 llm:// 连接字符串了
简化模型与提供者配置,使用 llm:// URL
更新: 这篇文章促成了一个针对
llm://URI 方案的 Internet-Draft。
还记得过去连接数据库时要把一堆杂七杂八的环境变量弄得七零八落的日子吗?
那是一座脆弱的配置塔。DB_HOST、DB_PORT、DB_USER、DB_PASSWORD、DB_NAME……等等,或者是 DB_USERNAME?是 DB_PASS 还是 DB_PWD?这次还需要 PG_* 前缀吗?超时设置到底该放哪?
这座纸牌屋随时可能因忘记把 HOST 大写而崩塌,直接把生产构建拉垮。
后来,有人灵机一动,直接用 URL¹:
postgres://user:pass@host:5432/dbname一行字符串,所需信息全都有。通用可解析,跨平台。敢说……漂亮?
那我们为什么还把 LLM 当成 1999 年的老古董来对待?
环境变量的爆炸
现在我的 .env 文件看起来像一片被遗弃的 API 密钥墓地。OPENAI_API_KEY、ANTHROPIC_API_KEY、MISTRAL_API_KEY、GROQ_API_KEY。更别提 Azure 了——光是说声 “hello” 就得配置端点、部署名称、API 版本和密钥。
这不仅难看,更是摩擦点。每次想换模型或测试新供应商,我都得改写初始化代码,去翻特定参数名的文档,还要往环境配置里再添三行。
如果我们直接… 偷走 借用一下数据库 URL 的思路?
引入 LLM 连接字符串
想象一下,用一行就能配置整个模型接口:
llm://api.openai.com/gpt-5.2?reasoning_effort=none&temp=0.7&max_tokens=1500llm://api.z.ai/glm-4.7?top_p=0.9&cache=trueLLM 连接字符串的结构
方案是 llm://。主机是供应商的 API 基础 URL。路径是模型名称。查询参数负责处理所有通常会把代码弄得乱七八糟的运行时选项。
需要认证?很好,直接加进去。
就像 postgres:// 一样,我们可以把认证信息直接写进 URL:
llm://app-name:sk-proj-123456@api.openai.com/gpt-5.2?reasoning_effort=none&temp=0.7注意:是的,把凭证写进 URL 确实有泄露风险,尤其是当你把它们粘贴到公开日志里时。不过现代日志服务已经相当擅长清除这类模式,老实说,你的 .env 文件真的管理得更好吗?请务必验证、清理,并谨慎使用。
弹性?为什么不可以。
许多数据库库通过指定多个主机实现轮询故障转移。我们的 AI 代理为什么不能拥有同等的可靠性?
llms://primary.gpt,backup.gpt/gpt-6?temp=0.9llms:// 里的 s 并不是拼写错误,而是复数形式。如果 primary.gpt 卡住,客户端会自动重试 backup.gpt。不需要复杂的路由逻辑。
一个字符串就能囊括 auth、endpoint 和 hyperparameters 的全部信息。
替代格式
我并不执着于 llm://。具体的 scheme 并不重要,关键是统一的标准。
我可以想象一种使用供应商专属 scheme 以求简洁的世界,同时保持标准结构:
ollama://localhost:11434/llama3vercel://anthropic/sonnet-4.5?temp=0.8&web_search={"maxUses":3}bedrock://us-west-2.aws/anthropic/sonnet-4.5?temp=0.8&cacheControl=ephemeral不论语法细节如何,核心收益都是显而易见的:
- 可移植性: 将完整配置复制粘贴,从本地脚本到云端 worker 都能直接使用。
- CLI 友好: 向脚本传递单一参数。
my-agent --model "llm://..."胜过my-agent --model gpt-4 --temp 0.7 --key $KEY --host ...。 - 语言无关: 每种编程语言都有成熟的 URL 解析器。我们免费获得验证、解析和清理功能。
数据库行业花了数十年才弄清楚这件事。
好消息是,在 AI 时间线里,这只相当于半个 vibe-year 前的事。
判定
我们不需要再引入另一个复杂的配置标准或全新的基于 YAML 的清单文件。我们只需要使用过去 30 年里一直为整个互联网服务的同一个工具。
别再重复造轮子了,应该像对待数据库那样尊重我们的 LLM 连接。你的 .env 文件(以及你的理智)会感谢你的。
