现在很多公司都喜欢把自己往 AI infra 这个词上靠。这个词有一种天然的高级感。听起来像在做底座，像在掌握核心能力，像站在更靠近模型和算力的一层。
LaunchDarkly 也很容易被放进这个篮子里。它有 AI Configs，能管 prompt、model、tool、experiment、guarded rollout、observability，甚至开始讲 agent。乍一看，确实很像在做 AI 的基础设施。
但我把它的官方文档、SDK 边界和竞品都过了一遍以后，判断反而更清楚了：LaunchDarkly 真正在卖的，不是 AI infra，而是 AI control plane。
这个区别不是抠字眼。因为一旦分类错了，你对产品的期待就会彻底跑偏。你如果把它当成 model serving、AI gateway、agent runtime 去看，一定会觉得它“不够全”。但如果你把它当成一层专门管线上 AI 行为变更、分流、回滚、实验和治理的控制平面，它反而是很完整的一条产品线。
它不跑模型，这件事决定了它不属于底层 infra
判断一个产品是不是“真 AI infra”，最简单的方法不是看 marketing page，而是看它到底接不接 provider、代不代发请求、托不托管执行。
LaunchDarkly 在这件事上说得异常清楚。在官方文档 AI Configs quickstart 里，它直接写：
“In the AI Configs product, LaunchDarkly does not handle the integration to the AI provider.”
“However, it is still your application’s responsibility to call the AI provider.”
在总览页 AI Configs 里又补了一句更狠的：
“LaunchDarkly does not proxy or independently invoke model providers.”
只要一个产品明确说自己不负责 provider invocation，不 proxy model provider，你就很难再把它主标成模型基础设施。它不在跑车，它在管车道。
那它到底在卖什么
如果把 LaunchDarkly 的 AI 能力拆开看，它其实非常像把 feature flagging 时代最成熟的那套方法论，整体平移到了 AI 系统里。
它卖的是四件事。
第一，运行时配置。 你的 prompt、instructions、model config、tool schema 不再写死在代码里，而是变成一个可以按用户、按环境、按规则实时求值的对象。官方文档的说法是：“control how your application uses large language models”。
第二，发布控制。 新 prompt 能不能灰度。新 model 能不能先放 5% 用户。效果差了能不能秒回滚。有没有审批链和审计线索。这个思路本质上就是 feature rollout 的 AI 版本。
第三，实验与比较。 它不是只让你“改”，还让你“比”。不同 variation 的 token、时延、效果、judge 分数能不能一起看，这决定了你是在拍脑袋调 prompt，还是在做真正的生产实验。
第四，观测与治理。 AI 系统最怕的不是第一次跑不起来，而是上线以后慢慢漂。LaunchDarkly 的价值恰恰在这里。它想把 model behavior 放进一个可观测、可干预、可回退的闭环里。
所以我会把它翻译成一句更接地气的话：LaunchDarkly 不在造 AI 的发动机，它在造 AI 上路之后的方向盘、刹车、仪表盘和变道系统。
为什么这个位置反而可能很值钱
很多 AI 团队早期最关注的，都是“怎么把能力做出来”。接哪个模型，怎么调 prompt，怎么接工具，怎么把 demo 跑通。这当然重要，但一旦系统进入线上，真正麻烦的问题马上会变成另一组：
- 新 prompt 上线后效果变差了，怎么快速止损。
- 换模型后成本降了，但满意度掉了，怎么做分流比较。
- 某类用户应该走哪个 variation，谁来决定，怎么审计。
- judge、metric、rollout、approval 怎么绑成一个闭环。
这时候你会发现，AI 系统里最贵的部分，不一定是模型本身，而是变更管理。模型调用只是入口，真正容易出事故的是变更失控。
从这个角度看，LaunchDarkly 占的位置其实很聪明。它不是去和 OpenAI、Anthropic、Portkey、LangSmith 在同一个层面正面硬碰，而是抓住了一个很多团队都迟早会遇到的问题：AI 已经上线之后，谁来管它。
它也不是万能解
把 LaunchDarkly 看清楚以后，它的不足也就跟着清楚了。
如果你现在还处在“连 provider routing、prompt registry、trace、eval 都没搭起来”的阶段，那它不是你的第一优先级。因为它解决的不是“从零到一”，而是“从一到稳”。
如果你要的是完整 agent runtime，它也给不了。LaunchDarkly 在自己的 guide 里明确写过：配置它来管，orchestration 还是你的代码或 LangGraph 之类框架来管。这说明它想占的是 control plane，不是 runtime plane。
而且它还会带来另一个现实问题：你愿不愿意为这层控制面付费。对很多公司来说，这类平台最难证明价值的地方在于，它不直接“生成结果”，而是在防事故、防漂移、防变更失控。短期 ROI 不一定显眼，长期却可能越来越贵。
这也是为什么 LaunchDarkly 很容易在组织里碰到一种典型争论：业务会觉得“这不就是配置管理吗”，工程会觉得“这不就是 feature flag 延伸吗”，但真正把 AI 功能往线上推过几轮的人，往往会更容易理解它在卖什么。因为他们已经被 prompt 回滚、模型切换、线上漂移和实验不可追责这些问题打过脸了。
对企业团队来说，真正该问的问题
所以看 LaunchDarkly，不该先问“它算不算 AI infra”，而该先问三个更实际的问题。
第一，我们现在缺的是能力层，还是控制层。 如果能力层还没搭好，先别急着上控制平面。反过来，如果能力层已经差不多了，控制层迟早会变成瓶颈。
第二，我们的 AI 系统有没有进入需要治理的阶段。 只有当 variation、环境、审批、实验、回滚、观测这些问题同时出现时，LaunchDarkly 的价值才会真正显形。
第三，我们是否接受“AI 生产系统里，控制权本身就是产品”。 很多团队直到今天还会下意识觉得，真正值钱的是模型，控制只是配套。但我越来越觉得，AI 时代真正容易被低估的，恰恰就是控制面。
因为模型能力会越来越商品化，接口也会越来越标准化。真正长期稀缺的，不一定是“谁能调到最强模型”，而是“谁能让模型在真实业务里稳定、可控、可回退地运转”。
最后的判断
如果只让我给 LaunchDarkly 的 AI offering 贴一个标签，我不会选 AI infrastructure，也不会选 AI observability 或 AI experimentation。这些都太窄，或者太大。
我会选：AI control plane。
更完整一点，是：runtime AI control plane for production AI behavior。
它真正厉害的地方，不是替你把 AI 做出来，而是替你把 AI 上线后的失控风险，收回到一个可管理的系统里。
所以，LaunchDarkly 真正在卖的，不是 AI infra。它卖的是另一种在 AI 时代会越来越贵的东西：对生产行为的控制权。