企业功能与模型试点

新功能或模型的企业试点，应在开启之前明确参与范围、成功标准、预算及负责人。官方建议覆盖至少一个完整计费周期，通常四到六周；这与用于建立习惯的两周团队 onboarding sprint 不同。

定义可判断的目标

预先记录采用率、成本上限与反馈标准，并选取能够代表真实工作、经验水平和团队流程的参与者。不要试用结束后才挑选对结果有利的指标。

功能和模型的组织政策通常依据许可证授予来源生效。组织成员身份本身不足以证明会受试点政策控制；检查每位用户实际从哪里获得席位，以及企业政策是否允许组织修改相关值。具体例外和团队模型规则见企业与组织政策及多重授权冲突。

如果使用专门的试点组织，还需要处理仓库访问和上下文。对依赖真实仓库环境的 cloud agent，单纯把人移到一个空组织无法复现完整流程。

在开启之前配置边界

确认特性已满足组织要求，再在预期的组织层级设置政策。保存前检查影响范围，避免把组织试点误设为全企业开放。治理教程建议及时评估并开放适用功能，但这不是跳过组织自身审核的要求；默认开放行为和生效日期以未配置功能与模型为准。

同时为参与者准备许可、客户端、登录和项目访问。政策开启与用户确实可用需要分别验证。

估算使用量并设置预算

估算参与人数、较高使用强度下的消耗和可使用的企业共享池，再确定愿意承担的额外计量费用。共享池属于企业，不应默认把某个试点人数对应的额度当成隔离保留给该组的专用额度。

普通支出预算主要约束共享池耗尽后的计量费用。达到数额时是否停止使用取决于配置，创建时需检查 Stop usage when budget limit is reached，不能只填金额就假设会硬停止。

Universal user-level budget 则将个人从共享池及计量部分消耗的额度一起计入，并始终是硬限制。它可限制单个用户消耗，但也可能妨碍正常试点。配置层级、优先级和零值行为见用户预算与支出预算。

同时观察使用、费用和实际任务

采用趋势用于判断持续使用，开发者反馈说明成功与失败的原因，费用记录则检验预估是否合理。初期没有额外费用，可能只是仍在消耗共享池，不能据此推断扩大使用后的成本。

代理任务还应抽查会话内容与行为。审计日志能够说明政策何时被修改，但不等同于完整任务过程；查看范围和留存限制见Agent 会话监控与审计日志。

形成明确决定

达到计划周期后，对照原先标准选择扩大、延长观察或停止。报告应包括采用趋势、实际费用、代表性反馈、质量与治理观察，而非只展示总请求数。

扩大时分阶段增加组织并同步调整预算；证据不足时继续收集；停止时关闭试点功能或模型政策，通知参与者，并核对残留使用及预算设置。保留结果，为后续重新评估提供依据。