代理跑着跑着突然停了，多半不是程序崩了，是它手里那把钥匙过期了。我见过最惨的一个，量化策略跑了 89 天，距离默认过期就差一天，整个交易进程卡住，等发现的时候已经错过了两个关键行情。先别急着改代码，三步把这个坑填了。
真相：钥匙有保质期
AI 代理能自动付款，靠的不是你的人类私钥，而是一把临时签发的"会话钥匙"。你授权的时候给这把钥匙设了一个使用期限——到点了，智能账户自动拒收它的签名，代理发什么都无效。
这其实是个安全设计，不是 bug。没有这个过期机制，代理一旦被黑，攻击者可以一直用你的钱包付款，直到你把授权撤掉。过期相当于自动切断风险。但问题在于，很多人在设置代理的时候没注意到这个期限，或者直接把期限拉满（比如 180 天），结果到期的时候完全没准备，代理停在半路。
步骤 1：先确认你现在被哪种过期卡住了
情况 A：会话过期
典型表现：代理日志里有
Session expired、invalid session、validUntil相关错误原因：代理钱包（尤其是基于 ERC-4337 智能账户的方案）在创建会话时设了 TTL（Time-to-Live），到期后智能账户拒绝接受该 session key 的签名
Hyperliquid 的例子：代理默认 90 天过期，最长可设 180 天，通过在
agentName里加valid_until时间戳控制
情况 B：Refresh Token 过期
典型表现：用 Dynamic 这类服务商时，代理报
refreshExp到达上限，refreshAuthToken()返回 401原因：用户 JWT 的刷新次数或时间到达了服务端的硬上限，必须重新走一遍用户的签名授权流程才能恢复
步骤 2：查你当前会话还剩多少时间
[做什么] 找到会话的剩余有效期，确认是不是快到了。
[怎么做]
查代理创建时的配置文件或代码，找到
validUntil或ttl相关的参数如果是 Hyperliquid，看
agentName里附加的时间戳如果是基于 ERC-4337 的钱包，查 session key 的
validUntil字段，看 ETA 是什么时候如果是 Dynamic，检查你存储的 JWT 的
refreshExp字段，这是不可延长的硬上限
[完成标准] 拿到一个明确的时间点（比如"2026-11-15 03:00 UTC"），对比当前时间，知道还剩多久。
步骤 3：正确续期，别傻等
情况 A：会话过期了
如果是可配置的过期（比如 Hyperliquid 的 valid_until），你需要撤销旧会话，重新签发一把新钥匙。过程和你第一次创建代理时一样：
生成新的 session keypair
在授权请求里带上新的
valid_until时间戳用你的主账户签名批准
注意：有些工具包（如 @cinaconnect/session-keys）支持 rotate 操作，可以在不中断服务的情况下轮换 session key。能旋转就别撤销重建，少一次停机的窗口。
情况 B：Refresh Token 过期了
Dynamic 的机制是：refreshExp 到达后无法延长，必须重新走一次用户登录/授权流程。如果你的代理跑在 autonomous mode 下，重新触发 sign-in 流程是自动的——前提是你把 agent signing token 保管好了。如果丢了，永久失去该用户钱包的访问能力。
[怎么做]
如果是人类用户，需要重新登录并签名授权
如果是 autonomous 模式，SDK 会自动检测 401 并重新执行 sign-in，前提是 agent signing token 未泄露且可用
高危提醒：Dynamic 明确警告——refreshExp 是服务端的硬上限，不是软限制。刷新失败返回 401 后，任何 refreshAuthToken() 调用都会失败，只能重新登录。设计代理逻辑的时候，必须捕获这个错误并触发重新授权流程，否则代理会一直卡在 401 循环里，你不在日志里看到根本发现不了。
步骤 4：避免再次踩坑
在配置里加过期预警：在距离
validUntil还有 7 天、3 天、1 天的时候触发通知（邮件或 Telegram bot）。别等到过期了才发现。如果支持，把过期拉满：Hyperliquid 最多 180 天，设置的时候直接拉满，减少续签频率。
把代理的支付权限和会话生命周期解耦：会话可以过期，但钱包里的余额和限额策略独立存在。设计代理时，让它在检测到会话过期后能自动触发重建，而不是卡死在原地等人工干预。
核验收尾
做一次手动测试：
把 session 的
validUntil设到 5 分钟后让代理正常跑任务
等 5 分钟后观察日志——应该看到明确的过期错误（如
invalid session或expired），代理自动触发了重新授权流程还是卡住了
核验渠道：
日志里能看到过期错误码（如 Dynamic 的 401，或 ERC-4337 钱包的
SessionKeyExpired报错）代理的审计记录里有一条重新授权的操作记录
重新授权后，代理能继续执行后续任务，没有资金损失
如果你发现代理没有自动处理过期，回代码里加一个异常捕获分支：遇到 expired 相关错误时，触发 rotateSessionKey() 或重新登录流程，而不是静默失败。
