角色数量设上限
首期角色数量要写死，例如不超过四个，新增角色需说明合并或替换哪一个。角色越多，交互路径增长越快，测试越覆盖不住。上限不是为了限制能力，而是让复杂度可见，避免在不知不觉中膨胀。
场景白名单
明确哪些业务类型、哪些合同或单据类型进入首期，其余一律不接。白名单要写进配置而不是文档，越界请求直接拒答并记录。没有白名单，边缘场景会不断涌入，把评测样本逐渐稀释掉。
轮次预算与降级
给每个场景设轮次预算，超出即降级到单角色或人工，而不是继续尝试。降级路径要在设计阶段就实现，不能等出问题再补。有降级，新增场景的风险可控；没有降级，一次异常就会拖垮整条链路。
变更走评审
新增角色、放宽上限、扩大白名单都属于变更，应经过评审并评估对评测集的影响。评审不必复杂，但要留下结论与责任人。没有评审，配置会在日常运维中被逐步放宽，最终回到失控的状态。
适用与不适用
适合谁
- 已出现角色与场景不断追加的项目
- 多团队共用一套编排、缺少统一入口的组织
不适合谁
- 角色与场景天然收敛的单点应用场景
- 不愿意设上限、要求全场景覆盖的诉求
典型场景
某团队的多角色流程上线一个月，角色从三个加到七个，场景从两类扩到六类，平均轮次翻倍。项目经理把角色上限设为四个、场景白名单固定为两类，超出即降级到单角色，并把新增需求统一进需求池评审，轮次随后回落。
可执行步骤
- 把首期角色数量与场景白名单写进配置，越界请求一律拒答
- 为每个场景设置轮次预算，并实现对应的降级与转人工路径
- 新增角色或放宽上限时，一律走变更评审并留下书面结论
- 每月公开需求池的排序，并向提出方说明取舍理由与排期
- 把越界请求逐条记入日志，作为后续是否扩围的评估依据
常见坑
- 角色随需求自然增长，交互路径指数上升，测试覆盖不住，缺陷集中在组合场景。
- 白名单只写在文档里，配置未生效，边缘场景照样进入，评测样本被逐步稀释。
- 没有降级路径，异常输入就把轮次预算耗尽，用户长时间等待后仍拿不到结果。
自检与验收清单
- 首期角色数量是否已设上限并对外公示
- 场景白名单是否已写入配置并生效
- 每个场景是否有轮次预算与降级路径
- 变更是否经过评审并留下可查的结论
常见问题
上限会不会限制业务创新？
上限针对首期，不是永久。扩围按批次进行，每批都要用评测证明有效。没有上限的创新往往变成堆角色，最后没人说得清哪个角色在起什么作用，创新反而被拖住。
降级后用户体验怎么保证？
降级要给出明确提示，例如已转人工并告知处理方式，而不是静默返回半成品。降级率也应被监控，上升说明白名单或上限设置有问题，需要回头调整而不是继续加角色。
白名单外的需求怎么处理？
进需求池并给出评估结论：需要哪些新角色、对轮次与评测的影响、预计批次。让提出方看到代价，多数需求会自行收敛；确有价值的，按批次扩围并补充评测样本。