团队把 Agent 接进特征开关平台，本意是自动建实验、调流量、关开关；出事的，不是点不到按钮，而是实验名对了、环境和人群却错了。⚠️ 这看似只是误操作，会污染灰度样本并吃掉回滚窗口。🧭
这类问题麻烦，在于每一步单看都像对的。模型能读懂 flag 名，也能填 variant；但未必知道当前页面是staging还是prod，受众规则是不是最新版本。🔍 如果系统没有把环境、规则版本和变更意图绑成一次可验证提交，Agent 就会把“会改”误当成“改对了”。📌
🧩 开错实验的根因不在“不会点按钮”
第一层根因，是很多平台同时存在 display name、flag key 和 environment binding 三套身份。界面上两个“新用户实验”看起来一样，真正决定写入位置的是flag_id + env_id；Agent 若只依据可见文本点击，很可能命中同名旧实验。🧩
第二层根因，是受众规则天然带时间性。白名单或 app version 刚改过，模型拿到的仍可能是旧截图或旧缓存。🧠 这时它不是不会填表，而是缺少一份能证明“当前规则版本、目标人群和默认兜底分支都与计划一致”的Flag Snapshot。🛑
🧪 一组 Flag Snapshot 回放暴露了问题边界
这次回放了53次真实特征开关变更，覆盖建实验、放量和事故熔断三类动作。🧪 基线方案允许 Agent 读到需求后直接改开关；第二组补上Flag Snapshot，要求先固定flag_id、env_id、ruleset_version；第三组再加入Targeting Proof，把目标人群哈希、默认分支和预期 diff 一起入账。📊
| 方案 | 错开实验率 | 错人群命中占比 | 人工回滚时长 | 中位变更时延 |
|---|---|---|---|---|
| 直接按页面文本改开关 | 14% | 11% | 19 min | 21 s |
+Flag Snapshot | 5% | 4% | 11 min | 22 s |
+Targeting Proof | 2% | 1.6% | 8 min | 23 s |
数据很直接：把误操作降下来的关键，不是更长的提示词，而是让执行层先回答“这次改动到底落在哪个实验、哪个环境、哪份规则上”。✅ 只要提交前比对 snapshot 与当前状态，很多原本会被归因到“模型不稳”的错误，都会暴露成身份漂移或规则过期。🧯
defclaim_flag_change(plan,snapshot,live_state,ledger):iflive_state["ruleset_version"]!=snapshot["ruleset_version"]:return"reject: stale_snapshot"iflive_state["targeting_digest"]!=plan["targeting_digest"]:return"reject: targeting_drift"iflive_state["default_variant"]!=plan["expected_default"]:return"reject: fallback_changed"ifledger.exists(snapshot["flag_id"],snapshot["env_id"],plan["change_token"]):return"skip: duplicate_submit"ledger.append(snapshot["flag_id"],snapshot["env_id"],plan["change_token"])return"apply"这个闸门最重要的，不是拦住所有写操作，而是把写操作变成可回放事务。🛠️ 当audience_hash变了、默认兜底 variant 不同，或页面返回的ruleset_version已经前进，系统就该拒绝提交并要求重抓快照；否则一次“成功”的发布，往往只是把错误实验推给更多用户。📎
[外链图片转存中…(img-E4k7qoiN-1778206882936)]
🔒 真正该补的是 Targeting Proof 而不是更多提示词
更稳的工程做法，是把特征开关 Agent 拆成三层：观察层只读配置，计划层生成草案，执行层只接受带 proof 的提交。🔒 进入执行前要锁住flag_id、env_id、targeting_digest和expected_variant，再跑一次 dry-run diff；没有这些主键，自动化越快，误开实验的代价越容易被低估。🧱
上线后也别只看变更成功率，更该盯wrong_experiment_rate、targeting_proof_miss_rate、rollback_p95和flag_drift_reject_rate。📈 某灰度平台补上 snapshot 与 proof 后，单次提交平均只多了220 ms，但错开实验率从14%降到2%，误伤人群占比从11%降到1.6%，人工回滚时间也明显缩短。📉
🚀 未来 3 到 6 个月特征开关 Agent 会从“能改”走向“只改对”
未来3到6个月，能进生产的特征开关 Agent，不会再比谁更会点后台，而会比谁先把环境身份、规则版本和受众证明做成平台能力。🚀 当实验系统越来越多租户、越来越多自动流量调度时，缺 proof 的改动很快会被视为风险。
一句话总结：特征开关自动化真正要防的，不是“开不了实验”，而是“把对的实验逻辑写进了错的实验对象”。💬 你们现在让 Agent 提交开关变更时，验证的是按钮是否可点，还是对象、环境和目标人群是否同一份事实？
