开源 LLM 代理：读源码，更要验证运维开源 LLM 代理：代码与运维
从许可证、架构、运维和生产证据评估开源 LLM 代理，而不是只看仓库热度。
速览
与法务确认许可、Notice、依赖、商业使用、再分发、商标与企业功能边界。
发布节奏、维护者响应、贡献者多样性、Issue 关闭、安全策略与升级说明能揭示运营风险。
如果工具、流、结构化输出、用量、错误与新 API 面行为不一，再长的供应商列表也意义有限。
部署、密钥、高可用、数据库、遥测、备份、升级、事故响应与支持仍由团队承担。
开源项目暴露不同产品边界
LiteLLM 是广泛代理与 Python SDK；Bifrost 强调高性能网关与 Go SDK；Portkey 发布开放网关并提供更广托管套件；Kong 网关有开源核心与大型插件/平台生态，但 AI 能力及版本要求必须精确核对。
其他项目可能专注可观测性、缓存、本地推理或窄协议。不要假设开放仓库包含产品页展示的所有云功能；评估时应固定具体仓库、Commit、许可、版本、二进制与部署路径。
开源代理候选
| 项目 | 最适合 | 选择前验证 |
|---|---|---|
| LiteLLM | 广泛供应商转换、代理端点、Python SDK、路由、密钥、预算与扩展性。 | 固定版本并测试适配器、数据库、高可用、安全、遥测、性能、支持与升级路径。 |
| Bifrost | 基于 Go 的可自托管网关，提供统一 API、供应商路由、回退、负载均衡与治理控制。 | 验证仓库许可、协议/供应商覆盖、集群与状态行为、安全流程、支持与成熟度。 |
| Portkey 网关 | 与 Portkey Config、路由及护栏生态对齐的开放网关框架。 | 区分仓库功能与托管可观测、提示词、管理、护栏、托管和支持。 |
| Kong 网关 Core | 成熟网关核心、声明式配置、Ingress 与插件模型，适合已运营 Kong 的团队。 | 逐项核对所需 AI 插件、控制平面功能与部署能力的具体许可与版本。 |
| 窄范围社区代理 | 小型项目可用较低复杂度满足简单转换、本地开发或特定供应商路径。 | 评估 Bus Factor、发布节奏、CVE、协议测试、可观测性、迁移，以及团队能否成为维护者。 |
上线前检查十类证据
仓库许可、依赖许可、CLA、Notice、商标、商业使用及哪些功能不在开放项目中。
维护者、贡献者多样性、Issue 响应、发布频率、Changelog 质量、语义版本与升级说明。
安全策略、私密披露、CVE 处理、依赖更新、签名、SBOM、密钥扫描与加固指南。
针对端点、工具、结构化输出、流、用量、错误、推理、文件与多模态行为的契约测试。
资格、优先级、健康、重试、超时、熔断、防重复、缓存与每个决策的证据。
部署、状态、高可用、扩缩、备份、灾备、升级、回滚、遥测、保留、值班、支持与总成本。
使用开放工程生产门禁
- 部署前阅读架构、配置、数据模型、安全策略、版本说明与近期高严重度 Issue。
- 为每个生产供应商、端点、功能与故障不变量构建单元及一致性测试。
- 压测真实流式与工具；分析 CPU、内存、连接、队列、数据库与遥测反压。
- 对供应商、副本、数据库、控制平面、陈旧配置、无效密钥、升级与恢复做故障演练。
- 记录已接受风险、分配负责人、定义 SLO 与回滚，并让每次发布通过同一门禁。
冻结被评估制品及其证据
为具体源码 Commit 与构建镜像创建 SBOM，签名镜像、固定依赖并记录配置结构定义。把一致性结果、性能 Profile、威胁审查、部署清单、备份证明与 Runbook 同版本保存；仅通过已评审环境发布，并保留上一签名镜像及兼容数据备份用于回滚。
生产规则：开源提升可检查性；运营信任来自可复现制品、已验证行为与有人负责的 Runbook。
LLM 代理不是智能体能力注册表
开源 LLM 代理标准化并治理模型推理；QVeris 通过 Discover、Inspect、调用补充外部 API、工具、服务与实时数据。代理控制推理供给，QVeris 控制现实能力的选择与执行。
FAQ
许可可能允许免费使用，但基础设施、数据库、遥测、安全、升级、值班、支持与事故仍有成本。
与法务审查具体仓库 Tag、依赖、Notice 与功能边界，不要只依赖营销标签。
成熟度与负载相关；应比较发布、安全、测试、升级、Operator、支持与自身生产验证。
仅当能力值得长期 Rebase、安全修复、测试与责任时 Fork；条件允许时优先向上游贡献。