摘要:CrewAI 数字员工跑长任务,Kimi OAuth token 15 分钟就过期,官方没文档。我从 CLI 二进制里逆向出刷新端点,做了跑前刷新加运行中守护续期,冒烟 159 秒跑通,四个团队全部真跑。

token 只活 15 分钟,我从二进制里抠出续命开关

8 月 7 号中午,我在项目部宿舍盯着屏幕,看我的数字员工团队跑到第 17 分钟,啪,401 鉴权失败,整个 crew 当场暴毙。

我 39 岁,白天在高速公路项目部干征迁,晚上用 AI 给自己搭数字员工团队。团队架构铺了 5 个组,常态化上岗的目前 1 个组,跑的是 CrewAI 框架,模型用 Kimi k3。那天本来是大日子,团队停工十来天后复工,结果复工第一跑就死在鉴权上。

死因很快查明:Kimi Code 的 OAuth access_token 只有 15 分钟寿命。我的 crew 一跑就是十几二十分钟,token 死得比任务快。

官方没文档,秘密在 CLI 身体里

我先去翻官方文档,没有。OAuth 刷新接口长什么样、参数怎么传,一个字都没公开。

卡住半天,我换了个思路:Kimi Code 这个命令行工具自己就能续期,它从没让我 15 分钟重登一次。那续期的秘密一定写在它身体里。

身体就是 kimi.exe 那个编译后的二进制。

我从二进制里把字符串全部提取出来,顺藤摸瓜,摸到了三样东西:

• 刷新端点:POST https://auth.kimi.com/api/oauth/token
• 请求格式:form 表单,三个参数,client_id、grant_type=refresh_token、refresh_token
• 一个公开的 client_id

再配合抓行为验证,错误码语义也对齐了:401、403、invalid_grant 说明 refresh_token 作废,得打开一次 Kimi Code 重新登录;429 和 5xx 就退避重试。

到这里,续命的开关算是抠出来了。说实话,从二进制里翻字符串这招,我十几年码龄也没用过几回,这次是真被逼的。

抠出开关只是开始,后面还埋着两个坑

第一个坑,OpenAI SDK 的缓存。

CrewAI 底层走 OpenAI SDK 调接口。我把新 token 写进 api_key,满心以为成了,结果请求照样 401。查了半天才明白,SDK 内部缓存了客户端对象,光改 api_key 它不重建连接。得把缓存的 _client 清掉,新 token 才真正生效。这个坑不实测根本发现不了,代码上看不出任何毛病。

第二个坑更疼,顶号。

我一开始的设计是到点就强制刷新。结果服务端只认最新签发的 token,我的 crew 刷新一次,共享同一份凭证的 Kimi Code CLI 手里的 token 立刻作废,反过来也一样。两边互相顶,谁也别想活。8 月 7 号那天,三次真跑夭折,换来的就这一句话:共享凭证的两边,不能都强制刷新。

最终方案:不抢,轮流用

改完的自动续期长这样,核心四条:

1. 跑前刷新:构建 LLM 之前先检查凭证文件里的 token 新不新鲜,不新鲜立刻刷新;
2. 运行中守护:守护线程默认每 10 分钟查一轮,首轮检查压在启动后 60 秒内,防止 token 死在第一个间隔里;
3. 不强制刷新:凭证文件里已有新鲜 token(哪怕是 CLI 刚刷的)就直接采用,同步到全部 LLM 实例;实在不新鲜,才向服务器换新;
4. 原子写回:写凭证走临时文件加 os.replace 原子替换,每次刷新前重读文件,两边同时刷也不会写坏。

外加一条纪律:失败不许静默。刷新失败每轮向 stderr 大声报错,refresh_token 失效直接以退出码 3 退出,绝不带病续跑。token 值本身不进日志、不进代码、不进提交。

这块我也没完全跑通所有边界,比如 crew 和 CLI 共享凭证,偶发瞬时 401 还存在,会自愈,根治得申请独立凭证。先记账上。

实测数字

8 月 7 号下午,售后组 crew 冒烟真跑:159 秒跑完,烧 1.6 万 token,退出码 0,运行中 2 次续期成功,品控员正常履职。

之后四个团队全部真跑验证通过。引流组 33 分钟、61 万 token 的长跑,放在以前够 token 死两回,现在全程没断气。

能带走的三句话

• 官方没文档的接口,别干等。客户端二进制就是最诚实的文档,提取字符串,顺藤摸瓜,比发邮件问客服快得多。
• 改 key 不生效的时候,先怀疑 SDK 缓存了客户端,这是实测踩出来的,不是猜的。
• 共享凭证的多方续期,设计的核心不是"怎么刷",而是"谁有资格刷"。

15 分钟的 token 都能续命,人也一样,关键得找到那个开关。

你踩过"官方文档没有、只能自己逆向"的接口吗?评论区聊聊,逆出来的东西敢不敢用在生产上。

素材点

1. "token 只能活 15 分钟,我从二进制里抠出续命开关":官方没文档,从 kimi.exe 二进制提取字符串,逆向出刷新端点和公开 client_id。
2. 三次真跑夭折换来"不顶号"设计:服务端只认最新签发的 token,共享凭证的两边不能都强制刷新。
3. CrewAI 走 OpenAI SDK,光改 api_key 不生效,要清缓存的 _client,实测才踩得到的坑。
4. 冒烟实测:159 秒、1.6 万 token、退出码 0、运行中 2 次续期成功,之后四个团队全部真跑。
5. 39 岁项目部码农的复工日:团队停工十天,复工第一跑死在 401 上,当天修好当天复工。

备选标题

1. CrewAI 实战:Kimi token 15 分钟过期,我从二进制抠出自动续期(大词前置型:CrewAI/自动续期)
2. Kimi Code OAuth token 自动续期:官方没文档,我逆向了刷新端点(长尾命中型:OAuth/token 自动续期/刷新端点)
3. 长任务跑到一半 401?你的 token 可能只能活 15 分钟(痛点钩子型:401/长任务)