一旦 AI agent 从内部工具变成面向客户的产品，很多原本在工程里被默认的东西都会变得敏感。谁能用更强的模型，谁能开浏览器自动化，谁能并发跑 20 个任务，谁只能做只读分析，这些都不再只是系统默认值，而会直接变成价格、体验、安全和毛利的交叉点。
麻烦在于，不少团队会让这几个维度分头增长。产品团队在价格页上写“专业版支持自动执行”，后端团队在配置里只知道“允许某个工具”，安全团队再单独维护一份角色白名单，SRE 则用另一套限流规则控制并发。短期看每条线都在解决自己的问题，长期看系统却越来越难解释：为什么这个客户明明买了高级版，却仍被拦在浏览器 runner 外？为什么某个支持人员临时放开的功能，又顺带打开了高风险外发工具？
这时你会发现，真正缺的不是更多 feature flag，而是一套 entitlement envelope，把套餐、角色、租户策略、工具权限、模型能力和容量边界统一成同一种语言。
建议配合 AI agent 准入控制与配额闸门、AI agent 工具能力协商与环境契约、AI agent 多租户隔离与 Workspace 供给 和 AI agent Policy Engine 规则分层 一起看。
先统一这张表：套餐限制的从来不只是一项功能
| 能力维度 | 常见限制方式 | 真正应该怎么表达 |
|---|---|---|
| 模型能力 | 只能 / 不能用某模型 | 指定可用模型池、fallback 范围与预算上限 |
| 工具能力 | 开 / 关某工具 | 按动作风险、写权限和环境类型定义 capability |
| 并发与吞吐 | 同时可跑多少任务 | 按租户、套餐、时段和任务类型分层 |
| 数据范围 | 能看哪些项目 / 数据集 | 绑定租户作用域与对象级权限 |
| 人工协作能力 | 是否支持 review / approval | 绑定角色和审计要求，而不是只绑价格 |
如果价格页只写“支持高级能力”，而系统里没有对应的 envelope，运营、支持和工程迟早会各自补一层临时判断，最后把权限边界越缝越乱。
Entitlement 不该写进 prompt，它应该先在系统侧收口
有些团队为了快，会把套餐限制直接写进系统提示词，例如“当前用户是标准版，不可使用浏览器工具”。这种方式对 demo 很方便，但一旦进入生产，它的问题就很明显：模型知道了限制，不代表系统真的拦住了限制。
更稳的做法是先在系统侧把可用能力裁好，再让 agent 在这个 envelope 里决策。也就是说，agent 应该看到的是：
- 哪些模型可选
- 哪些工具可调
- 哪类动作必须 review
- 当前预算和并发上限是多少
而不是自己记住整份价格表，然后尝试“遵守”。功能分级只要还靠 prompt 约束，它就还不是生产边界。
真正难的是套餐、角色和临时 override 同时出现时
企业环境里很少只有套餐。通常还会叠加：
- 租户级策略：某个客户禁用某些外发工具
- 角色级策略：管理员能做的，普通操作者不能做
- 临时 override：支持团队为排障或试用临时开一个能力
这时 entitlement 设计最忌讳“谁优先”全靠人记。系统应该显式回答：
- 套餐给的是上限，还是默认值
- 租户策略能不能覆盖套餐
- 临时 override 有多长 TTL，是否自动回收
- override 是否需要审计和复核
如果这些规则说不清，临时开关很快就会从“帮助客户试用”变成权限边界最薄的地方。
并发和容量也属于 entitlement，不只是 SRE 的事
不少团队会把套餐和容量拆开看，觉得一个归产品，一个归基础设施。但 AI agent 的成本和稳定性恰恰要求它们必须绑在一起。比如某个套餐允许浏览器自动化，却不给并发上限，那运营很可能卖出去一个“功能已开”的承诺，基础设施却根本承不住。反过来，如果系统只从容量角度限流，而不理解客户套餐和任务优先级，商业承诺又会被随机打折。
所以更合理的表达不是“高级版能用浏览器工具”，而是“高级版可在指定并发范围内使用浏览器 runner，并允许特定高风险动作进入人工 review 流程”。这句话听起来更长，但它至少把商业和系统的真实边界讲在了一起。
一个经典事故：试用开权限，结果把正式边界也一起打开了
某团队为了推进转化，允许销售支持给试用客户临时开启“自动发布”能力。实现上，他们图快，直接在 feature flag 里对租户打了一个 auto_publish=true。一周后出问题：
- 这个 flag 只管前端入口，不管后台工具 capability
- 后台看到 flag 为 true，就默认允许走真实发布工具
- 某个本该只有内部 staging 环境权限的试用租户，触发了正式外发路径
问题不是“试用客户不该试高级功能”，而是系统没有把 entitlement 当成一份完整 envelope，只做了表层入口控制。
修复后，团队改成 capability bundle：同样是试用高级功能，也只能获得有限并发、staging-only publish 和强制 review。这个例子说明，所谓套餐开关，如果不能落成一组系统边界，就只是另一个容易误导人的按钮。
真正该先补的，是让价格表和权限表说同一种语言
如果你现在正在推进 AI agent 商业化，最值得先做的不是加更多 SKU，而是先把套餐、租户策略、角色权限、工具能力和容量限制收成同一份 entitlement schema。只要这几层还在各自维护术语，系统就会持续出现“产品说能用，后端说不能跑，安全说不该开”的扯裂感。
价格本来就是对边界的承诺。AI agent 的商业化做得稳不稳，最后看的不是你有多少档套餐，而是每一档套餐背后是不是都有一份系统真的能执行的能力边界。
延伸阅读：
