用途：以账户实时合同为准，而非在代码中写死套餐名或数字限制，动态获取 SerpAPI 容量并据此实施准入、并发与重试预算，防止 429 并协调共享凭据的多个工作负载。
主要能力：通过 Account API 读取 plan_searches_left、total_searches_left、this_hour_searches、account_rate_limit_per_hour 等字段；将剩余容量换算为每个工作进程的准入预算，预留交互与故障流量余量；施加共享并发限制器与队列，优先拒绝或推迟低优先级任务；在 429 时暂停新准入、刷新账户信息，区分吞吐量耗尽与搜索配额耗尽；按分类与重置策略决定是否重试，并限制尝试次数、加入抖动避免同步突发；用假客户端压测、低于账户上限做金丝雀，并对容量消耗速率和持续 429 告警。
使用方式：服务端保存 SERPAPI_KEY 供 Account API 与搜索调用使用；用 Read/Glob/Grep 盘点生产者与重试循环，用 WebFetch 核实 Account API 与状态语义，用 Write/Edit 编写准入控制与可观测性，用 Bash(python3:*) 做容量检查或负载模拟。示例：account = client.account()；hourly_limit = int(account["account_rate_limit_per_hour"])；used_this_hour = int(account["this_hour_searches"])；headroom = max(0, hourly_limit - used_this_hour)；admission_budget = max(0, int(headroom * 0.8))。
适用场景：多个工作进程共享同一 SerpAPI 密钥、需要防止 429、需要按优先级分配搜索预算、或需在续期及新增工作进程时重新评估容量的场景。
限制：Account API 不可用时需按保守缓存预算失败关闭并设过期；吞吐量耗尽时应暂停排空而非立即重试；搜索配额耗尽时应停止消耗额度的工作并联系账户所有者；存在多个未协调工作进程时应先引入共享限制器再增加并行度。HTTP 429 本身无法区分是小时吞吐超限还是搜索配额用尽，需结合响应字段与账户刷新判断。具体平台支持、价格与配额数值以账户实时数据为准，资料未提供固定值。