当我们需要同时对接 OpenAI、Anthropic Claude、Google Gemini 等多个 LLM 提供商时，管理和维护这些 API 调用很快会变成一场噩梦。每个提供商都有自己独特的认证方式、速率限制、错误格式和响应结构，更不用说它们在模型能力、定价策略和可用性上的差异了。传统的做法是为每个提供商编写独立的客户端代码，然后在业务逻辑中根据模型名称进行条件判断和路由分发。这种方式在模型数量较少时或许可行，但随着团队使用的模型数量增加到数十个，这种分散式的代码结构会迅速膨胀，重复代码遍地，错误处理逻辑碎片化，维护成本呈指数级上升。LLM 时代的 API 组合实践，本质上是要解决这种异构多模环境下的一致性调用问题。
统一的命令行接口（CLI）是解决这一问题的关键入口。开源工具 llm（来自 Datasette 团队）提供了一个令人印象深刻的解决方案：它将 OpenAI、Anthropic、Google、Meta 等主流提供商的 API 封装成统一的命令行接口，用户只需掌握一套命令语法，即可无缝切换不同模型进行对话。这种设计理念的核心价值在于「接口抽象」—— 它将底层实现细节隐藏起来，只暴露简洁的输入输出契约。对于开发者而言，这意味着可以像使用普通 Shell 工具一样调用任何 LLM，将输出通过管道传递给其他命令，或者在脚本中捕获结果进行后续处理。更重要的是，统一的接口使得错误处理逻辑可以集中实现，当某个提供商出现服务中断时，可以快速切换到备用模型，而无需修改业务代码。
插件架构是 CLI 工具实现可扩展性的核心机制。以 llm 为例，它提供了完善的插件钩子系统，开发者可以通过编写简单的 Python 插件来添加新的模型提供商、嵌入模型或自定义工具。这种松耦合的设计意味着社区可以持续贡献对新兴模型的支持，而核心工具本身无需频繁更新。对于企业内部而言，插件机制还提供了定制化的空间 —— 团队可以将内部模型、私有部署实例或特定领域的提示模板封装成插件，供内部工具链统一使用。关键配置参数包括插件安装路径（通常为 ~/.llm/plugins/）、插件优先级（决定同名模型的路由顺序）以及插件超时设置（建议控制在 30 秒以内）。
多模型路由策略是生产环境中的核心挑战。简单地按模型名称路由只是最基础的需求，更复杂的情况包括：基于请求特征的智能路由（根据输入长度、任务类型或成本预算选择模型）、基于可用性的自动故障转移（当主模型响应超时或报错时自动切换到备用模型）以及基于成本的动态选择（在结果质量相近时优先使用更便宜的模型）。实现这些策略需要建立统一的路由配置层，通常采用 JSON 或 YAML 格式定义路由规则。例如，可以配置当 prompt 长度超过 2000 token 时自动使用支持更长上下文的模型，当请求失败率超过阈值时触发告警并暂停向该模型发送请求，以及设置每日调用配额来控制成本。路由匹配算法建议采用优先级队列模式，允许规则重叠时按预设优先级确定最终路由目标。
错误重试机制直接决定了系统的鲁棒性。LLM API 调用可能因为网络抖动、速率限制、服务端错误或模型过载而失败，完善的重试策略应当覆盖这些场景。首先需要区分「可重试错误」和「不可重试错误」：429 状态码（速率限制）和 5xx 服务器错误通常值得重试，而 401（认证失败）或 400（请求参数错误）重试无意义。重试间隔建议采用指数退避策略，初始延迟 1 秒，最大延迟 32 秒，最大重试次数设为 3 到 5 次。对于流式响应场景，重试时需要特别注意断点续传问题 —— 如果请求已经接收了部分响应，重试时应当能够从断点继续，而非从头开始，这需要在应用中维护请求偏移量状态。监控指标应包括重试率（建议控制在 5% 以下）、首次成功率（目标 95% 以上）以及平均重试延迟（目标 2 秒以内）。
流式响应封装是提升用户体验的重要手段。当用户输入一个复杂问题时，他们通常希望看到模型「边思考边输出」的效果，而非等待完整响应后才看到结果。Server-Sent Events（SSE）是实现流式输出的标准协议，LLM 提供商普遍支持这一机制。在 CLI 工具中封装流式响应时，关键参数包括连接超时（建议 10 秒）、读取超时（建议保持长连接但设置 5 分钟空闲超时）以及缓冲区大小（建议 1024 到 4096 字节）。流式解析需要处理 JSON Lines 格式或自定义的分块协议，提取每个 chunk 中的内容增量并实时输出。对于需要完整响应才能进行后续处理的场景，可以将流式输出暂存到内存缓冲区，待流结束后再进行解析。值得注意的是，流式响应的错误处理比同步请求更复杂 ——Connection Reset 错误可能发生在流的任意位置，应用需要有状态恢复机制来处理这类情况。
在工程实践中，我们还需要关注安全性与合规性。CLI 工具通常会将 API 密钥存储在配置文件或环境变量中，这些敏感信息必须妥善保护。建议使用系统的密钥管理服务（如 macOS Keychain、Windows Credential Manager 或 HashiCorp Vault）来存储密钥，而非明文写入配置文件。CLI 的命令历史也可能泄露敏感信息，应当将包含 API 密钥的命令自动排除出历史记录，或使用 HISTIGNORE 环境变量设置过滤规则。对于企业部署场景，还需要在网络层面设置出站策略，确保 API 请求只能流向经过审批的提供商域名，防止数据泄露风险。
从工具选型的角度，团队应当根据自身需求在「通用 CLI 工具」和「定制化解决方案」之间做出选择。通用工具如 llm 适合快速上手、多模型探索或脚本自动化场景，它们提供了开箱即用的体验，但定制化空间有限。定制化解决方案则适合有特殊需求的团队 —— 例如需要深度集成内部系统、实现复杂的成本核算逻辑或满足特定的合规要求。折中方案是在通用工具基础上开发插件或包装脚本，既利用了成熟的基础设施，又保留了定制能力。无论选择哪种路径，关键是要建立统一的抽象层，将模型差异和调用细节隔离在低层，让业务逻辑能够以一致的方式使用任何 LLM 能力。
资料来源：LLM CLI 工具官方文档（https://llm.datasette.io/en/latest）。