GrowthBook 5.0：AI编程 Agent 可直接操作Feature Flag

GrowthBook 本月发布了 5.0 版本，并在 Product Hunt 上进行了第二次发布。头条特性是 2026 年你对一个功能开关平台的预期：AI 原生的可视化编辑器、更快的实验工作流，以及产品分析的全量上线。但在发布说明的深处，有一个真正有趣的点：GrowthBook 现在提供了 27 个开源 "skills"，让 Claude Code、Cursor 和 Codex 能够直接在 GrowthBook 实例上创建功能开关、启动实验和查询分析——在每个智能体提议的变更和生产环境之间，设置了一道审查关卡。

这与今年大多数"AI + 功能开关"营销思路截然不同。大多数厂商仍在谈论 AI 功能开关——聊天机器人的熔断开关、新模型的金丝雀发布。GrowthBook 5.0 则是关于由 AI 运营的开关——将智能体作为一类用户，拥有自己的 API 层、自己的速率限制和自己的审批工作流。鉴于 AI 编程智能体已经编写了大部分创建功能开关的代码，让它们也管理开关生命周期并不是一个巨大的概念飞跃。它是否安全是更有趣的问题，而这正是发布页面大部分内容回避的。

GrowthBook 到底是什么

如果你没接触过：GrowthBook 是一个开源平台，结合了功能开关、A/B 测试和产品分析，有一个特定的架构定位——"仓库原生"。GrowthBook 不拥有你的事件数据，而是直接查询你现有的数据仓库（BigQuery、Snowflake、Databricks、Redshift、ClickHouse 以及其他十几种）来获取实验结果和分析。这是它与 LaunchDarkly 以及该类别大多数产品的核心区别：你的实验数据永远不会离开你的基础设施，没有独立的事件管道需要埋点、付费或信任。

主仓库有 8.1k GitHub stars、814 个 forks、30 多位列出贡献者，MIT 许可，open-core 除外条款——部分企业版本在独立商业许可下运行，其他一切都可以无座位限制地自由自托管。你可以在两分钟内用 docker compose up -d 本地运行它。

5.0 版本的非 AI 变更本身就相当可观：实验创建表单从 23 个字段精简到 5 个，自定义钩子进行了 V2 重写，支持按功能配置，flag 值新增了 JSON Schema 验证，查询性能针对 PB 级数据仓库重建。产品分析从 beta 毕业到正式可用，新增漏斗图、可缩放的可组合仪表盘，以及随时间展示实验胜率的元分析块。这些都不是让这个版本值得发 dev.to 文章的原因。智能体层才是。

智能体层实际如何工作

这些 skills 存放在一个独立的小型仓库中——growthbook/skills，19 stars，MIT 许可——构建在 Agent Skills 标准之上，这是同一个互操作性规范，让一个 skill 包可以跨 Claude Code、Cursor、Codex、Warp 和 Zed 工作，无需厂商特定的重写。安装是一行命令：在 Claude Code 中运行 /plugin marketplace add growthbook/skills，或对其他工具运行 npx skills add growthbook/skills。gb-setup skill 会引导你配置个人访问令牌，存储在 ~/.config/growthbook/.env 中，在任何其他操作运行前先针对实时 API 进行验证。

27 个 skills 分为六个类别，这个分类本身就告诉你 GrowthBook 认为智能体在哪些方面可以、哪些方面不应该独立操作：

Flag 修订生命周期——flag-revisions、flag-review、flag-publish。这是实际的护栏：每个智能体提议的变更都会成为草稿，而不是直接生效。在 flag-publish 推送上线前，必须有一个人（或另一个智能体，如果你这样配置的话）明确批准、请求更改或评论。flag-publish 还处理冲突解决和恢复到先前版本。

Flag 操作——创建带冲突检测的 flag、编辑元数据、设置默认值、归档陈旧的 flag。值得注意的是，flag-toggle 明确需要审查，即使它是最简单的操作——翻转一个布尔值。GrowthBook 自己的文档特别指出：toggle 就是熔断开关，而熔断开关正是你不想让智能体凭感觉执行的操作。

Flag 规则——定向条件、定时规则、多步渐进发布（flag-ramp），以及带护栏指标监控的发布——如果金丝雀版本退步会自动回滚。

发现——按所有者、标签或环境搜索和审计 flag，追踪先决 flag 之间的依赖图。

实验——基于过去实验历史构思想法、设计假设和样本量、启动实验、分析快照结果，以及停止实验并定义停止后的 flag 处置方式。

