Experiential Labs 最近把 Experiential 开源，仓库说明是“an open source gateway and router for agent workflows”。它提供 OpenAI 兼容 API，可以把 hosted、BYOK、本地和自定义模型放在一个控制面里，还能控制用户和 agent 可以用哪些模型、用于哪些场景、花多少钱。更有意思的是，README 把生产流量转化成 custom router 或 model optimization 作为核心能力之一。参考来源：Experiential GitHub、AI Engineer speaker page、YC LinkedIn 介绍。
模型网关这个赛道并不新。LiteLLM、OpenRouter、Helicone、Portkey、LangSmith、OpenTelemetry collector、各家云 API gateway 都能覆盖一部分需求。Experiential 值得单独看，是因为它把 agent workflow 的真实 trace 放到了更中心的位置。对 agent 团队来说，模型调用不只是成本中心，也是一种持续积累的任务分布数据。
它解决哪一层问题
一个模型网关通常有四层价值。
第一层是统一 API。你希望用同一个 OpenAI 兼容接口调用 OpenAI、Anthropic、Gemini、本地 vLLM 或 OpenRouter。第二层是治理。不同用户、不同 agent、不同任务应该有不同预算、模型白名单和 fallback 策略。第三层是可观测性。每次调用的延迟、成本、错误、输入输出摘要和 trace id 要能追踪。第四层是优化。系统应该根据历史流量学会哪些请求不用打到最贵模型。
Experiential 的 README 把这四层串起来：先启动本地 gateway，选择 public alias，拿 key 调 /v1/chat/completions；再收集 OpenTelemetry traces；随后用 exp build 从 agent traces 构建 simulation；最后可以优化 router 或微调自有开源模型。
快速体验路径
它的本地入口很轻：
pip install experiential
exp向导会让你配置 provider、model、reasoning effort、public alias、identity 和预算。之后就可以用 OpenAI 兼容 API 调用。
export EXP_GATEWAY_KEY="xpl_your_local_key"
curl http://127.0.0.1:8000/v1/chat/completions \
-H "Authorization: Bearer $EXP_GATEWAY_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "opus-5",
"messages": [{"role": "user", "content": "Summarize this incident."}]
}'生产迁移时，应用侧改动通常只有两处：base URL 指向 gateway，API key 换成 gateway key。真正复杂的是策略设计。
from openai import OpenAI
client = OpenAI(
base_url="http://127.0.0.1:8000/v1",
api_key="xpl_your_local_key",
)
response = client.chat.completions.create(
model="support-agent-router",
messages=[{"role": "user", "content": "用户要求退款，应该走什么流程？"}],
)
print(response.choices[0].message.content)与 LiteLLM、OpenRouter 的区别
如果你只需要“一个 endpoint 调很多模型”，LiteLLM 和 OpenRouter 已经很成熟。LiteLLM 在自托管、预算、fallback 和 provider 兼容上生态更大；OpenRouter 在公共模型市场、快速试模型和统一结算上更方便。
Experiential 的差异点在于后半段：它希望你把 production traffic 变成 simulation，再基于 simulation 优化 router 或模型。这个思路更贴近 agent 团队的长期问题。随着 agent 流量增长，最贵的不是某一次 API 调用，而是你每个月都把同类简单请求交给 frontier model，却没有把历史流量变成自己的资产。
可以把三者粗略分工为：
| 工具 | 更适合 | 主要价值 |
|---|---|---|
| LiteLLM | 企业多供应商代理 | 兼容、成本控制、fallback、proxy |
| OpenRouter | 快速试模型和公共路由 | 模型市场、统一入口、开发便利 |
| Experiential | agent workflow 优化 | trace、simulation、custom router、自有模型优化 |
这不是互斥关系。一个团队完全可能用 Experiential 接自己的 BYOK provider，其中某个 provider 又是 OpenRouter；或者保留 LiteLLM 作为成熟代理层，只把特定 agent 的 trace 导入 Experiential 做优化实验。
选型关键指标
评估模型网关不要只看 README 漂亮不漂亮。至少测六项。
第一，兼容性。你的 SDK、streaming、tool calling、structured output、JSON mode、Anthropic Messages API 是否都能正常转发。第二，延迟开销。网关本身增加的 p50 和 p95 延迟是多少。第三，失败行为。provider 超时、限流、schema 错误、stream 中断时是否能稳定 fallback。第四，成本归因。能否按 user、agent、task、repo、customer 分摊成本。第五，数据边界。prompt、completion、tool result、trace 是否可脱敏、可采样、可关闭。第六，策略表达力。能否表达“低风险分类任务用本地模型，高风险法律草稿走强模型，超过预算进入人工队列”。
Experiential 的优势会在第六项和后续优化上体现。如果你还没有稳定 trace，也没有多个 agent，它的高级能力暂时用不上。
风险
模型网关是高敏感组件。所有 prompt、工具结果、客户上下文和模型 key 都可能经过这里。上线前要看三件事。
第一，遥测默认值。Experiential README 提到匿名聚合 PostHog telemetry 默认开启，并说明不包含 prompt、trace、action、observation、path、model name、credential 或 raw customer content。即便如此，企业环境仍应在试点时显式检查 exp config telemetry status，必要时关闭。
第二，trace 采样。生产 trace 很容易包含 PII、密钥、内部路径和客户数据。导入 simulation 前必须脱敏，不要为了优化路由把合规边界打穿。
第三，策略回滚。router 优化后不应一次性接管全部流量。先按任务类型和用户分桶灰度，保留强模型 fallback，并对质量指标设置回退阈值。
结论
Experiential 的价值在于把模型网关从“统一调用面”推进到“agent 资产入口”。短期它可以帮你统一 OpenAI 兼容 API、预算和 provider；中期它可以把真实 trace 变成 simulation；长期它试图让团队训练自己的 router 或模型，把简单、重复、低风险的请求从昂贵模型上迁走。
我的判断是：已经有 agent 流量和成本压力的团队值得试点；还在原型期的团队先把 eval、trace id、成本归因做好。没有这些基础，任何智能路由都会变成更复杂的黑盒。