为了帮助企业管理员合理控制 AI 智能体(Agent)的成本与使用强度,ClawPro 在管控端的平台策略中提供了两类 Tokens 上限配置:单用户 Tokens 上限 和 全局 Tokens 上限。本文将系统介绍两类上限的工作机制,并辅以可直接对照的示例,方便管理员理解并实施合理的 Tokens 上限管控。
基本概念
ClawPro 的 Tokens 上限分为单用户 Tokens 上限和全局 Tokens 上限两个互相独立、同时生效的层级:
| 上限类型 | 含义 | 控制粒度 | 达到上限后的影响 |
|---|---|---|---|
| 单用户 Tokens 上限 | 单个用户在所选周期内最多可消耗的总 Tokens 数量 | 每位用户独立计数(同分组下每个用户也是各自独立的额度) | 该用户停服,不影响其他用户;下个周期或管理员上调上限后恢复 |
| 全局 Tokens 上限 | 所有用户使用所有模型在所选周期内最多可消耗的总 Tokens 数量 | 多用户共享池计数(一群用户合计消耗同一个池;池的圈定范围由实际配置决定,可能是全部用户、同一分组的用户或全部无分组用户,详见后文的策略生效原理) | 对应池下全部用户停服;下个周期或管理员上调上限后恢复 |
说明:两个上限同时生效,取严判定。即一次 AI 调用必须同时满足该用户未超单用户上限和该用户所属池未超全局上限才会成功;任意一项达到上限即停服。
第一部分:单用户 Tokens 上限
策略构成
单用户 Tokens 上限由以下要素构成:
| 策略构成 | 具体类型 | 含义 |
|---|---|---|
| 应用范围 | 预设策略 | 作用于未匹配任何分组策略的所有用户中 <strong>每位用户</strong> 的 Tokens 上限,策略仅 1 条,不可删除。 |
| 分组策略 | 作用于所选分组中 <strong>每位用户</strong> 的 Tokens 上限,策略可设置 0 ~ N 条,可删除。 | |
| 时间周期 | 自然周期 | 按<strong>日历自然边界</strong>(每日 / 每月 / 每年)滚动计数,到边界后已消耗 Tokens 自动清零并开启下一周期。 |
| 自定义周期 | 由管理员在策略上<strong>独立配置开始时间、终止时间和刷新方式</strong>(每日刷新 = 1 天、每月刷新 = 31 天、每年刷新 = 365 天,或不刷新),按设定时长滚动计数。 | |
| 配额 | Tokens 上限值 | 每条策略(预设策略 / 分组策略)单独配置的 Tokens 数量上限,代表<strong>一位用户在一个周期内最多可消耗的 Tokens</strong>;该周期内累计消耗达到此值时,对应用户即被停服,直到下个周期自动刷新或管理员上调上限后恢复。 |
应用范围规则
ClawPro 按以下规则匹配单用户 Tokens 上限策略:
- 没有分组的个人用户:
- 在添加新用户时,该用户的单用户 Tokens 上限会自动使用预设策略,管理员也可以针对该用户进行调整。
- 设置好单用户 Tokens 上限之后,预设策略再怎么修改,都不会影响已存在的没有分组的用户,按各自的配置继续滚动。
- 后续新增的没有分组的用户会按最新预设策略进行初始化。
- 有分组的用户:
- 不管是已在分组的用户还是新加入分组的用户,始终实时引用当前命中的策略(分组策略或预设策略),策略修改后立即生效。
- 没有设置任何分组策略时:分组统一都使用预设策略。
- 设置了分组策略时:分组将优先采用本分组策略;本分组无则采用上级分组的分组策略;均无则使用预设策略。
- 若用户属于多个分组,用户将在用户端创建 Agent 时自行选择分组,该 Agent 即按所选分组对应的策略生效。
示例 1:仅配置预设策略
- 配置:预设策略 = 100,000 Tokens / 每月,未添加任何分组策略。
- 未加入分组的用户:新添加的用户默认走预设策略,每位用户各自独立享有 100,000 Tokens / 每月;存量用户保持各自的额度配置,不受预设策略变动影响。
- 加入分组的用户:分组使用预设策略,分组里的每位用户各自独立享有 100,000 Tokens / 每月。
示例 2:分组层级向上匹配
- 分组层级:总公司 >技术中心 > 研发部 > AI 攻坚组。
- 配置:预设策略 = 100,000 Tokens / 每月;「技术中心」分组策略 = 300,000 Tokens / 每月;「AI 攻坚组」无单独策略。
- 用户 X 属于「AI 攻坚组」:本分组无策略 → 上级分组「研发部」无策略 → 上级分组「技术中心」有策略,用户 X 命中 300,000 Tokens / 每月。
- 用户 Y 属于「财务部」:由于财务部无任何本分组策略,也无任何上级分组策略,因此财务部的用户 Y 使用预设策略 100,000 Tokens / 每月。
示例 3:用户兼岗多个分组
- 用户 Z 因兼岗同时归属「市场部」和「品牌部」两个分组。
- 配置:「市场部」分组策略 = 200,000 Tokens / 每月;「品牌部」分组策略 = 100,000 Tokens / 每月。
- 用户 Z 在用户端创建 Agent 时,会被要求必须选择一个归属分组:
- 选择「市场部」→ 该 Agent 走 200,000 Tokens / 每月 上限;
- 选择「品牌部」→ 该 Agent 走 100,000 Tokens / 每月 上限。
- 用户 Z 可同时拥有归属于不同分组的多个 Agent,每个 Agent 各自按所选分组对应的上限独立计数。
时间周期规则(自然周期)
设置单用户 Tokens 上限时,必须选定其中一个时间周期类型:自然周期、自定义周期。选择后,所有策略统一使用同一种时间周期类型。
自然周期:时间说明
按日历自然边界计数,到边界自动刷新(已消耗 Tokens 清零)。
| 周期长度 | 起算时间 | 周期范围示例 |
|---|---|---|
| 每日 | 每天 0:00 | 2026-06-09 00:00 ~ 2026-06-09 23:59 |
| 每月 | 每月 1 号 0:00 | 2026-06-01 00:00 ~ 2026-06-30 23:59 |
| 每年 | 1 月 1 日 0:00 | 2026-01-01 00:00 ~ 2026-12-31 23:59 |
说明:
- 起算时间使用控制台所在时区的本地时间。
- 自然周期下,所有用户共享统一的刷新时刻(所有人在同一时刻刷新)。
示例 4:自然周期 · 每月(仅预设策略)
- 配置:自然周期 · 每月,预设策略 = 100,000 Tokens / 每月,未添加分组策略。
- 用户 A 在 2026-06-30 23:50 累计消耗 85,000 Tokens,剩余 15,000 Tokens。
- 2026-07-01 00:00 周期切换:用户 A 已消耗清零,可用额度恢复为 100,000 Tokens。
示例 5:自然周期 · 每月(混合策略)
- 配置:自然周期 · 每月,预设策略 = 100,000 Tokens;分组策略「研发部」= 300,000 Tokens;分组策略「市场部」= 200,000 Tokens。
- 企业拥有「研发部」「市场部」「财务部」「人事部」四个分组。
- 用户分布与生效情况:
| 用户 | 所在分组 | 命中策略 | 6 月可用额度 |
|---|---|---|---|
| 用户 A | 研发部 | 分组策略「研发部」 | 300,000 Tokens |
| 用户 B | 市场部 | 分组策略「市场部」 | 200,000 Tokens |
| 用户 C | 财务部(无策略,无上级策略) | 使用预设策略 | 100,000 Tokens |
| 用户 D | 人事部(2026-06-15 入职) | 使用预设策略 | 100,000 Tokens(从 2026-06-15 起算消耗,但仍按 6 月自然边界与所有人一起在 2026-07-01 00:00 刷新) |
| 用户 E | 兼岗研发部和市场部 | 创建 Agent 时自选分组 | 选研发部 → 300,000 Tokens;选市场部 → 200,000 Tokens |
- 2026-07-01 00:00 所有用户已消耗清零,新月统一开始计数。
自然周期:修改预设策略
预设策略修改并保存后:
- 已存在的没有分组的个人用户 → 不受影响,仍按各自的上限值滚动;
- 分组下使用预设策略的用户 → 立即按新上限值结算后续消耗,已计入当前周期的消耗不清零,可能立即超额停服;
- 新增的没有分组的用户 → 按最新预设策略初始化。
示例 6:自然周期 · 修改预设策略上限值
- 配置:自然周期 · 每月,预设策略 = 100,000 Tokens / 每月,研发部、财务部均无分组策略。
- 现有用户:
- 老员工 A:无分组,2026-04-15 添加进企业,6月已消耗 80,000 Tokens;
- 员工 C:财务部(分组无策略,使用预设策略),6月已消耗 80,000 Tokens。
- 2026-06-09 14:00 管理员把预设策略上限调整为 200,000 Tokens/ 每月。
- 影响:
- 老员工 A(无分组):不受影响,仍是 100,000 Tokens / 每月,剩余 100,000 - 80,000 = 20,000 Tokens;
- 员工 C(财务部使用预设策略):立即生效,新上限 200,000 Tokens / 每月,已消耗 80,000 Tokens 保留计入,剩余 120,000 Tokens;
- 2026-06-15 新加入的员工 E(无分组):按新预设策略 = 200,000 Tokens / 每月。
自然周期:修改 / 删除分组策略
- 修改分组策略:上限值或周期长度调整后立即生效,命中分组的用户使用新值,当前周期已消耗的 Tokens 继续累计。
- 删除分组策略:该分组按生效原理改成新策略(上级分组策略 → 预设策略)。命中分组的用户使用新值,当前周期已消耗的 Tokens 继续累计。
示例 7:删除分组策略后使用预设策略(自然周期 · 每月)
- 配置:自然周期 · 每月,预设策略 = 100,000 Tokens / 每月;分组策略「市场部」= 500,000 Tokens / 每月。
- 2026-06-15,市场部用户 G 在6月已消耗 400,000 Tokens(在分组策略下属于正常水位)。
- 管理员删除「市场部」分组策略。
- 用户 G 改用预设策略 100,000 Tokens / 每月,已消耗 400,000 Tokens 全部落在 2026-06-01 ~ 2026-06-30 自然周期窗口内,全部计入 预设策略统计。
- 结果:用户 G 已消耗 400,000 Tokens > 100,000 Tokens,立即停服,直到 2026-07-01 00:00 自然刷新或管理员调整分组策略。
自然周期:切换为自定义周期
自然周期切换为自定义周期后:
- 所有分组策略被清空,需重新添加;
- 预设策略保留原上限值,原自然周期的周期长度自动映射为自定义周期同名的刷新方式:每日 → 每日刷新;每月 → 每月刷新;每年 → 每年刷新;
- 没有分组的用户不受影响,仍按各自配置继续滚动;
- 「分组下使用预设策略」的分组按新预设策略生效,分组开始时间 = 切换确认时刻(同时被记为新的「预设策略最新保存时间」);
- 已消耗 Tokens 中落在新周期窗口内的部分保留计入,窗口外的不计入。
示例 8:自然周期 → 自定义周期
- 切换前:自然周期 · 每月,预设策略 = 100,000 / 每月,分组策略「研发部」= 500,000 / 每月。
- 2026-06-09 14:00 管理员切换为「自定义周期」并确认。
- 切换后:
- 自定义周期,预设策略 = 100,000,刷新方式 「每月刷新」(由「每月」自动映射),预设策略最新保存时间 = 2026-06-09 14:00;
- 分组策略「研发部」被清空,需要管理员重新配置;
- 切换前没有分组的老员工保留各自的上限和原有时间周期继续滚动,不受切换影响;
- 财务部(原使用预设策略)切换后新窗口为 2026-06-09 14:00 ~ 2026-07-10 13:59,已消耗 Tokens 中落在新窗口外的部分不计入新周期统计。
自定义周期
由管理员独立为每条策略配置开始时间、终止时间和刷新方式,更适合短期试点、季度考核、合同周期等非自然边界场景。
| 字段 | 说明 |
|---|---|
| 开始时间 | 策略生效起点。预设策略 没有显式开始时间,由系统自动取值(详见下表)。 |
| 终止时间 | 策略到期时间。预设策略固定为「永不终止」;分组策略可填具体时间,也可置空。 |
| 刷新方式 | 「不刷新 / 每日刷新 / 每月刷新 / 每年刷新」,决定 Tokens 的滚动统计窗口。 |
预设策略的开始时间取值规则:
| 适用对象 | 开始时间取值 |
|---|---|
| 没有分组的新增用户 | 默认以 用户加入企业的时间 为开始时间,可在「用户管理」中针对单个用户单独调整 |
| 未匹配任何分组策略的分组 | 以 预设策略最新保存时间 为开始时间 |
刷新方式的工作机制:
- 不刷新:在 [开始时间, 终止时间] 整个生效期内累计计数,到达上限即停服直至终止时间。
- 每日 / 每月 / 每年刷新:从「开始时间」起按对应固定长度滚动,每个滚动周期到期消耗清零(不强制对齐自然边界)。三种刷新长度的具体定义为:
| 刷新方式 | 一个滚动周期的长度 |
|---|---|
| 每日刷新 | 24 小时 |
| 每月刷新 | 31 天 |
| 每年刷新 | 365 天 |
注意: 自定义周期下「每月刷新」恒按 31 天计算,不会因为 2 月 28/29 天、4 月 30 天而缩短;「每年刷新」也恒按 365 天计算,不会因为闰年而变成 366 天。
示例 9:自定义周期 · 每月刷新(仅预设策略)
- 配置:自定义周期,预设策略 = 100,000 Tokens,刷新方式「每月刷新」(即每 31 天滚动一次),未添加任何分组策略,预设策略最新保存时间 = 2026-05-20 14:35。
- 全部用户均走预设策略,但「没有分组的用户」与「有分组的用户(包括新加入分组的用户)」起算时间规则不同:
| 用户 | 加入企业时间 | 所在分组 | 开始时间取值 | 终止时间 | 滚动周期(每月 = 31 天) |
|---|---|---|---|---|---|
| 用户 A | 2026-03-15 09:20 | 无分组 | 默认 = 加入企业时间 → 2026-03-15 09:20 | 永不终止 | 3/15 09:20 ~ 4/15 09:19、4/15 09:20 ~ 5/16 09:19、5/16 09:20 ~ 6/16 09:19 …… |
| 用户 B | 2026-04-20 16:48 | 无分组 | 添加用户时管理员手动调整为 2026-05-08 09:00(管理员可在添加用户时覆盖默认值) | 永不终止 | 5/8 09:00 ~ 6/8 08:59、6/8 09:00 ~ 7/9 08:59 …… |
| 用户 C | 2026-02-10 10:30 | 研发部(分组无单独策略,使用预设策略) | 因属于分组,按 预设策略最新保存时间 起算 → 2026-05-20 14:35 | 永不终止 | 5/20 14:35 ~ 6/20 14:34、6/20 14:35 ~ 7/21 14:34 …… |
| 用户 D | 2026-06-08 11:00 新加入研发部 | 研发部(同上,使用预设策略) | 与用户 C 一致,按 预设策略最新保存时间 起算 → 2026-05-20 14:35 | 永不终止 | 同用户 C |
- 关键差异说明:
- 没有分组的用户:默认以「加入企业时间」为开始时间,终止时间为「永不终止」;管理员可在「用户管理 > 添加用户」时手动调整开始时间,已添加的用户也可在用户详情中调整。
- 有分组的用户(无论是否新加入):只要属于某个分组,就完整走分组的策略匹配链路。本示例中所有分组都没有单独配置分组策略,因而最终都使用预设策略,分组对应的开始时间统一取「预设策略最新保存时间」,终止时间默认「永不终止」,同分组下所有用户的滚动周期完全一致。
示例 10:自定义周期 · 每月刷新(混合策略)
- 配置:
- 预设策略 = 100,000,刷新方式「每月刷新」(每 31 天),预设策略最新保存时间 = 2026-05-20 14:35。
- 分组策略「研发部」= 300,000,开始 2026-05-22 09:30,刷新方式「每月刷新」,永不终止。
- 分组策略「市场部」= 200,000,开始 2026-06-08 10:00,终止 2026-12-08 18:00,刷新方式「每月刷新」。
- 用户分布与生效情况:
| 用户 | 加入企业时间 | 所在分组 | 命中策略 | 开始时间 | 终止时间 | 滚动周期(每月 = 31 天) |
|---|---|---|---|---|---|---|
| 用户 A | 2026-04-01 10:15 | 研发部(有分组策略) | 分组策略「研发部」 | 2026-05-22 09:30 | 永不终止 | 5/22 09:30 ~ 6/22 09:29、6/22 09:30 ~ 7/23 09:29 ……每月独立享 300,000 |
| 用户 B | 2026-03-01 14:20 | 市场部(有分组策略) | 分组策略「市场部」 | 2026-06-08 10:00 | 2026-12-08 18:00 | 6/8 10:00 ~ 7/9 09:59、7/9 10:00 ~ 8/9 09:59 ……每月独立享 200,000;2026-12-08 18:00 之后用户 B 处于策略生效期外,无任何 Tokens 可用——既不会自动改用预设策略,也不会继续使用市场部策略;只有当管理员删除「市场部」分组策略或为该用户的分组配置新的分组策略后,用户 B 才会重新匹配到预设策略或新的分组策略 |
| 用户 C | 2026-02-01 11:40 | 财务部(分组无策略) | 使用预设策略 | 财务部按 预设策略最新保存时间 起算 → 2026-05-20 14:35 | 永不终止 | 5/20 14:35 ~ 6/20 14:34、6/20 14:35 ~ 7/21 14:34 ……每月独立享 100,000 |
| 用户 D | 2026-06-15 09:45 加入企业,无分组 | —— | 使用预设策略 | 按 加入企业时间 起算 → 2026-06-15 09:45(管理员可在添加用户时调整) | 永不终止 | 6/15 09:45 ~ 7/16 09:44、7/16 09:45 ~ 8/16 09:44 ……每月独立享 100,000 |
提示: 自定义周期下,「无分组的用户」按各自的加入企业时间起算,刷新时刻彼此独立;「有分组的用户」按所命中策略的开始时间起算,同一策略下所有用户的刷新时刻一致;这与自然周期「全员同时在自然边界刷新」的特性形成鲜明对比。
修改预设策略
预设策略保存后(每次保存都会刷新「预设策略最新保存时间」):
- 已存在的没有分组的个人用户 → 不受影响,仍按各自固化的上限值与开始时间继续滚动;
- 分组下使用预设策略的分组 → 上限值立即更新,且分组的开始时间会同步更新为「预设策略最新保存时间」,从该时刻起重新滚动一个新周期;
- 新增的没有分组的用户 → 按最新预设策略快照初始化(开始时间默认 = 加入企业时间,可在添加用户时调整)。
示例 11:自定义周期 · 修改预设策略
- 配置:自定义周期,预设策略 = 100,000,刷新方式「每月刷新」(每 31 天),原预设策略最新保存时间 2026-05-20 14:35,研发部、财务部均无分组策略。
- 现有用户:
- 老员工 A:无分组,加入企业时间 2026-03-15 09:20(开始时间默认沿用),当前周期 5/16 09:20 ~ 6/16 09:19 内已消耗 60,000;
- 员工 C:财务部(使用预设策略),分组开始时间 = 2026-05-20 14:35,当前周期 5/20 14:35 ~ 6/20 14:34 内已消耗 60,000。
- 2026-06-09 14:00 管理员将预设策略上限调整为 200,000 并保存,预设策略最新保存时间随即更新为 2026-06-09 14:00。
- 影响:
- 老员工 A(无分组):不受影响,仍按 100,000 上限和原开始时间 2026-03-15 09:20 继续滚动,已消耗 60,000 保留;
- 员工 C(财务部使用预设策略):上限立即变为 200,000;财务部分组的开始时间同步更新为 2026-06-09 14:00,新周期变为 6/9 14:00 ~ 7/10 13:59,已消耗 60,000 中落在新窗口外的部分不计入新周期(仍可在 Tokens 监控历史中查询);
- 2026-06-15 09:45 新加入的员工 E(无分组):按新预设策略快照,上限 200,000,开始时间默认 = 入职时间 2026-06-15 09:45。
修改 / 删除分组策略
- 修改分组策略:上限值或刷新方式调整后立即生效,命中分组的用户按新上限累计当前周期消耗,已消耗不清零。
- 删除分组策略:该分组的用户改为按生效原理就近匹配的策略(上级分组策略 → 预设策略)。已消耗 Tokens 中:
- 落在新策略当前周期窗口内的部分 → 保留并计入 新策略统计;
- 落在新策略当前周期窗口外的部分 → 不计入 新策略统计(但 Tokens 监控页历史数据仍可查询)。
示例 12:删除分组策略后使用预设策略(自定义周期)
- 配置:自定义周期,分组策略「市场部」开始 2026-04-01 09:00、每月刷新(每 31 天);预设策略最新保存时间 2026-05-20 14:35。
- 用户 D(市场部):5/1 ~ 5/31 累计消耗 30,000;6/1 09:00 ~ 6/15 11:00 累计消耗 50,000。
- 2026-06-15 11:00 管理员删除「市场部」分组策略。
- 用户 D 改用预设策略,市场部分组的当前周期窗口 = 2026-05-20 14:35 ~ 2026-06-20 14:34(按预设策略最新保存时间起算)。
- 结果:5/1 ~ 5/19 的 30,000 中落在新窗口外的部分不计入;5/20 14:35 之后的消耗(包括 6/1 09:00 ~ 6/15 11:00 的 50,000)计入新周期统计。
切换为自然周期
切换会触发 二次确认弹窗。确认后:
- 所有分组策略被清空,需重新添加;
- 周期长度 完全以管理员在下拉框中选择的「每日 / 每月 / 每年」为准,系统不会根据原刷新方式做自动推断;
- 预设策略保留原上限值,自定义周期专用字段(开始时间、终止时间、刷新方式)被清空;
- 没有分组的用户不受影响,仍按各自固化的上限值与开始时间继续滚动;
- 已消耗 Tokens 落在新自然周期窗口内的部分保留并计入。
示例 13:自定义周期 → 自然周期
- 切换前:自定义周期,预设策略 = 100,000,刷新方式「每月刷新」,分组策略「研发部」= 300,000,开始 2026-05-22 09:30,每月刷新。
- 管理员在下拉框中选择「自然周期 · 每年」并确认。
- 切换后:
- 自然周期 · 每年,预设策略 = 100,000 / 每年。不会因为原刷新方式是「每月刷新」而映射成「每月」;
- 分组策略「研发部」被清空,需要管理员重新配置;
- 没有分组的老员工保留各自的上限值与时间周期,仍按个人配置滚动,不会立刻进入自然年度计数;
- 研发部(原走分组策略,切换后无策略)改用预设策略,按自然年度边界结算,已消耗中落在 2026-01-01 ~ 2026-12-31 内的部分计入新周期统计。
设置入口与查看入口
设置入口
管控端**>基础信息>平台策略>**配额设置 > 单用户 Tokens 上限 卡片:
- 点击卡片顶部周期类型右侧的铅笔图标,选择自然周期或自定义周期。
- 在卡片正文中编辑预设策略和分组策略的上限值与时间字段。
- 点击添加分组策略可针对特定分组单独配置例外策略。
查看入口
| 角色 | 页面 | 可看到的内容 |
|---|---|---|
| 管理员 | 管控端 > 用户管理 | 在每位用户行内查看其当前命中的策略来源(「预设策略」或某条分组策略名)和上限值;自定义周期下可对单个用户的开始时间做覆盖调整 |
| 管理员 | 管控端 > Tokens 监控 > 按用户 | 在所选时间范围内查看每个用户的 Token 消耗,按总 Tokens 降序,用于核对是否有用户接近或达到上限 |
| 管理员 | 管控端 > Tokens 监控 > 按分组 | 验证分组策略是否生效 |
| 普通用户 | 用户端顶部导航 > 模型额度 | 查看自己当前命中的策略、当前周期、上限值、已消耗、剩余额度等。仅当允许用户查看模型额度开关开启时可见 |
第二部分:全局 Tokens 上限
策略构成
全局 Tokens 上限同样由「预设策略 + 分组策略」两类策略共同构成。但与单用户上限不同,两类策略管控的对象都是「分组(或分组集合)合计消耗的总 Tokens」:
| 策略类型 | 数量 | 适用范围 | 是否可删除 |
|---|---|---|---|
| 预设策略 | 仅 1 条 | 默认作用于「未匹配任何分组策略」的每个分组(每个分组各自独立享一个池)以及所有无分组用户(所有无分组用户合并共享同一个预设池) | 否 |
| 分组策略 | 0 ~ N 条 | 针对所选分组下所有用户 合计 消耗的 Tokens 总量配置的独立池子 | 是 |
关键差异(与单用户上限对比):
- 单用户分组策略「市场部 = 200,000」= 市场部 每位用户 各自享有 200,000;
- 全局分组策略「市场部 = 200,000」= 整个市场部全员合计 共享 200,000 的池子,无论市场部有多少用户,都消耗这同一个池子。
策略生效原理
全局 Tokens 上限的策略匹配逻辑与单用户 Tokens 上限 完全一致,仍遵循「分组策略优先 → 上级分组策略 → 预设策略」的就近匹配原则:
- 无需按分组设置策略时,直接使用「预设策略」:每个分组各自独立享一个预设上限值的池,所有无分组用户合并共享同一个预设池。
- 需要按分组设置策略时,添加「分组策略」,优先采用本分组策略;本分组无则采用最近的上级分组策略;均无则使用「预设策略」。若上级分组也有策略,下级分组用户的消耗会同时扣减「自身命中池」和「上级分组池」(嵌套池规则,详见示例 15)。若用户属于多个分组,由用户端创建 Agent 时自行选择的分组决定该 Agent 走哪条策略链路(即扣减哪些池子)。
示例 14:仅配置预设策略
- 配置:预设策略 = 1 亿 / 每月,未添加分组策略。
- 池子分布:未匹配分组策略的每个分组各自独立享一个 1 亿预设池;所有无分组用户合并共享同一个 1 亿预设池。任一池子用尽即对应分组 / 无分组用户群体停服,其他池不受影响。
示例 15:分组层级向上匹配(嵌套池规则)
- 分组层级:
总公司 > 技术中心 > 研发部或测试部,配置「技术中心」分组策略 = 5000 万 / 每月,「研发部」「测试部」无单独策略。 - 因「研发部」「测试部」均向上匹配到「技术中心」策略,每个分组都独立享有一个 5000 万池,且上级分组池的计数包含其下全部子分组用户:
| 池子 | 计数对象 | 上限 |
|---|---|---|
| 研发部池 | 研发部全员合计消耗 | 5000 万 / 每月 |
| 测试部池 | 测试部全员合计消耗 | 5000 万 / 每月 |
| 技术中心池 | 技术中心直属 + 研发部 + 测试部 全员合计消耗 | 5000 万 / 每月 |
- 研发部用户的每一次调用同时扣减「研发部池」和「技术中心池」;测试部用户的每一次调用同时扣减「测试部池」和「技术中心池」。
- 任意一个池子达到 5000 万,对应池下所有用户立即停服:
- 仅研发部池满 → 仅研发部停服,测试部、技术中心其他用户仍可继续使用,直到自身池子用尽;
- 技术中心池满 → 技术中心、研发部、测试部 全员停服(即便子分组池尚未用尽)。
示例 16:用户兼岗多个分组
- 配置:分组策略「市场部」= 1000 万 / 每月;分组策略「品牌部」= 500 万 / 每月。
- 用户 Z 同时归属「市场部」和「品牌部」。在用户端创建 Agent 时由用户 Z 自选归属分组:
- 选「市场部」→ 该 Agent 的消耗扣减「市场部」1000 万池;
- 选「品牌部」→ 该 Agent 的消耗扣减「品牌部」500 万池。
- 同一个用户的不同 Agent 可能扣减不同的全局池。
周期类型与计算规则
每个上限项必须先选定时间周期类型,该上限项下的所有策略(预设 + 所有分组)统一使用同一种周期类型,不会出现混合。可选两种:自然周期和自定义周期。
全局 Tokens 上限的「计数对象」为:
| 上限类型 | 周期内计数对象 |
|---|---|
| 单用户 Tokens 上限 | 每位用户独立计数 |
| 全局 Tokens 上限 | 每个分组策略池 或 每个预设池(未匹配分组策略的每个分组各自独立享一个预设池;所有无分组用户合并共享同一个预设池);上级分组若也有策略,其池计数包含全部子分组用户的消耗(嵌套池) |
关键产品规则(修改策略时贯穿两个周期):
全局 Tokens 上限的修改与切换行为与单用户 Tokens 上限 结构对称,但因计数对象是「分组池合计」,不存在「单个用户独立时间周期」——所有用户都属于某个池(分组策略池或预设池),策略修改对池中全部用户即时生效。
下面对每种周期类型,分别说明:
(1) 周期长度与起算规则的应用示例;
(2) 修改预设策略的影响;
(3) 修改或删除分组策略的影响;
(4) 切换为另一种周期类型的影响。
自然周期
按 日历自然边界 计数,到边界自动刷新(已消耗 Tokens 清零)。
| 周期长度 | 起算时间 | 周期范围示例 |
|---|---|---|
| 每日 | 每天 0:00:00 | 2026-06-09 00:00:00 ~ 2026-06-09 23:59:59 |
| 每月 | 每月 1 号 0:00:00 | 2026-06-01 00:00:00 ~ 2026-06-30 23:59:59 |
| 每年 | 1 月 1 日 0:00:00 | 2026-01-01 00:00:00 ~ 2026-12-31 23:59:59 |
说明:
- 起算时间使用控制台所在时区的本地时间。
- 自然周期下,所有池共享统一的刷新时刻(所有池在同一时刻刷新)。
示例 17:自然周期 · 每月(仅预设策略)
- 配置:自然周期 · 每月,预设策略 = 1 亿 Tokens / 每月,未添加分组策略。
- 池子分布(未匹配分组策略的每个分组各自独立享一个 1 亿预设池;所有无分组用户合并共享一个 1 亿预设池):假设企业拥有「研发部」「市场部」两个分组与若干无分组用户,则形成研发部池 1 亿、市场部池 1 亿、无分组用户合并池 1 亿,共 3 个独立池。
- 2026-06-09,研发部池累计消耗 6500 万、剩余 3500 万;市场部池与无分组用户合并池各自独立计数、互不影响。
- 2026-07-01 00:00:00:所有池子同时清零,剩余额度均恢复为 1 亿。
示例 18:自然周期 · 每月(混合策略)
- 配置:自然周期 · 每月,预设策略 = 1 亿;分组策略「研发部」= 2 亿;分组策略「市场部」= 5000 万。
- 企业拥有「研发部」「市场部」「财务部」「人事部」四个分组,另有无分组的两名用户 P、Q。
- 各对象命中策略与池子对应关系(未匹配分组策略的每个分组各自独立享一个预设池;所有无分组用户合并共享同一个预设池):
| 对象(分组 / 个人) | 命中策略 | 上限 | 计数方式 |
|---|---|---|---|
| 研发部 | 分组策略「研发部」 | 2 亿 / 每月 | 研发部全员合计消耗 |
| 市场部 | 分组策略「市场部」 | 5000 万 / 每月 | 市场部全员合计消耗 |
| 财务部 | 预设策略 | 1 亿 / 每月 | 财务部全员合计消耗(独立预设池) |
| 人事部 | 预设策略 | 1 亿 / 每月 | 人事部全员合计消耗(独立预设池) |
| 用户 P、用户 Q(均无分组) | 预设策略 | 1 亿 / 每月 | P 和 Q 合并共享同一个预设池,二人累计消耗合并扣减 |
- 各池互不影响,任一池子用尽仅导致 该池下用户停服,其他池子不受影响。
- 兼岗用户 Z 同时属于「市场部 + 品牌部」(品牌部无分组策略 → 品牌部独享一个 1 亿预设池):用户 Z 在用户端创建 Agent 时选择「市场部」则扣减市场部池,选择「品牌部」则扣减品牌部预设池。
- 2026-07-01 00:00:00:所有池子同时清零。
修改预设策略
预设策略保存后:
- 每个使用预设策略的池(未匹配分组策略的各分组各自独立池 + 全部无分组用户的合并池)→ 各自独立按新上限值结算后续消耗,已计入当前周期的累计消耗不清零;
- 各分组策略池不受影响。
示例 19:自然周期 · 修改预设策略(调低导致超额)
- 配置:自然周期 · 每月,预设策略 = 1 亿 / 每月;财务部、人事部等无分组策略 → 各自独立享 1 亿预设池;无分组用户 P、Q 合并共享一个 1 亿预设池。
- 2026-06-09 各预设池水位:
| 对象(分组 / 个人) | 命中策略 | 上限 | 已消耗 | 剩余 | 计数方式 |
|---|---|---|---|---|---|
| 财务部 | 预设策略 | 1 亿 / 每月 | 8000 万 | 2000 万 | 财务部全员合计消耗 |
| 人事部 | 预设策略 | 1 亿 / 每月 | 3000 万 | 7000 万 | 人事部全员合计消耗 |
| 用户 P、用户 Q(均无分组) | 预设策略 | 1 亿 / 每月 | 4000 万(P + Q 合计) | 6000 万 | P、Q 合并共享同一个预设池 |
- 管理员把预设策略调整为 5000 万 / 每月。
- 影响:
- 财务部池:原池消耗 8000 万 > 新上限 5000 万,财务部全员立即停服;
- 人事部池:原池消耗 3000 万 < 新上限 5000 万,正常继续;
- 无分组用户合并池:原池消耗 4000 万 < 新上限 5000 万,P、Q 仍可继续合用,共享池剩余 1000 万。
- 直到 2026-07-01 00:00 自然刷新或管理员再次上调上限。
修改 / 删除分组策略
- 修改分组策略:上限值或刷新方式调整后立即生效,命中分组池按新上限继续累计当前周期消耗,已消耗不清零。
- 删除分组策略:该分组改为使用预设策略,即该分组 独立获得一个预设上限值的新池,原池已消耗 Tokens 全部计入 该分组的新预设池当前自然周期统计。
示例 20:自然周期 · 删除分组策略后该分组获独立预设池
- 配置:自然周期 · 每月,预设策略 = 1 亿;分组策略「研发部」= 2 亿。
- 2026-06-09:研发部池本月已消耗 6000 万(在自身 2 亿池下正常)。
- 管理员删除「研发部」分组策略。
- 研发部改用预设策略,独立获得 1 亿 / 每月的新池。已消耗 6000 万全部落在 2026 年 6 月自然周期窗口内,全部计入 研发部新预设池。
- 结果:研发部池累计 6000 万 < 1 亿,正常使用,不会影响财务部、人事部等其他预设池。
切换为自定义周期
切换会触发 二次确认弹窗。确认后:
- 所有分组策略被清空,需重新添加;
- 预设策略保留原上限值,原周期长度自动映射为同名「刷新方式」(每日 → 每日刷新、每月 → 每月刷新、每年 → 每年刷新),开始时间 = 切换确认时刻(同步记为新的「预设策略最新保存时间」);
- 切换后每个分组各自独立获得一个新的预设池;所有无分组用户合并共享同一个新的预设池,开始时间统一为切换确认时刻;
- 已消耗 Tokens 中落在新周期窗口内的部分保留计入,窗口外的不计入。
示例 21:全局上限自然周期 → 自定义周期
- 切换前:自然周期 · 每月,预设策略 = 1 亿 / 每月,分组策略「外包账号」= 1000 万 / 每月。
- 2026-06-09 14:00 管理员切换为自定义周期并确认。
- 切换后:
- 自定义周期,预设策略 = 1 亿,刷新方式 「每月刷新」(由「每月」自动映射),开始时间 = 2026-06-09 14:00;
- 分组策略「外包账号」被清空,外包账号独立获得 1 亿预设池;
- 全部分组(含外包账号)各自独立获得一个新的预设池;所有无分组用户合并共享一个新的 1 亿预设池;6/1 00:00 ~ 6/9 14:00 之间的消耗中,仅落在新窗口(6/9 14:00 ~ 7/10 13:59)内的部分保留计入。
自定义周期
由管理员独立为每条策略配置开始时间、终止时间和刷新方式,更适合短期试点、季度考核、合同周期等非自然边界场景。
| 字段 | 说明 |
|---|---|
| 开始时间 | 策略生效起点。预设策略 没有显式开始时间,由系统自动取值(详见下表)。 |
| 终止时间 | 策略到期时间。预设策略固定为「永不终止」;分组策略可填具体时间,也可置空。 |
| 刷新方式 | 「不刷新 / 每日刷新 / 每月刷新 / 每年刷新」,决定 Tokens 的滚动统计窗口。 |
预设策略的开始时间取值规则:
| 适用对象 | 开始时间取值 |
|---|---|
| 未匹配任何分组策略的分组 | 以 预设策略最新保存时间 为开始时间 |
| 所有没有分组的用户(合并共享一个预设池) | 以 预设策略最新保存时间 为开始时间 |
刷新方式的工作机制:
- 不刷新:在 [开始时间, 终止时间] 整个生效期内累计计数,到达上限即停服直至终止时间。
- 每日 / 每月 / 每年刷新:从「开始时间」起按对应固定长度滚动,每个滚动周期到期消耗清零(不强制对齐自然边界)。三种刷新长度的具体定义为:
| 刷新方式 | 一个滚动周期的长度 |
|---|---|
| 每日刷新 | 24 小时 |
| 每月刷新 | 31 天 |
| 每年刷新 | 365 天 |
注意: 自定义周期下「每月刷新」恒按 31 天计算,不会因为 2 月 28/29 天、4 月 30 天而缩短;「每年刷新」也恒按 365 天计算,不会因为闰年而变成 366 天。
示例 22:自定义周期 · 不刷新(仅预设策略)
- 配置:自定义周期,预设策略 = 100 亿 Tokens,刷新方式「不刷新」,预设策略最新保存时间 = 2026-04-08 09:30。
- 池子分布(未匹配分组策略的每个分组各自独立享一个预设池;所有无分组用户合并共享同一个预设池):每个分组各自独立享一个 100 亿池、所有无分组用户合并共享一个 100 亿池,开始时间统一为 2026-04-08 09:30,整个生效期内不刷新,任一池用尽即对应分组 / 无分组用户群体停服。
- 适用于按合同总量结算的场景。
示例 23:自定义周期 · 每月刷新(混合策略)
- 配置:
- 预设策略 = 1 亿 Tokens,刷新方式「每月刷新」(每 31 天),预设策略最新保存时间 = 2026-05-20 14:35。
- 分组策略「研发部」= 2 亿,开始 2026-05-22 09:30,刷新方式「每月刷新」,永不终止。
- 分组策略「外包账号」= 1000 万,开始 2026-06-08 10:00,终止 2026-12-08 18:00,刷新方式「不刷新」。
- 各对象命中策略与池子对应关系(未匹配分组策略的每个分组各自独立享一个预设池;所有无分组用户合并共享同一个预设池):
| 对象(分组 / 个人) | 命中策略 | 上限 | 起算时间 | 终止时间 | 滚动周期 |
|---|---|---|---|---|---|
| 研发部 | 分组策略「研发部」 | 2 亿 / 每月 | 2026-05-22 09:30 | 永不终止 | 5/22 09:30 ~ 6/22 09:29、6/22 09:30 ~ 7/23 09:29 …… |
| 外包账号 | 分组策略「外包账号」 | 1000 万(不刷新) | 2026-06-08 10:00 | 2026-12-08 18:00 | 整段累计;终止后该池关闭,外包账号在新分组策略未配置前无 Tokens 可用 |
| 财务部 | 预设策略 | 1 亿 / 每月 | 按预设策略最新保存时间 → 2026-05-20 14:35 | 永不终止 | 5/20 14:35 ~ 6/20 14:34、6/20 14:35 ~ 7/21 14:34 …… |
| 人事部 | 预设策略 | 1 亿 / 每月 | 同上 → 2026-05-20 14:35 | 永不终止 | 同上 |
| 全部无分组用户(合并池) | 预设策略 | 1 亿 / 每月 | 按预设策略最新保存时间 → 2026-05-20 14:35 | 永不终止 | 同财务部 / 人事部 |
说明: 与单用户 Tokens 上限不同,全局 Tokens 上限下「无分组用户」不再按各自加入企业时间独立成池,而是 所有无分组用户合并共享同一个预设池,开始时间统一锚定到「预设策略最新保存时间」,与无策略的分组保持一致的滚动节奏。
修改预设策略
预设策略保存后(每次保存都会刷新「预设策略最新保存时间」):
- 每个使用预设策略的独立池 → 上限值立即更新,且 开始时间同步更新为「预设策略最新保存时间」,从该时刻起重新滚动一个新周期;
- 各分组策略池不受影响。
示例 24:自定义周期 · 修改预设策略
- 配置:自定义周期,预设策略 = 1 亿,刷新方式「每月刷新」(每 31 天),原预设策略最新保存时间 2026-05-20 14:35。财务部、人事部等无分组策略,各自独立享 1 亿池。
- 当前周期 5/20 14:35 ~ 6/20 14:34 内,财务部池累计消耗 6000 万。
- 2026-06-09 14:00 管理员把预设策略调整为 2 亿,并保存(预设策略最新保存时间随即更新为 2026-06-09 14:00)。
- 影响:
- 财务部池、人事部池等所有使用预设策略的池上限均立即变为 2 亿;
- 各池开始时间同步更新为 2026-06-09 14:00,新周期变为 6/9 14:00 ~ 7/10 13:59;
- 财务部池已消耗 6000 万中 落在新窗口外的部分不计入新周期统计(仍可在 Tokens 监控历史中查询)。
修改 / 删除分组策略
- 修改分组策略:上限值或刷新方式调整后立即生效,命中池按新上限累计当前周期消耗,已消耗不清零。
- 删除分组策略:该分组改为使用预设策略,即该分组 独立获得一个预设上限值的新池。已消耗 Tokens 中落在新池当前周期窗口内的部分保留计入,窗口外的部分不计入。
示例 25:自定义周期 · 删除分组策略后该分组获独立预设池
- 配置:自定义周期,预设策略 = 1 亿、刷新方式「每月刷新」、预设策略最新保存时间 2026-05-20 14:35;分组策略「研发部」= 2 亿、开始 2026-04-08 09:30、每月刷新。
- 2026-06-15 11:00:财务部预设池当前周期(5/20 14:35 ~ 6/20 14:34)累计消耗 6000 万(不受影响);研发部池在 5/8 09:30 ~ 6/8 09:29 周期消耗 6000 万、6/8 09:30 起当前周期已消耗 3000 万。
- 管理员删除「研发部」分组策略。
- 研发部改用预设策略,独立获得 1 亿新池,窗口起算于 2026-05-20 14:35。研发部已消耗中:
- 5/20 14:35 ~ 6/8 09:29 的部分(落在新窗口内)→ 计入研发部新池;
- 6/8 09:30 ~ 6/15 11:00 的 3000 万 → 全部计入研发部新池;
- 5/8 09:30 ~ 5/20 14:34 的部分(落在新窗口外)→ 不计入。
- 财务部、人事部等其他预设池不受影响。
切换为自然周期
切换会触发 二次确认弹窗。确认后:
- 所有分组策略被清空,需重新添加;
- 周期长度 完全以管理员在下拉框中选择的「每日 / 每月 / 每年」为准,系统不会根据原刷新方式做自动推断;
- 预设策略保留原上限值,自定义周期专用字段(开始时间、终止时间、刷新方式)被清空;
- 全部分组各自独立获得一个新的预设池;所有无分组用户合并共享同一个新的预设池,按下拉选择的自然边界结算;
- 已消耗 Tokens 落在新自然周期窗口内的部分保留并计入。
示例 26:全局上限自定义周期 → 自然周期
- 切换前:自定义周期,预设策略 = 1 亿、刷新方式「每月刷新」,分组策略「研发部」= 2 亿、开始 2026-05-22 09:30、每月刷新。
- 管理员在下拉框中选择「自然周期 · 每月」并确认。
- 切换后:
- 自然周期 · 每月,预设策略 = 1 亿 / 每月。不会因为原刷新方式是「每月刷新」而自动保持每月;
- 分组策略「研发部」被清空,研发部独立获得 1 亿 / 每月预设池;
- 全部分组和用户按自然月度边界结算,已消耗中落在 2026 年 6 月内的部分保留计入。
设置入口
管控端 > 基础信息 > 平台策略 > 模型配额 > 全局 Tokens 上限 卡片:
- 点击卡片顶部周期类型右侧的铅笔图标,选择自然周期或自定义周期。
- 在卡片正文中编辑预设策略和分组策略的上限值与时间字段。
- 点击添加分组策略可针对特定分组单独配置独立的总池上限。
查看入口
| 角色 | 页面 | 可看到的内容 |
|---|---|---|
| 管理员 | 管控端 > Tokens 监控 顶部总览卡片 | 当前周期下企业累计消耗的总 Tokens、剩余额度、占比;接近或达到上限时顶部会显示告警条 |
| 管理员 | 管控端 > Tokens 监控 > 按实例 / 按用户 / 按模型 / 按分组 | 各 Tab 的「合计」与全局 Tokens 上限是同一口径数据,便于从不同维度溯源全局消耗 |
| 普通用户 | 用户端 > 模型额度 | 不直接展示全局上限;当全局上限达到后,用户在使用 AI 时会收到「企业总配额已用尽」的提示 |
注意: 全局 Tokens 上限达到后,对应分组池下所有用户的 AI 服务都会暂停,直到进入下一个周期或管理员上调上限/扩大池子。
跨周期已消耗 Tokens 的处理规则
无论是「修改预设策略」「修改/删除分组策略」还是「切换时间周期类型」,凡是涉及周期窗口变化的场景,都遵循以下统一原则:
已消耗 Tokens 中,落在新周期窗口内的部分保留并计入新周期统计;落在新周期窗口外的部分,不计入新周期统计。
注意: 「不计入新周期统计」不等于「数据被清空」。Tokens 监控页仍可按时间范围检索到这些历史消耗记录,仅是不再参与「当前周期是否超额」的判定。
附录:页面路径速查
| 页面 | 路径 | 说明 |
|---|---|---|
| 平台策略 | 管控端 > 基础信息 > 平台策略 | Tokens 上限、Agent 数量上限、功能权限开关的统一配置入口 |
| 用户管理 | 管控端 > 用户管理 | 查看 / 调整单个用户的命中策略与开始时间 |
| Tokens 监控 | 管控端 > Tokens 监控 | 按实例 / 用户 / 模型 / 分组 多维度查看 Token 消耗 |
| 模型额度 | 用户端顶部导航 > 模型额度 | 普通用户查看自身的当前周期与剩余额度(需开启「允许用户查看模型额度」) |
如需了解功能权限开关、Agent 数量上限等其他平台策略,请参考[平台策略总览]文档(待补充)。