开源项目推荐｜Unleash：用 Feature Flags 安全灰度发布 AI 功能

AI 变更不应该只有发布或不发布

传统功能在测试通过后通常表现稳定，AI 功能却会同时受模型、Prompt、检索、工具和内容分布影响。一个新模型在离线样本上更好，不代表所有租户、语言和长尾请求都会改善。如果代码一部署就让全部用户切换，团队很难区分版本问题，也缺少快速缩小影响面的开关。

Unleash 是开源 Feature Management 平台。Feature Flags 可以让代码部署与功能释放分离，并按环境配置 activation strategy。官方文档支持渐进比例、用户或业务分群、约束和 variants；stickiness 可让同一用户持续进入同一变体，避免每次请求随机切换体验。

官方仓库：https://github.com/Unleash/unleash

AI Feature Flag 应该控制什么

不要只设置一个 ai_enabled。更实用的粒度包括：是否显示 AI 入口、使用哪个模型或 Prompt 版本、是否启用新检索器、哪些租户可以调用写工具、失败时回到什么路径。每个 Flag 只表达一个清晰决策，并约定负责人、预期寿命和删除条件。

变体 payload 可以携带配置标识，但不应直接存放模型密钥或完整 Prompt。应用根据标识读取受版本控制的配置，AnyAIS 则统一模型入口、API Key、额度与日志。这样 Flag 决定谁看到哪个方案，平台记录实际调用了什么，两者可以通过用户、租户、会话和请求 ID 关联。

从内部流量开始逐步扩大

典型顺序是开发环境、内部账号、指定试点租户、小比例稳定流量，再逐步扩大。分流键应选择稳定的 userId 或 tenantId；同一 DASP 会话中途切换模型或 Prompt 可能破坏上下文一致性，因此可以在会话创建时固定变体，并将版本写入会话元数据。

每个阶段先定义停止条件：任务成功率下降、人工接管增加、延迟或单次成本超过阈值、风险事件出现时，立即关闭新变体或回到旧路径。Feature Flag 本身不负责判断质量；监控系统和运营人员需要根据 AnyAIS 用量、应用反馈与业务指标执行回滚。高风险输出还可由独立模型做抽样复核，复核结果只作为发布证据之一。

A/B 变体不等于可靠实验

Unleash variants 能稳定分配不同体验，但真正实验还需要明确假设、样本范围、主指标和护栏指标。不要在同一时间同时更换模型、Prompt、检索和界面，否则即使结果变化也无法定位原因。对企业客户还要避免把同一组织的成员拆到互相冲突的流程中，通常按 tenantId 保持粘性更合适。

发布记录应包含 Flag 配置、变体、模型与 Prompt 版本、开始和结束时间。达到百分之百后仍要观察一个稳定窗口，然后删除临时 Flag 和旧代码路径。长期遗留的开关会形成组合爆炸，让测试与排障越来越困难。

Feature Flag 不能替代权限系统

Flag 适合控制发布范围，却不是授权边界。客户端看到关闭状态，不代表服务端可以省略权限验证；涉及 MCP 写操作、数据导出和付款时，仍要进行身份、租户、策略和人工审批检查。SDK 或 Flag 服务异常时，也要为 AI 功能定义安全默认值，通常是回到已验证版本或暂停高风险动作。

Unleash 与 AnyAIS 可以把“发布给谁”和“实际调用什么”分开管理。先用一个模型切换 Flag 完成内部灰度，再逐步增加指标与回滚流程。

参考资料：

• Unleash Feature Flags 概念：https://docs.getunleash.io/concepts/feature-flags
• Unleash Activation Strategies：https://docs.getunleash.io/concepts/activation-strategies
• Unleash 创建渐进发布 Flag：https://docs.getunleash.io/guides/how-to-create-feature-flags
• Unleash 官方仓库：https://github.com/Unleash/unleash