工具失效时，先判断是哪一层
同一个“请求失败”，可能来自产品入口退役、用量配额、账单、区域策略、账号安全、客户端漏洞或第三方代理。若不先确认 HTTP 状态、官方公告、认证方式和账号类型，社区经验很容易把一次限流放大成“封号”，也可能把真实的凭据泄露误当成普通故障。
把迁移能力设计在平时
项目指令、Skills、MCP 配置与模型选择应尽量分离；密钥放在独立的安全存储，不写进仓库或代理配置；关键工作流保留第二客户端或直接 API 路径。每季度导出配置并在非关键仓库恢复一次，才能知道所谓“可迁移”是否真实。
账号安全的最低基线
- 工作账号只使用组织批准的客户端、网关和扩展。
- 第三方代理不得接触主账号 Cookie、长期令牌或未脱敏代码。
- 遇到异常先撤销令牌、检查登录记录和组织审计日志，再讨论绕过办法。
- 客户端能读写工作区时，把提示注入、扩展供应链和本地命令执行一并纳入威胁模型。
推荐阅读顺序
先读 Gemini CLI 页面，把官方迁移与“反代封号”分开；再读账号锁定和 token 开销，评估供应商切换成本；最后看客户端漏洞与提示注入案例，理解“能调用更多工具”为什么同时扩大攻击面。迁移的目标不是追逐下一款热门 CLI，而是让模型、客户端和账号中的任一层变化时，项目仍可继续。