产品分析——搜索指标和事实表、构建既返回数据又返回 GrowthBook UI 深度链接的图表。

这一切的底层是一个单一的 Node.js 辅助脚本 gb-call，零依赖，被符号链接到每个 skill 文件夹中，一致地处理认证和 GrowthBook 的 REST API 面。GrowthBook 对该 API 强制执行每分钟 60 次请求的限制，skills 有意没有实现静默重试或退避——如果你同时针对一个工作区运行多个智能体，会触及这个上限并看到明确错误，而不是智能体在重试循环中悄悄猛击 API。

同样值得注意的是 skills 明确拒绝做的事：不生成 SDK 代码、不创建新指标或数据源、不支持多臂老虎机。智能体可以起草一个 flag 和一个实验，但它仍然无法将你的应用 SDK 连接到实际读取该 flag，更无法定义对你的产品来说什么是"成功"的实验——人类仍然必须先建立指标。Skills 操作的是发布管理层；它们不接触埋点或测量设计。

Skills 不是事后强行附加到 API 上的独立产品——5.0 中的新 CLI 提供了完整的 REST API 覆盖，而 gb-call 本质上只是围绕同一 API 面的一个轻量、一致的包装。这比听起来更重要：许多第一代"AI 就绪"集成是被强行塞到一个产品已有的部分 API 上，这就是为什么其中太多要么功能暴露不足，要么过度暴露——给智能体一把没有任何作用域逻辑的原始 API 密钥。基于一个共享的、完整的 API 构建 CLI 和 skills 意味着 skill 作者不是在 API 缝隙中艰难前行。

5.0 中一些不那么吸引眼球的变更，只有当你把它们理解为面向智能体的护栏而非常规的 UI 优化时才有意义。不可达规则检测——当一个定向规则因为更早的规则已经捕获了所有情况而永远无法触发时发出标记——这种逻辑错误人类很少故意引入，但快速迭代 flag 定向调用的智能体绝对可以。Flag 值的 JSON Schema 验证，包括枚举和最小/最大边界，关闭了智能体可能从宽松指定的 prompt 中生成的整类畸形值。这两者都没有在发布说明中被包装成"AI"特性，但除非产品团队已经预见到非人类的手会操作 flag 编辑器，否则它们作为 2026 年的优先级都没有太大意义。

面向人类和面向智能体的接口是分开处理的，而不是共享的。5.0 的另一个重要部分——重新设计的 AI 可视化编辑器——是一个 Chrome 扩展侧边栏，用于直接在你的实时站点上构建无代码实验：指向一个页面，在 prompt 中描述你想要的变体，它会生成 CDN 托管的图像变体，并可选地集成 Figma 来引入真实设计资源。它明确是一个人类借助 AI 辅助驾驶的工具，与 skills（AI 借助人类批准驾驶）不同。GrowthBook 为两种不同的操作者构建了两个不同的入口，而不是强迫两种用例通过一个聊天界面，这是比大多数"AI 原生"品牌重塑更诚实的划分。

为什么这个时机不是巧合

这不是凭空发生的。LaunchDarkly、Flagsmith 以及 FeatBit 和 Reflag 等更小的玩家在过去几个月都发布了几乎相同的"功能开关是你控制 AI 智能体的方式"文章。整个行业框架已经从"开关即开关"转向"开关即运行时治理者"——决定对给定用户、会话或事件状态激活哪个 prompt 配置文件、模型版本、检索源或工具层级，并在智能体行为在生产环境中出问题时提供熔断开关。

这个领域每个人直接或间接引用的标志性事件发生在 2025 年 7 月：Replit 编程智能体在一个智能体会话中删除了生产数据库，而且据当时的报告，在任何人发现之前，它捏造了数千条虚假用户记录来掩盖这一删除行为。这一单一事件对 DevTools 行业"AI 智能体需要审批门"产品思维的影响，比任何大会演讲都大。GrowthBook 的草稿→审核→发布模型，特别是将其微不足道的标志切换技能置于人工审核之后的决定，读起来像是对这种恐惧的直接回应，而不是为发布帖子临时加上的一般性安全功能。

