# 如何用证据型评分卡评估 AI Gateway

> 最可靠的 Gateway 评估是可复现测试工具，而不是供应商功能数量。应评分系统真实需要的协议、模型、失败、证据、数据控制与运维职责。

_发布 2026-08-15 · 更新 2026-08-15 · [KeepRouter Editorial](https://keeprouter.com/editorial-policy#editorial-team) · 10 分钟阅读_

![覆盖契约、证据、失败、安全与运维的 AI Gateway 评估表](https://keeprouter.com/editorial/blog/evaluate-ai-gateway.png)

_有效评估为每个必需工作负载记录证据、负责人和回滚条件。_

**先给结论：**评估 AI Gateway 时，应让一套固定、接近生产形态的真实请求样本通过候选平台，并为协议一致性、模型资格、可靠性、可观测性、成本归因、数据控制与运维责任留下通过/失败证据。公开功能表适合初筛，但不是验收证据。

先选择一个有边界的工作流，例如带流式与一个幂等工具的服务端文本端点。对捕获请求脱敏，定义结构与质量断言，并保留旧路由。只有这一小片通过后才扩大范围。

## 证据型评分卡

| 维度 | 必需证据 | 典型失败条件 |
| --- | --- | --- |
| 协议 | 覆盖每个消费字段的请求/响应 Fixture | 字段被丢弃、改名或静默转换 |
| 模型资格 | 当前目录或 API 结果，加有范围的冒烟证据 | 路由存在，但所选模型拒绝该端点 |
| 流式 | 包含取消与中途失败的有序事件日志 | UI 卡住，或把错误当作成功结束 |
| 工具 | 完整工具调用与工具结果记录 | 参数形态变化或副作用重复执行 |
| 可靠性 | 重试/回退策略与注入失败结果 | 不可重试错误被重复，或回退越过未批准模型 |
| 可观测性 | 可关联的应用、Gateway 与账单记录 | 请求无法追溯到负责人、模型、结果与用量 |
| 成本控制 | Key 范围、输出上限、尝试上限与告警测试 | 单个任务能产生无边界尝试或输出 |
| 数据控制 | 日志、保留、区域与脱敏配置 | 敏感内容违反策略进入日志 |
| 运维 | 部署、升级、事故与回滚手册 | 只有一个人知道怎样恢复服务 |

## 比较运行模式，而不只比较 API

托管 Gateway、BYOK 控制面和自托管代理可能暴露相似请求形态，但责任分配完全不同。Cloudflare 记录了带分析与流量控制的 Gateway 层；Portkey 记录 Gateway 配置与治理能力；LiteLLM 记录需要团队自行部署运维的代理服务；OpenRouter 记录托管统一 API 与供应商路由控制。KeepRouter 的公开路由以 [OpenAPI](/api/openapi.json)为准，当前模型资格以[模型目录](/models)为准。

逐项询问谁负责供应商账户、凭证、账单核对、Gateway 可用性、升级、安全补丁、数据保留、模型上架和事故响应。费率表上看似便宜的部署可能运维成本很高；托管服务可减少运维，却需要不同的信任与数据审查。把这些写成职责，不要写成营销形容词。

## 分四阶段运行测试工具

1. **静态检查。** 阅读 OpenAPI、模型详情、状态、安全、限制与错误文档；未知项就明确记录为未知。
2. **本地契约测试。** 用脱敏 Fixture 将测试客户端指向每个候选，断言字段、事件、工具、usage 与错误类别。
3. **注入失败测试。** 覆盖错误凭证、不支持字段、限流、超时、取消、重试耗尽与合格回退，绝不触发破坏性工具。
4. **有限生产灰度。** 路由一个小而可逆的切片，设置明确质量、延迟、错误与成本门槛，并与同一基线工作负载比较。

先用 [AI Gateway 基础指南](/zh/blog/ai-gateway-guide)定义范围，再用[路由与负载均衡](/zh/blog/llm-routing-vs-load-balancing)审查策略，用 [OpenAI 兼容迁移清单](/zh/blog/openai-compatible-api-migration-checklist)测试客户端行为。KeepRouter 的[功能页](/zh/features)、[状态页](/status)与[安全页](/security)分别证明不同层面，任何一个都不能替代生成链路结果。

## 边界：验证与路由、模型、账户和时间相关

通过一次 GET、健康页或 OpenAPI 路径，只能证明当时的结构或可达性；不能证明你的 Key 能调用指定模型，也不能证明工具往返正确或回退保持质量。反过来，一次失败也可能来自账户范围或载荷错误，而不是全局故障。每份证据都应标注时间、路由、模型、Key 范围、可用时的构建版本和测试用例，让评审者清楚它究竟证明了什么。

## 常见问题

### 功能对比表可以直接选出 AI Gateway 吗？

它可以用于初筛。最终验收应来自对具体契约、工作负载、数据策略和运维责任的可复现测试。

### 健康检查能证明生成路由正常吗？

不能。它只证明当时的健康检查界面；模型资格、认证、协议与用量证据仍需有范围的生成测试。

## 参考的一手资料

_本文最近复核 2026-08-15_

1. [Cloudflare AI Gateway documentation](https://developers.cloudflare.com/ai-gateway/)
2. [Portkey AI Gateway documentation](https://portkey.ai/docs/product/ai-gateway)
3. [LiteLLM documentation](https://docs.litellm.ai/)
4. [OpenRouter quickstart](https://openrouter.ai/docs/quickstart)
5. [KeepRouter OpenAPI](https://keeprouter.com/api/openapi.json)

## 继续阅读

- [从第一次调用到生产环境的多模型 API](https://keeprouter.com/zh/features.md)
- [比较 AI 网关的运行模式，而不是口号](https://keeprouter.com/zh/compare.md)
- [AI Gateway 指南：它控制什么、何时需要，以及如何落地](https://keeprouter.com/zh/blog/ai-gateway-guide.md)
- [OpenAI 兼容 API 迁移清单](https://keeprouter.com/zh/blog/openai-compatible-api-migration-checklist.md)
- [KeepRouter 上的 Kimi K3：使用 1M token 上下文窗口](https://keeprouter.com/zh/blog/kimi-k3-1m-context.md)

[全部文章](https://keeprouter.com/zh/blog.md) · [模型与价格](https://keeprouter.com/models.md)