AI agent 一旦进入企业交付阶段，平台最常听到的一句话通常是：“这个客户比较特殊。”最开始这种特殊看起来都很合理。有人要多一条审批规则，有人要屏蔽某个工具，有人要把同一个按钮文案换成内部术语，还有人要求某类任务只能在指定时间窗口运行。单看每一条都不算离谱，于是团队很容易在系统里不断加 if、加 flag、加一层又一层的租户例外。
可租户数一上来，问题就会迅速从“支持定制化”变成“谁也说不清当前这个客户到底在跑哪一套系统”。运营觉得是同一个产品，工程看到的是几十种变体，支持团队则不得不先问清这个客户到底开了哪些隐藏开关，才能判断故障是不是系统问题。到了这一步，真正拖垮平台的已经不是某个复杂功能，而是例外配置失去了边界。
所以 tenant override governance 真正要解决的，不是禁止定制，而是让每一份定制都能被版本化、被追溯、被自动回收。没有这层治理，所谓“灵活”最终都会变成平台无法维护的另一种名字。
建议配合 AI agent Plan Tier Entitlement 与 Tool Gating、AI agent Policy Engine 规则分层、AI agent Version Set Pinning 与 Rollback 和 AI agent 多租户隔离与 Workspace 供给 一起看。
先把“租户配置”从散落 flag 变成 bundle
| 配置类型 | 散落配置时的典型问题 | bundle 化后的好处 |
|---|---|---|
| 工具开关 | 不知道是谁、何时给这个租户开的 | 能看到完整能力边界 |
| Policy 例外 | 规则写在脚本、数据库和配置中心各处 | 可以一起审计和回滚 |
| 模型 / 预算差异 | 客服以为是套餐，工程以为是临时调整 | 能区分产品承诺和临时 override |
| 时间窗口 / 区域限制 | 运维和业务各记一套 | 可以变成统一执行前置条件 |
bundle 的价值不是更好看，而是把“这位客户目前跑的到底是哪一套配置”从一件靠人回忆的事，变成系统自己能回答的事。
真正危险的不是定制多，而是 override 没有作用域
很多平台一开始为了快，会直接给租户打一两个 override 字段，例如 allow_browser=true、review_required=false。这种做法最大的问题不在于粗糙，而在于它没有清楚表达：
- 这个 override 影响哪些任务类型
- 只影响哪个环境
- 是临时生效还是长期生效
- 谁批准过、什么时候该收回
结果就是，一次为排障临时开的例外，很可能几个月后还留在生产里，并且悄悄影响了越来越多本不该受影响的场景。系统最怕的例外不是多，而是例外自己没有边界。
Override 最好带 TTL，不要默认永久有效
企业环境里很多 override 本来就只适合短期存在。比如：
- 为某个上线窗口临时放宽 review 门槛
- 为新集成试运行暂时开放某个高阶工具
- 为排查问题临时增加日志或 probe
如果这些动作默认没有 TTL，平台很容易在半年后回头发现，正式行为其实一直被一堆“临时”配置塑造着。更稳的做法是把 override 当成一种会过期的政策对象，而不是一个被写进数据库后永远不问来历的开关。
一个典型事故：为了救一个客户，顺手污染了同类租户的默认边界
某团队为了帮一位重要客户尽快上线，在周末临时关闭了一段人工 review 门槛，让 agent 在某类低风险场景下能直接外发。因为赶时间，工程同学没做单独 tenant bundle，而是在共享 policy 层加了一条“对某类任务放宽规则”的特判。上线当天问题确实解决了，可几周后他们才发现：
- 另一批同类型租户也命中了这条特判
- 支持团队以为这是产品默认行为
- 审计回看时没人能立刻说清这个例外最初是为谁、为何而加
最后他们不是简单把规则删掉，而是重构成 tenant config bundle：任何租户例外都必须显式声明作用域、审批来源和 TTL。这个改动的意义不是更流程化，而是第一次让例外变成了可管理对象，而不是平台状态的一部分噪音。
真正该先补的，是“例外配置目录”而不是更多开关
如果你现在只能先做一层，优先别急着继续加更细的 flag，而是先让系统能列出某个租户当前有哪些 override、每个 override 影响什么、何时创建、何时过期、能否一键回到基线。只要这份目录还不存在，平台就很难在复杂交付里保持自知。
AI agent 平台迟早会支持定制。真正决定平台能不能长期活下去的，不是你支不支持例外，而是例外有没有被治理成一份清楚的边界，而不是一团历史遗留。
延伸阅读：
