夜雨聆风如果一个 AI 编程工具突然改登录、改额度、改入口，你的工作流会不会直接卡住？
我现在的答案是：不能。
Gemini CLI 要迁到 Antigravity CLI，Qwen Code 的 OAuth free tier 已经停用，DeepSeek-V4 又把 1M context 推到官方服务里。工具越来越强，但入口也越来越不稳定。
所以我现在更倾向于把 AI 编程工具链分成四层。
主力 Agent 只处理重任务。
比如：
读陌生仓库。 定位 bug。 跨文件修改。 补测试。 跑命令并根据报错继续修。
这一层可以放 Codex、Claude Code、Antigravity 这类工具。
它们适合做工程闭环，但不适合拿来回答所有小问题。解释一个函数、写一段小脚本、整理一段日志，都没必要上最贵、最重的入口。
主力 Agent 要省着用。
备用 CLI 不需要平替主力。
它只需要在主力入口卡住时，帮我继续处理轻任务。
比如 Qwen Code、OpenCode，或者任何支持自定义 base_url、api_key、model 的 CLI。
典型配置长这样：
1export OPENAI_API_KEY="sk-..."2export OPENAI_BASE_URL="https://example.com/v1"3export AI_MODEL="deepseek-v4-flash"关键点不是某个模型名字，而是这套结构：
工具归工具，模型归模型，入口归入口。
只要这三件事能拆开，后面迁移就不会太痛。
长上下文模型不要神化。
DeepSeek-V4 官方文档写到，V4-Pro 是 1.6T total / 49B active params，V4-Flash 是 284B total / 13B active params，官方服务默认支持 1M context。
这很适合读材料：
长文档。 大日志。 技术报告。 多个 Issue。 大段历史对话。
但我不会一上来就让长上下文模型直接改代码。
更稳的流程是：
1长上下文模型读材料 -> 输出摘要 -> 主力 Agent 改代码 -> 本地测试一个负责读，一个负责改，出问题也好定位。
省钱不是白嫖。
真正省钱，是不要把所有任务都交给最贵模型。
我的规则是：
小问题：便宜模型。 长材料：长上下文模型。 真改代码：主力 Agent。 高频任务：脚本和 Hooks。
如果需要统一管理入口，可以加 OpenRouter、LiteLLM、CLIProxyAPI、Sub2API 这类代理层。
它们的意义不是神秘，而是帮你把模型路由和成本控制从具体工具里拆出来。
今天不用折腾太复杂。
先建一个 ai-env.example：
1export OPENAI_API_KEY=""2export OPENAI_BASE_URL=""3export ANTHROPIC_API_KEY=""4export DEEPSEEK_API_KEY=""5export HTTPS_PROXY="http://127.0.0.1:7890"6export HTTP_PROXY="http://127.0.0.1:7890"以后所有 AI CLI 尽量读这一套配置。
不要把 Key、代理、模型名散落在每个项目里。那样某个入口一变，你就要到处找配置。
我的最终原则就一句话：
主力 Agent 负责闭环，备用 CLI 负责不断工，长上下文负责读材料，代理层负责省钱和切换入口。
AI 编程工具肯定还会继续变，但配置和分工最好留在自己手里。
素材来源：
Google Developers Blog: https://developers.googleblog.com/en/an-important-update-transitioning-gemini-cli-to-antigravity-cli/ Qwen Code GitHub Issue: https://github.com/QwenLM/qwen-code/issues/3316 DeepSeek API Docs: https://api-docs.deepseek.com/news/news260424