Cloudflare发布Flagship，专为AI驱动的特性管理设计
Cloudflare AI··作者 Abhishek Kankani
关键信息
Flagship针对Cloudflare Workers进行了优化，在边缘网络内实现本地评估，避免了外部HTTP调用带来的延迟；它支持Node.js、Bun、Deno和浏览器等多种运行时，并通过OpenFeature标准化API集成。
资讯摘要
AI生成的代码正以前所未有的速度被部署，像OpenCode和Claude Code这样的工具可以在几分钟内交付整个功能。下一步是自主性：AI代理将无需人工介入即可编写、审查、合并并部署代码。为了确保安全性，Cloudflare推出了Flagship——一个特性开关系统，可将部署与发布解耦，并实现安全的自动化发布。
与其硬编码标志或进行缓慢的远程调用，Flagship会在Cloudflare边缘网络中本地评估标志，确保低延迟决策并集中控制。这使得AI代理能够在小规模用户群体上测试新功能，监控指标，并根据结果扩大或禁用该功能——全部无需人工监督。Flagship目前已进入封闭测试阶段，并基于CNCF批准的OpenFeature标准构建。
资讯正文
人工智能正在编写比以往更多的代码。AI辅助的代码贡献如今占据了平台上新代码的快速增长比例。像OpenCode和Claude Code这样的智能编程工具，可以在几分钟内完成整个功能的开发。
进入生产环境的AI生成代码只会加速。但更大的转变不仅仅是速度——而是自主性。
今天，AI代理编写代码，人类负责审查、合并并部署它。明天，这个代理将自行完成所有这些步骤。问题随之而来：你如何让一个代理在不移除所有安全措施的情况下发布到生产环境？
特性标志（Feature Flags）就是答案。代理在标志后编写新的代码路径并部署它——此时标志是关闭的，用户不会察觉任何变化。接着，代理为自己或一小部分测试用户开启标志，在生产环境中使用该功能并观察结果。如果指标表现良好，就逐步扩大发布范围；如果出现问题，就关闭标志。人类不需要参与每一步——他们设定边界，而标志控制影响范围。
这就是特性标志始终致力于实现的工作程：不仅解耦部署与发布，还解耦人类注意力与每个发布阶段。正是标志让代理能够快速行动，同时保持安全。
今天，我们宣布推出Flagship——Cloudflare原生的特性标志服务，基于CNCF开放标准OpenFeature构建，用于特性标志评估。它可在任何地方运行——Workers、Node.js、Bun、Deno和浏览器中——但在Workers上最快，因为标志在Cloudflare网络内部进行评估。结合Flagship绑定和OpenFeature，集成看起来像这样：
await OpenFeature.setProviderAndWait(
new FlagshipServerProvider({ binding: env.FLAGS })
);
Flagship目前已进入封闭测试阶段。
Workers上的特性标志问题
许多Cloudflare开发者已经采用了一种务实的权宜之计：直接在Workers中硬编码标志逻辑。老实说，一开始这方法效果不错。Workers部署只需几秒钟，所以修改代码中的布尔值并推送到生产环境的速度对大多数情况来说已经足够快。
但它不会一直简单。一个硬编码的标志很快变成十个，十个变成五十个，由不同团队维护，且没有统一视图来查看哪些功能处于开启或关闭状态。也没有审计日志——当出问题时，你只能通过git blame查找是谁切换了什么。
调用外部服务的网络请求
另一种常见的Workers模式是向外部服务发起HTTP请求，如下所示：
const response = await fetch("https://flags.example-service.com/v1/evaluate", {
body: JSON.stringify({
flagKey: "new-checkout-flow",
context: {},
}),
});
const { value } = await response.json();
if (value === true) {
return handleNewCheckout(request);
}
return handleLegacyCheckout(request);
这种出站请求位于每个用户请求的关键路径上。根据用户距离标志服务所在区域的距离，可能会带来显著延迟。
这是一个奇怪的情况。你的应用程序在边缘运行，距离用户仅毫秒之隔。但特征标志检查却迫使它必须跨互联网回传到另一个API，才能决定渲染什么内容。
为什么本地评估无法解决问题
一些特征标志服务提供“本地评估”SDK。与每次请求都调用远程API不同，该SDK会将完整的标志规则集下载到内存中并进行本地评估。这样就不需要每次评估都发出外部请求，标志决策也能在进程中完成。
但在Workers平台上，这些假设都不成立。没有长期运行的进程：一个Worker隔离环境可能在一次请求之间被创建、处理请求后又被清除。新的调用意味着必须从头重新初始化SDK。
在无服务器平台上，你需要一种已经部署在边缘的分发原语——这种原语自带缓存管理机制，读取操作是本地的，并且无需保持持久连接来维持更新。
Cloudflare KV正是为此设计的理想原语！
Flagship如何工作
Flagship完全基于Cloudflare基础设施构建——包括Workers、Durable Objects和KV。评估路径中没有任何外部数据库、第三方服务或集中式源服务器。
当你创建或更新一个标志时，控制平面会原子性地将变更写入一个Durable Object——这是一种基于SQLite的全局唯一实例，作为该应用标志配置和变更日志的权威来源。几秒钟内，更新后的标志配置就会同步到Workers KV，即Cloudflare的全球分布式键值存储系统，在Cloudflare网络中进行复制。
当请求评估一个标志时，Flagship直接从边缘的KV读取标志配置——也就是正在处理请求的同一Cloudflare位置。评估引擎随后就在这个隔离环境中运行：它将请求上下文与标志的目标规则匹配，计算发布百分比，并返回一个变体。数据和逻辑都位于边缘——无需发送到其他地方进行评估。
使用Flagship：Worker绑定
对于运行Cloudflare Workers的团队，Flagship提供了直接绑定，可在Workers运行时内部评估标志——无需HTTP往返，也无需额外的SDK开销。只需将绑定添加到你的wrangler.jsonc文件中，你的Worker即可连接：
{
"flagship": [
{
"binding": "FLAGS",
"app_id": "<APP_ID>"
}
}
就是这样。账户ID会自动从你的Cloudflare账户推断得出，而app_id则将绑定关联到特定的Flagship应用。在你的Worker中，你只需请求一个标志值：
export default {
async fetch(request: Request, env: Env) {
// 简单布尔检查
const showNewUI = await env.FLAGS.getBooleanValue('new-ui', false, {
userId: 'user-42',
plan: 'enterprise',
});
// 需要详细信息时获取完整评估结果
const details = await env.FLAGS.getStringDetails('checkout-flow', 'v1', {
userId: 'user-42',
});
// details.value = "v2", details.variant = "new", details.reason = "TARGETING_MATCH"
},
};
该绑定支持每种变体类型的类型化访问器：getBooleanValue()、getStringValue()、getNumberValue()
getObjectValue()
- plus
*Details()
返回解析后的值，同时附带匹配的变体和选择该变体的原因。如果评估过程中发生错误，将优雅地返回默认值；如果类型不匹配，则绑定会抛出异常——这属于代码中的错误，而非临时性故障。
SDK：OpenFeature 原生
大多数特性标志 SDK 都自带自己的接口和评估模式。随着时间推移，这些接口会深深嵌入你的代码库中，而更换供应商则意味着要重写每一个调用点。
我们不想再打造另一个这样的 SDK。Flagship 基于 OpenFeature 构建，这是 CNCF 的特性标志评估开放标准。OpenFeature 定义了跨语言和供应商的统一标志评估接口——它与 OpenTelemetry 在可观测性领域的角色类似。你只需针对标准编写一次评估代码，通过修改一行配置即可切换供应商。
import { OpenFeature } from '@openfeature/server-sdk';
import { FlagshipServerProvider } from '@cloudflare/flagship/server';
await OpenFeature.setProviderAndWait(
new FlagshipServerProvider({
appId: 'your-app-id',
accountId: 'your-account-id',
authToken: 'your-cloudflare-api-token',
})
);
const client = OpenFeature.getClient();
const showNewCheckout = await client.getBooleanValue(
'new-checkout-flow',
false,
{
targetingKey: 'user-42',
plan: 'enterprise',
country: 'US',
}
);
如果你在 Workers 上运行并使用 Flagship 绑定，可以直接将其传递给 OpenFeature 提供商。该绑定已包含你的账户上下文，无需额外配置——认证是隐式的。
import { OpenFeature } from '@openfeature/server-sdk';
import { FlagshipProvider } from '@cloudflare/flagship/server';
let initialized = false;
export default {
async fetch(request: Request, env: Env) {
if (!initialized) {
await OpenFeature.setProviderAndWait(
new FlagshipServerProvider({ binding: env.FLAGS })
);
initialized = true;
}
const client = OpenFeature.getClient();
const showNewCheckout = await client.getBooleanValue('new-checkout-flow', false, {
targetingKey: 'user-42',
plan: 'enterprise',
});
},
};
你的评估代码不会改变——OpenFeature 接口完全一致。但底层上，Flagship 通过绑定来评估标志，而不是通过 HTTP 请求。你既获得了标准的可移植性，又享受到了绑定的高性能。
浏览器端也提供了一个客户端提供商。它会预先获取你指定的标志，以可配置的 TTL 缓存它们，并从缓存中同步提供评估结果。
你可以用 Flagship 实现什么功能
Flagship 支持你期望从一个特性标志服务中获得的所有模式，同时也支持 AI 自动生成的代码每天上线时变得至关重要的那些场景。
标志值可以是布尔值、字符串、数字或完整的 JSON 对象——这对配置块、UI 主题定义，或者在不维护多个代码路径的情况下引导用户到不同 API 版本非常有用。
目标规则
每个标志可以有多个规则，按优先级顺序逐一评估。第一个匹配的规则胜出。
一条规则由以下组成：
决定规则适用于特定上下文的条件
当规则匹配时要提供的标志变体
可选的百分比发布方案
确定多个规则存在时的评估顺序的优先级（数字越小优先级越高）
嵌套逻辑条件
条件可以通过 AND/OR 逻辑组合，最多嵌套五层。单个规则可以表达类似以下内容：
(plan == “enterprise” AND region == “us” ) OR (user.email.endsWith(“@cloudflare.com”))
= 提供 (“premium”)
在规则顶层，多个条件通过隐式 AND 连接，所有条件都必须满足规则才能匹配。在每个条件内部，你可以嵌套 AND/OR 分组以实现更复杂的逻辑。
按百分比的标志发布
与渐进式部署不同——后者将流量拆分到上传的不同版本 Worker 中，标志允许你在单一版本中按百分比逐步推出功能，而该版本仍服务全部流量。
任何规则都可以包含百分比发布。不是向所有符合条件的用户推送变体，而是仅向其中的一部分用户推送。
发布使用指定上下文属性的一致哈希算法。相同的属性值（例如 userId）始终哈希到同一个桶中，因此请求之间不会在不同变体间切换。你可以从 5%、10%、50% 逐步提升到 100% 的用户，已处于发布范围内的用户会保持不变。
为未来而生
AI 生成代码进入生产环境的速度只会加快。代理工作流将进一步推动这一趋势——即自主部署、测试并迭代生产环境中代码的代理。在这个世界中取得成功的企业，不会是那些发布速度最快的团队，而是那些既能快速发布，又能掌控用户所见内容、在出现问题时几秒内回滚、并自信地逐步暴露新代码路径的团队。
这正是 Flagship 所致力于的目标：
跨地球区域的评估，
使用 K/V 全球缓存。
完整的审计日志。
每次标志变更都会记录字段级别的差异，这样你就能清楚知道是谁在何时更改了什么。
仪表板集成。
团队中的任何人都可以在不修改代码的情况下切换标志或调整发布比例。
兼容 OpenFeature。
采用 Flagship 无需重写你的评估代码，迁移离开时也无需重写。
开始使用 Flagship
从今天起，Flagship 处于私有测试阶段。你可以在此处申请访问权限。
随着正式可用性的临近，我们将公布更多定价细节。
访问 Cloudflare 仪表板创建你的第一个 Flagship 应用
安装 SDK：
npm i @cloudflare/flagship
或者直接在你的 Worker 中使用 Worker 绑定
阅读文档获取集成指南和 API 参考
查看源代码获取示例并参与贡献
如果你目前在 Workers 中硬编码标志，或通过外部服务评估标志导致每次请求延迟增加，请尝试 Flagship。我们非常期待了解你构建的内容。
来源与参考
收录于 2026-04-18