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