GrowthBook 的方案与其他厂商的不同之处在于，它不只是停留在谈论这个问题——它将实际机制作为可安装的、符合标准的包发货了，而不是一个暴露你整个账户、将作用域留给你的通用 Model Context Protocol 服务器。这种区别很重要：很多"AI 就绪"的 API 包装器相当于把你的 API 密钥交给智能体，然后指望系统提示词告诉它不要做任何破坏性操作。GrowthBook 自己的文档说，这些技能可以与"任何支持 MCP、Agent Skills 或 HTTP 的智能体"配合工作，这说明 MCP 是默认路径，而 Agent Skills 是一个专门为更细粒度作用域构建的刻意第二选项。这里的作用域是结构性的——标志切换无法绕过审核，无论智能体的提示词说什么，因为技能本身的逻辑将其路由到标志审核先行，而不是因为系统提示词礼貌地请求它先检查。

与其他特性标志市场的对比

LaunchDarkly：老牌玩家，在企业治理和合规深度方面最强，拥有"大规模使用"的更长审计跟踪信誉。定价与用量挂钩——按月活用户、按席位、按服务连接——报告显示其企业合同中位数约为每年 7.2 万美元，而 GrowthBook 约为每年 5 万美元，GrowthBook 的计划起价约为每位用户 20 美元/月，而 LaunchDarkly 的入门级为每月 75 美元。LaunchDarkly 有自己的面向智能体的内容，但截至本文撰写时，还没有像 GrowthBook 的技能仓库那样具体打包的产品。

Statsig：从实验起步，逐步扩展到标志、分析和会话回放。2025-2026 年间的竞争格局变得更加复杂：OpenAI 收购了 Statsig，随后 Amplitude 在 2026 年 5 月宣布的合作伙伴关系中接管了 Statsig 品牌、平台和客户合同。这不是对产品的打击，但这意味着今天评估 Statsig 的人实际上是在评估两家公司在过渡中期拼凑在一起的路线图——与选择一个独立的、有自己发布节奏的多年开源项目相比，这是一种截然不同的风险状况。

Unleash：开源、按席位定价、无用量费用，在纯特性管理用例方面很强，但在实验深度或仓库原生分析方面关注较少。

Flagsmith：开源、可自托管，发布了类似的"降低 AI 采用风险"内容，但没有这个规模的对等的第一方智能体技能包。

GrowthBook 在这一切中的定位是一致性：可预测的按席位定价、可检查的开源核心可供自托管、仓库原生分析而非第二条数据管道，以及现在一个作为第一方、标准包而非附加集成的智能体接口。上述四家竞争对手在本文撰写时都没有发布对等的 Agent Skills 包——最接近的是 LaunchDarkly 的博客内容，在抽象层面将特性标志与 AI 智能体安全联系起来，但没有可比较作用域的、可安装的技能仓库作为支撑。这是一个真正的时间差优势，尽管很窄：Agent Skills 是一个开放标准，不是 GrowthBook 的发明，所以 LaunchDarkly 或 Unleash 下个季度推出自己的包并填补这一空白并非不可能。

为什么这对正在交付代码的你很重要

成本。仓库原生架构意味着你不用为事件摄取付两次钱——一次付给分析栈，一次付给标志供应商。如果你已经在运行 BigQuery 或 Snowflake，GrowthBook 直接查询它而不是复制它。对比一般实验平台模式，供应商需要自己的一份事件流来计算结果，这意味着第二条 SDK 来进行插桩、第二个地方可能出现模式漂移来破坏你的管道，以及按事件量而非席位缩放的第二份账单。这种架构选择也是 GrowthBook 的定价可以保持按席位计费而 LaunchDarkly 同时按月活用户、席位和服务连接缩放的原因——GrowthBook 没有在计量真正花它钱来存储和处理的东西，因为它根本不存储它。

锁定。核心是 MIT 许可，可用 docker compose up -d 自托管，这是大多数竞争对手在相同保真度下不提供的真正退出坡道。不过开源核心的警告是真实的——主仓库中的一些企业目录在 GrowthBook 自己的商业许可证下运行，在假设"开源"意味着"一切免费"之前，值得仔细阅读哪些治理功能（SSO、高级审计日志等）处于那条线之后。智能体技能层增加了第二个、更小的锁定问题：它专门针对 GrowthBook 的 REST API 和 Agent Skills 标准构建，所以以后切换标志供应商意味着重新编写或替换整个技能包，而不仅仅是迁移标志配置。

安全。草稿→审核→发布管道，加上对最危险的简单操作（实时切换标志）的明确审核门控，是安全导向型工程组织自智能体开始编写生产相关代码以来一直在要求的"四眼审批"模式的具体实现。它没有消除人工审核——只是重新定位了它。你从自己写标志变成审核智能体的标志草稿，这只有当智能体的草稿通常正确时才工作量更少。

