Agent 灰度最容易被照抄的是微服务那套流量比例：5% → 20% → 50% → 全量。这套对无状态服务成立，对 Agent 不成立。同一个用户这次落在 5% 的桶里，下次落到 95% 的桶，拿到的是另一个脾气的东西——工具调用风格变了、拒答边界变了、连回答长度都变了。这不是灰度，这是给用户随机抽奖。我的做法是按用户/租户切，切进去就不回退。
按流量切，等于让同一个用户前后拿到两个东西
Agent 的行为不幂等。改一句 system prompt、换一段工具描述、调一下重试策略，同样的输入出来就不一样。用户感知到的不是"这功能有 5% 概率是新版本"，而是"这东西今天怎么怪怪的"。
多轮对话更麻烦。第一轮走旧版本，第二轮走新版本，上下文是同一份，风格直接断层。会话级粘性能救一部分，但只保证一次对话内一致，用户隔天回来照样撞上另一个版本。
而且 Agent 的失败大多不是报错，是"答得挺顺但错了"。流量灰度那套靠 5xx、延迟、错误率做熔断，在 Agent 上基本全瞎。
TV4 那件事说明，有些操作压根不该进灰度池
瑞典 TV4 因为 AI agent 抹掉已剪辑素材，把节目推迟到 2027。几百天的工作没了。
重点不是"agent 不可靠"，是灰度边界画错了。写文件、删数据、发邮件、动钱——这类不可逆动作不该出现在任何比例的灰度池里，应该直接卡在人工确认后面。灰度是给"错了还能改"的行为用的。可逆性是灰度的前提，不是灰度的产出。
按租户切，样本量确实小，这点我不辩
一个 B 端产品，前十个租户加起来可能就几百个日活会话。拿这几十个会话算成功率，置信区间宽得能跑马。指标噪音大是真的，某个客户那天心情不好多问几句，曲线就抖。
反方说"要拉长观察期"，我同意一半。拉长解决样本量，代价是反馈变慢——两周才敢下判断，迭代节奏就废了。
我的折中是：主判据不用成功率这种聚合指标，用事件密度。具体说，盯人工介入率——每百次会话里有多少次是人接手、人重跑、人改答案。这个指标在几十个会话的量级上就比成功率稳，因为它数的是"人被迫下场"这种离散事件，不是模型自我感觉。
别拿"看起来还行"当指标
这周有篇写 AI coding agent 的：代码产出涨了，软件没多出来。同一周还有一篇更扎心的，有人删了 16.8 万行注释，agent 全程没反应。
两篇指向同一件事：Agent 的"正常运行"信号特别廉价。它不会因为上下文被你搞坏了就报错，照样输出，照样自信。所以灰度看板上如果只有延迟、token 数、调用成功率，你看到的是全绿，实际已经烂了。
人工介入率是少数能穿透这层的东西。它不完美——介入标准会漂，不同值班同学松紧不一——但比"agent 自己说没事"可信得多。
档位怎么排
三档够用，再多就是流程表演。
内部租户先上，自己人天天用，出错直接骂到脸上。这一档主要不是验证功能，是验证你的看板和告警能不能真的抓到问题——很多团队的监控在这一步才发现是摆设。
然后是低风险场景租户，找那些用错一次代价可控的客户，比如内部知识问答、文档草稿。避开合同、账单、对外发送。
最后全量，但不可逆动作仍然挂在人工确认后面。
每档至少一周。一周不是为了攒样本量，是为了跨过一个完整的工作周期——周一早上的行为和周五下午不一样，只跑三天你会漏掉一半。
切了不回退，这条我态度比较硬。回退看着安全，实际是把"新版本有问题"这个信号抹掉了，团队学不到东西，下次还踩。真出事，正确做法是往前修。前提是留好后路：租户级开关要有，但开关的语义是"这个租户先停在新版本外面"，不是"全体回滚"。
一个还没想清楚的地方
多租户 SaaS 里，租户之间常常不隔离。A 租户的 agent 和 B 租户共享同一套 prompt、同一套工具。你按租户切，切的是入口，不是底层。所以"低风险租户"这一档的实际保护力比看上去弱——除非 agent 配置真的按租户隔离了。
Itaú 那个案例里提到他们专门做了个 IARA 治理平台，我猜就是干这个的。银行那种监管环境，不敢让所有租户跑同一份配置。
这条我暂时没答案。按我现在看，租户隔离的成本比想象中高，但如果你的 agent 会动真东西，这笔钱省不掉。