# Lesson 04｜资源治理：多账号额度巡检与自动重排

# 核心问题

当你把 OpenClaw 真正用到“每天都在跑”的强度时，瓶颈很快就不是“会不会写 prompt”，而是账号/额度/鉴权的治理：

• 多个模型账号并行使用，谁先用、谁兜底、谁已经过期？
• 一旦某个账号 401/额度耗尽，任务会不会整条链路崩掉？
• 你怎么保证“每天早上看到的结果”是可信的，而不是昨晚 cron 失败的残影？

# 真实案例（带证据）

案例 A：Codex 多账号额度巡检 + auth order 自动重排

• 做法：先读取 auth-profiles，预检 token；再拉 usage（wham/usage）；按规则排序；写回 openclaw models auth order set；最后发简报。
• 证据1：明确了执行逻辑与排序规则（“日剩余% + 5h剩余%”）。
  • sessionKey: agent:main:cron:d2cf6089-a0cb-4c97-a1d1-530986396d37:run:c7b058f0-0806-4776-bb3d-19baf8792a66
  • time: 2026-03-04T00:46:39.424Z
  • quote: “每天凌晨 3 点…读取…auth-profiles…调用…wham/usage…按‘日剩余% desc, 5h剩余% desc’排序…”
• 证据2：排序结果被写入并可读回（Order override 列表）。
  • sessionKey: agent:main:cron:d2cf6089-a0cb-4c97-a1d1-530986396d37:run:c7b058f0-0806-4776-bb3d-19baf8792a66
  • time: 2026-03-04T00:48:03.661Z
  • quote: “Order override: openai-codex:…@outlook.com, …”

案例 B：cron 自动调度失败后的补跑闭环

• 结论：“自动失败 ≠ 任务逻辑失效”。要把失败说清楚（时间 + 原因），然后手动补跑拿到真实结果。
• 证据1：指出“昨天凌晨自动调度失败”，状态 error，原因 fetch failed。
  • sessionKey: agent:main:telegram:group:-1003807921933:topic:4375
  • time: 1772415862224
  • quote: “昨天凌晨那次自动调度是失败的… 状态 error… 原因 fetch failed”
• 证据2：随后“重跑好了，已成功”。
  • sessionKey: agent:main:telegram:group:-1003807921933:topic:4375
  • time: 1772416092486
  • quote: “重跑好了，已成功 ✅… 任务状态 ok”

# 错误尝试 / 失败点（你很可能也会踩）

1. 只做“拉额度”不做“健康检查”：token 过期/401 时，usage 请求本身就会失败。
2. 只在出事后手工改顺序：这会让“调度系统”退化成“人肉值班”。
3. 改完顺序不复核：写回失败或没生效，你以为兜底在，实际下一次照样崩。
4. 混淆自动失败与逻辑失败：cron error 可能是网络抖动/超时，不代表流程不可跑。

# 关键转折（从“能跑”到“可治理”）

把“额度/账号”当作一等公民：

• 先做健康检查（鉴权），再做额度采样（usage），最后做策略决策（排序）。
• 每次策略更新都要有读回验证与可视化简报。
• 遇到 error 先把“失败发生在哪里”说清楚，再决定“加参数抗抖”还是“补跑出结果”。

# 可复用 SOP（建议直接抄到你们的团队脚本里）

目标：每日自动给出“可用账号优先级”，并在失败时可快速补跑。

1. 读取配置：auth profiles 列表（来源 Unknown，取决于你们部署路径）。
2. Token 预检：对每个 profile 做一次轻量验证（401/过期标红）。
3. 额度采样：对通过预检的账号拉 usage（短窗 + 日窗）。
4. 排序策略：
   • 主排序：日剩余% desc
   • 次排序：5h 剩余% desc
   • 账号不可用（401/采样失败）直接排到末尾或剔除
5. 写回 order：openclaw models auth order set ...
6. 立即读回：openclaw models auth order get（或等价接口）确认生效。
7. 简报输出：
   • 当前排序
   • 不可用账号清单（原因：401/采样失败/Unknown）
   • “本次是否为自动补救/手动补跑”标识
8. cron 失败处理：
   • 先从日志提取：失败时间 + 错误字符串
   • 区分：自动调度失败 vs 逻辑失败
   • 需要时手动补跑并回传“核心指标”（排序 + 需要修复账号）

# 课后作业

1. 把你们当前的模型调用账号列出来，做一个最小版“健康检查 + 额度采样”脚本（先不排序也行）。
2. 写下你们的排序规则（别用“凭感觉”）：至少包含一个主排序字段和一个次排序字段。
3. 设计一条简报消息模板：包含“排序 + 不可用账号 + 失败原因（若有）”。
4. 思考题：当所有账号都不可用时，你的系统应该输出什么？（建议写 Unknown 也要写清楚 Unknown 的边界）