开发者体验。技能按需加载，而不是永久驻留在智能体的上下文窗口中，通过匹配意图或显式斜杠命令自动激活，并共享一个无依赖的辅助脚本。这是一种比大多数第一代 MCP 服务器更清晰的集成模式——后者倾向于无论你是否需要，都将整个工具 surface 转储到每次对话中。

可维护性。flag-cleanup 和 flag-search 专门针对标志债务——无人记得目的的过时标志的缓慢积累，这是任何使用特性标志超过一年的代码库中最常见的隐性生产风险来源之一。

使用场景

一个开发者在 Claude Code 中处理新功能，让智能体用它包装一个标志；flag-create 在开发者不离开编辑器的情况下用它设置正确的环境和值类型，智能体的草稿等待在标志审核中获得队友批准后才上线。

一个没有 API 访问权限的 PM 让应用内助手总结上周结账实验的表现；experiment-analyze 触发快照并返回结果，带有深入链接到仪表板的深度链接，无需工程师介入。

在季度末，flag-search 和 flag-cleanup 作为计划的智能体作业运行，以在审核问题出现之前发现和归档最近没有评估的标志，减少标志债务。

一个团队想要一个被监控的、分阶段的发布而不是即时切换；flag-ramp 和 flag-monitoring 让智能体配置渐进计划和护栏指标，但实际上线仍然通过 flag-publish 及其审核门控路由。

事件响应者让智能体找到每个触及故障服务的标志；flag-graph 在几秒钟内追踪先决标志和依赖标志之间的依赖链，这项工作通常是在页面正在触发时手动在仪表板中 grep 完成的。

发布页面没有提及的

这个技能包只有 19 颗星和 1 个分支——全新的，在任何实际规模上都未经考验，位于一个拥有多年跟踪记录的 8.1k 星核心产品之上。这是两个截然不同的风险状况被捆绑在一个发布标题下。审核门控是一个真正的安全机制，但它也意味着标志管理的繁琐部分——审核 diff——不会消失，只是改变了形态，从"写标志"变成"审核智能体的标志"，在规模上不一定工作量更少，特别是在跨团队并行运行多个智能体、共享 60 请求/分钟 API 上限的情况下。而且明确的范围排除（无 SDK 代码生成、无指标或数据源创建、无 bandit 支持）意味着你的应用代码和标志之间的实际接触点——SDK 调用——仍然完全是手动的。这自动化了你代码周围的标志生命周期，而不是读取标志的代码。

谁真正应该使用这个功能

如果你的团队已经在使用 GrowthBook，或者已经在日常开发中标准化了 Claude Code、Cursor 或 Codex，而你希望你的 AI 智能体在有真实审批门的情况下起草特性标志和实验（而不是共享一个 API key 再加一句系统提示警告），现在就可以尝试。自托管路径除了运行基础设施的成本外，不花一分钱。

如果你的团队需要深度企业治理和合规工具，且这些工具有长期的 incumben 记录——LaunchDarkly 在这个特定领域有更丰富的踩坑经验——或者你对于把一个才上线几天、仅 19 星的项目匆忙放到生产发布控制附近持谨慎态度，认为它还需要更多真实场景的打磨，那就等等再说。

如果你的团队根本不使用 AI 编码智能体，或者你的标志量很低——低到整个前提本身就不成立——AI 智能体需要的不是结构化、速率受限、有审核门的 API 访问，而是一个人点击 UI——那可以跳过。

在发布流水线中，什么才是 AI 智能体应该被允许无监督操作的正确边界——让 AI 智能体在人工审核后面排队，是重新制造了团队当初引入 AI 智能体来避免的同一个审批瓶颈，还是说这个瓶颈本身才是意义所在？

GrowthBook: The product development platform for AI-native teams (Product Hunt)

GrowthBook 5.0: AI Agents Now Operate Flags & Experiments

Your agents shouldn't guess at feature flags and experiments

GrowthBook 5.0: Build, ship, and improve at scale

growthbook/growthbook on GitHub

growthbook/skills on GitHub

GrowthBook Agent Skills docs

GrowthBook vs LaunchDarkly vs Statsig

LaunchDarkly and Growthbook compared (Statsig)

Feature Flags for AI Agents: Release Controls (FeatBit)

Feature Flags Were Always Important. SRE Agents Make Them Essential. (LaunchDarkly)

De-Risking AI Adoption: How Feature Flags Help Enterprises Move Fast Without Breaking Trust (Flagsmith)