Coding Agent Auto Model Router：Efficiency + Balance + Intelligence 自动选模完整项目

摘要： 本文是一个完整的开源式项目教程：用约 250 行 Python 搭一个 Coding Agent 自动选模代理（Auto Model Router），仿照 GitHub Copilot 与 Cursor 的做法提供 Efficiency、Balance、Intelligence 三种模式，让 Codex、自建 Agent 等客户端只写 model = "auto-balance"，由路由器按每次请求的难度、失败信号、成本和缓存情况自动选择 GPT‑6 Luna、Sol 或 Astra。核心结论是：三种模式不应该是三个固定模型，而是同一模型池上的三种“成功率门槛”；再加上会话粘性和失败升级，路由器才能既省钱又不掉质量。本文适合团队规模化使用 Coding Agent、账单增长过快的开发者与平台团队。建议先在个人或测试仓库以 Balance 模式试跑一到两周，再推广。读完后你将拿到完整配置、核心代码、Docker 部署方式、Codex 接入方法和成本评估思路。

配套项目源码：下载 Auto Model Router 完整项目（ZIP）。解压后阅读 README.md，并在本地填写环境变量。

核心结论

Coding Agent 的自动选模可以自己做，而且应该按“同一个模型池 + 三种优化目标”来设计：Efficiency 追求够用即可，Balance 兼顾质量与成本，Intelligence 追求高成功率；但无论哪种模式，简单任务都应落到便宜模型上，只有难任务和反复失败的任务才升级到贵模型。

• 设计参照官方做法：GitHub 在 2026 年 9 月 14 日为 Copilot 自动选模加入 Efficiency、Balance、Intelligence 三档，官方明确三档使用同一组可用模型，Auto 仍逐条评估提示词；Cursor Router 也采用 Intelligence、Balance、Cost 三种模式。
• 本项目的核心算法：每个模式对应一个“预估成功率门槛”，在达标候选中选择最便宜的；无人达标则选成功率最高的。
• 两个必须有的机制：会话粘性（上一轮模型仍达标就不换，保护提示词缓存）与失败升级（连续失败抬高最低档位，连续成功再逐步放回）。
• 成本判断：按官方价格，GPT‑6 Luna 与 Sol 的单价相差 20 倍，路由的收益主要来自把大量简单请求从贵模型上移走；具体节省比例必须用你自己的流量回放测出来。
• 实施建议：先以 Balance 作为默认模式，Efficiency 用于批量低风险任务，Intelligence 留给疑难调试与架构工作，并设置每日预算自动降档。

背景与主要变化

先说结论：2026 年下半年，主流 AI 编程工具已经把“自动选模”做成了标配功能，但它们只在各自产品里可用；如果你用的是 Codex CLI、自建 Agent 或 n8n 工作流，就需要一个自己的路由层。

变化来自两个方向。第一，计费方式变了。byteiota 等第三方分析指出，Copilot 在 2026 年 6 月转向按 Token 计价的 AI Credits 后，不同模型之间的价格差距直接反映到账单上，选模从“无所谓”变成了成本核心。第二，模型档位拉开了。OpenAI 在 9 月推出 GPT‑6 系列：官方公告中 Sol 为每百万 Token 输入 $2、输出 $10，Luna 为 $0.10 / $0.50；旗舰 Astra 的价格多家第三方一致报道为 $10 / $50（本文未直接核验官方定价页，请以 OpenAI 官方为准）。从最便宜到最贵，单价相差百倍。

两家产品的公开做法值得借鉴：

需要注意的边界：GitHub 官方没有公开 Auto 如何衡量任务复杂度，Cursor 的节省数据来自其自家在线 A/B 测试，本文项目的规则与参数也属于编辑设计，都需要在你自己的仓库和任务上验证。关于 Copilot 三档的使用细节，可以参考站内的 Copilot 自动选模相关教程。

核心功能拆解

结论先行：这个路由器由四个部件组成——特征提取、难度评分、按模式选模、会话状态机，外加一个对客户端透明的 Responses API 代理。

候选池：模型 × 推理强度

候选池里的每一项不是单纯的模型，而是“模型 + 推理强度”的组合，因为同一个模型在不同推理强度下的成本和能力差别很大。每个候选有三个参数：单价、能力分 cap（0～1）和相对延迟。

candidates:
  - {id: luna-none,  model: gpt-6-luna,  effort: none,   in: 0.10, out: 0.50,  cap: 0.35, latency: 0.10}
  - {id: luna-high,  model: gpt-6-luna,  effort: high,   in: 0.10, out: 0.50,  cap: 0.55, latency: 0.35}
  - {id: sol-medium, model: gpt-6-sol,   effort: medium, in: 2.00, out: 10.00, cap: 0.72, latency: 0.45}
  - {id: sol-high,   model: gpt-6-sol,   effort: high,   in: 2.00, out: 10.00, cap: 0.82, latency: 0.65}
  - {id: astra-low,  model: gpt-6-astra, effort: low,    in: 10.0, out: 50.00, cap: 0.88, latency: 0.60}
  - {id: astra-high, model: gpt-6-astra, effort: high,   in: 10.0, out: 50.00, cap: 0.95, latency: 0.90}

modes:
  efficiency:   {target_p: 0.60, w_latency: 0.30}
  balance:      {target_p: 0.80, w_latency: 0.15}
  intelligence: {target_p: 0.93, w_latency: 0.05}

cap 是本文给出的初始估计，不是官方数据，必须用历史任务回放校准。Astra 不支持 none 推理强度（官方迁移指南说明最低用 low），所以候选池里没有 astra-none。

特征提取与难度评分

路由器只读请求体，不额外调用模型：最后一条用户消息里是否有“重构、并发、安全、迁移”等高难关键词，是否是“注释、重命名、格式化”这类简单任务，上下文长度，工具数量，以及最近几次工具输出里是否出现 Traceback、FAILED 等失败信号。每出现一次失败，难度分加 0.12——这是整个设计里最有价值的信号，因为 Agent 卡住时最需要换更强的模型。

三模式选模：达标候选里选最便宜

核心算法只有几行：先用 logistic 函数把“能力分 − 难度分”换算成预估成功率，再用当前模式的门槛 target_p 过滤，在达标候选中按“成本 ×（1 + 延迟权重 × 延迟）”选最小值。

def choose(cfg, mode, f, diff, st, over_budget=False):
    if mode == "intelligence" and over_budget:
        mode = "balance"                                   # 预算保护
    w, pol = cfg["modes"][mode], cfg["policy"]
    pool = [c for i, c in enumerate(cfg["candidates"])
            if c["model"] in pol["allow_models"] and i >= st.floor]
    rows = {c["id"]: {"p": success_prob(c["cap"], diff),
                      "rank": expected_cost(c, f) * (1 + w["w_latency"] * c["latency"])}
            for c in pool}
    ok = [cid for cid, r in rows.items() if r["p"] >= w["target_p"]]
    if not ok:
        return max(rows, key=lambda cid: rows[cid]["p"])  # 无人达标：选最强
    best = min(ok, key=lambda cid: rows[cid]["rank"])
    # 会话粘性：上一轮模型仍达标且贵得不多，就不切换，保护提示词缓存
    if st.last_id in ok and rows[st.last_id]["rank"] <= rows[best]["rank"] * (1 + pol["stickiness"]):
        best = st.last_id
    return best

这样设计的好处是可解释：每条路由日志都能说清“为什么选它”。它也天然实现了 GitHub 官方描述的行为——即使在 Intelligence 模式下，给函数加 docstring 这种任务也可能交给小模型。

会话状态机：失败升级，成功降档

每个会话记录上一轮模型、连续失败次数、连续成功次数和一个“最低档位” floor。连续失败 2 次，floor 抬到上一轮模型的下一档；连续成功 3 次，再下降一档。这个“先升后降”的思路与第三方工具 Entelligence 公开描述的做法类似：检测到 Agent 卡住就升级，恢复进展后回落。

适用人群与使用场景

结论：日调用量越大、任务难度越分散，自建路由器越划算；小团队或调用量很低时，直接用单一模型或产品内置的 Auto 更省事。

Augment Code 的路由指南提到，动态路由会给每次请求增加一次分类步骤，对每天少于 500 次 Agent 调用的团队，维护路由分类器的工程开销可能超过节省的费用。本项目用纯规则做分类，不额外调用模型，开销很小，但维护和校准仍然需要人力。

适合的场景包括：团队共用一个 API 账号跑 Codex CLI 或自建 Agent，需要统一控制成本；CI 中批量运行代码审查、测试修复、文档生成等任务，量大且难度差异明显；企业希望把“哪些模型可用、每天预算多少”写进配置、纳入审计。

不适合的场景：你只用 Cursor 或 Copilot 且已开启其内置 Auto（它们有更多真实数据，而且模型可能不走你的 API）；或者任务几乎全是疑难问题，此时固定使用强模型更简单。

安装、配置或使用步骤

结论：按以下 7 步，大约 20 分钟可以在本机或 VPS 上跑起路由器，并让 Codex 通过它自动选模。

1. 下载项目并准备环境变量：解压项目包，复制 .env.example 为 .env，填入 OPENAI_API_KEY=YOUR_API_KEY 和客户端访问路由器用的 ROUTER_TOKEN=YOUR_TOKEN。不要把 .env 提交到仓库。
2. 离线预演：运行 python3 simulate.py，它不调用任何 API，只打印三种模式对示例任务的选模结果，用来检查配置是否符合预期。
3. 核对价格与候选池：打开 config.yaml，按 OpenAI 官方定价页核对单价；在 allow_models 中只保留你的账号可用的模型。
4. 启动服务：执行 docker compose up -d --build。Compose 文件默认只监听 127.0.0.1:8787，如需给团队使用，请放在内网并前置 HTTPS 反向代理。
5. 健康检查：curl http://127.0.0.1:8787/healthz，返回今日估算花费和会话数。
6. 接入 Codex：在 ~/.codex/config.toml 中新增一个自定义模型提供方（配置见下），把模型名设为 auto-balance。
7. 观察日志并校准：logs/routing.jsonl 会记录每次请求的特征、候选分数和选择理由；运行一周后按下文方法校准 cap。

Codex 接入配置（字段名参考 Codex 自定义提供方的公开配置方式，不同版本可能有差异，请以 Codex 配置参考为准）：

# ~/.codex/config.toml
model_provider = "autorouter"
model = "auto-balance"

[model_providers.autorouter]
name = "Auto Model Router"
base_url = "http://127.0.0.1:8787/v1"
env_key = "ROUTER_TOKEN"      # Codex 会把该环境变量作为 Bearer 令牌发送
wire_api = "responses"

[profiles.cheap]
model = "auto-efficiency"

[profiles.deep]
model = "auto-intelligence"

之后可用 codex --profile deep 临时切到 Intelligence 模式。需要注意：auto-balance 这类自定义模型名在 Codex 的模型目录中没有元数据，客户端可能使用默认的上下文和能力设定，第三方 Bifrost 文档也提到自定义模型名需要额外目录配置才会出现在选择器中。

代理的关键逻辑是改写请求体：把 model 换成选中的真实模型，写入 reasoning.effort，并按 GPT‑6 迁移指南在推理强度不为 none 时移除 temperature、top_p 等参数。显式写了真实模型名的请求会原样透传，方便临时绕过路由器。

c = decision.candidate
body["model"] = c["model"]
body.setdefault("reasoning", {})["effort"] = c["effort"]
if c["effort"] != "none":
    for k in ("temperature", "top_p", "top_logprobs"):
        body.pop(k, None)

实际工作流示例

结论：用同一批任务对三种模式做离线回放，能在花一分钱 API 费用之前就看清路由行为；上线后再用真实日志校准。

离线回放结果

以下是项目自带 simulate.py 的实际运行输出（基于本文假设的 cap 值，非实测质量）：

可以看到两个设计意图都得到了体现：Intelligence 模式下的简单任务依然走 Luna；而疑难且已经失败的任务，即使在 Efficiency 模式也会选到 Astra，因为只有它能达到 60% 的成功率门槛——省钱模式不等于把任务交给一个大概率会失败的模型。

成本模拟（示例计算，非官方数据）

假设一天 100 次请求：60 次简单、30 次中等、10 次疑难，每次约 3 万输入 Token（80% 命中缓存）、4000 输出 Token。按项目内置的成本估算函数：

• 全部固定用 Sol medium：约 $5.68 / 天
• 全部固定用 Astra high：约 $44.4 / 天
• Efficiency 模式：约 $2.26 / 天
• Balance 模式：约 $4.66 / 天
• Intelligence 模式：约 $6.41 / 天

Balance 比“全用 Sol”便宜约 18%，同时把 10 个疑难任务交给了更强的 Astra。真实节省幅度取决于你的任务分布、推理 Token 用量和缓存命中率，务必以控制台账单为准。

一次请求的完整生命周期

在 Codex 中执行一次“修复支付回调竞态”任务时：第一轮请求落到 Sol medium；Agent 运行测试失败，失败输出作为工具结果进入下一轮请求，难度分上升；连续两次失败后，会话 floor 被抬高，路由器切到 Sol high 甚至 Astra；测试通过、连续成功三轮后，floor 逐步回落。整个过程客户端无感知，所有决策都写进日志。

对比与选型建议

结论：已经在用 Copilot 或 Cursor 的团队，优先用它们的内置 Auto；需要跨工具、自控模型和预算，或者走 API 计费的团队，再考虑自建路由器或开源方案。

• 产品内置 Auto（Copilot、Cursor）：零维护，有海量真实数据支撑。Cursor 官方称其路由器基于 60 多万条真实请求训练；缺点是只在各自产品中可用，决策规则不透明，GitHub 官方也未公开复杂度如何衡量。
• 托管路由服务（如 OpenRouter 的自动路由）：一个 API Key 接入多家模型，免运维；第三方资料显示 OpenRouter 原先基于 Not Diamond 的 openrouter/auto 已标记为弃用，正过渡到自有的 beta 版本，接入前需确认当前状态。
• 开源路由框架（如 RouteLLM）：以强弱两模型加阈值为核心，适合做研究和二次开发。
• 本文自建方案：规则透明、完全自控、能读取 Agent 的失败信号并按会话升降档；代价是需要自己校准参数、维护代理。

选择模式时，可以参考 GitHub 官方的描述：Efficiency 适合快速、直接的任务；Balance 综合考虑成本、质量与延迟，适合日常工作；Intelligence 优先质量，面向复杂任务。更多模型选型内容可在站内 模型选型专题 和 Agent 实战教程 中查找。

风险、限制与注意事项

结论：自建路由器的主要风险在工程层面——密钥暴露、跨模型切换导致上下文异常、规则误判和成本失控，每一项都需要显式防护。

API Key 与访问控制。 路由器持有上游 API Key，等于一个“花钱入口”。项目默认只监听本机，并要求客户端携带 ROUTER_TOKEN；对团队开放时，应放在内网、启用 HTTPS，并为每个成员签发独立令牌，便于审计和吊销。

跨模型切换的状态兼容。 Agent 会话中途切换模型时，上一模型产生的推理状态能否被另一个模型正确使用，官方目前未明确说明。本项目用会话粘性降低切换频率，建议你在使用 previous_response_id 的客户端上重点实测切换后的表现；遇到异常时，可以把 stickiness 调大，或限制只在失败升级时才换模型。

缓存失效成本。 Cursor 官方特别强调其路由器在训练和评估中都计入了切换模型导致的缓存未命中成本。频繁切换会让“看起来更便宜”的路由实际更贵，这也是粘性参数存在的原因。

规则误判与数据漂移。 关键词规则会误判，例如“解释一下这个鉴权 Bug”会同时命中简单和高难两类关键词。所以不要把路由器当成一次配置、永久有效：每周抽查日志中“选便宜模型但随后失败”的会话，调整关键词和 cap。

成本与循环控制。 项目提供每日预算上限，超出后 Intelligence 自动降为 Balance；但它不会阻止 Agent 自身的无限循环。客户端侧仍需设置最大轮次、超时和人工确认。升级到最高档后仍连续失败的会话，应转人工处理，而不是无限重试。

生产操作必须人工审批。 路由器只决定用哪个模型，不决定 Agent 能做什么。涉及推送主分支、发布版本、执行生产数据库操作、修改权限或密钥的动作，应在 Agent 客户端的沙箱与审批策略中强制人工确认。

已知限制。 当前版本仅支持 /v1/responses 接口；会话状态保存在内存中，重启即丢失，多实例部署需要改用 Redis；流式请求的记账依赖上游 response.completed 事件中的 usage 字段。

事实依据与来源

官方已确认的事实： Copilot 自动选模于 2026 年 9 月 14 日新增 Efficiency、Balance、Intelligence 三档，三档使用同一组模型，Auto 逐条评估提示词，按实际选中的模型计费——来自 GitHub 官方 Changelog。Cursor Router 的三种模式、分类器原理、缓存意识、管理员控制和早期客户节省 30%～50%——来自 Cursor 官方博客（其中节省数据为 Cursor 自有测试）。GPT‑6 Sol 与 Luna 的价格来自 OpenAI 官方公告；Astra 不支持 none 推理强度、推理非 none 时需移除采样参数，来自 OpenAI GPT‑6 迁移指南。

第三方资料： GPT‑6 Astra 的 $10 / $50 价格来自 OpenRouter、MindStudio 等多家第三方一致报道；Copilot 计费方式变化来自 byteiota；动态路由的开销判断来自 Augment Code；OpenRouter 自动路由状态、Entelligence 升降级做法均来自第三方公开资料。

编辑设计与实施建议： 候选池的 cap 与延迟参数、难度评分规则、“达标候选选最便宜”的算法、会话粘性与升降档机制、成本模拟数字，均为本文项目的设计与示例计算，不代表任何官方结论。本文代码已在模拟上游环境中完成请求改写、流式透传、鉴权与记账测试，但未在真实 OpenAI API 与 Codex 上进行长期质量评估，需要在你的项目中验证。

内容核验日期： 2026 年 9 月 25 日。

FAQ

Efficiency、Balance、Intelligence 是三个不同的模型吗？

不是。在 GitHub Copilot 中，官方明确三档使用同一组可用模型，区别只在于 Auto 权衡成本、质量和延迟的方式；本文项目也照此设计，三种模式共用一个候选池，只是成功率门槛不同。因此 Intelligence 模式遇到简单任务时同样会选便宜模型，Efficiency 遇到疑难任务也可能选贵模型。

自建路由器比直接固定用一个模型能省多少钱？

没有统一数字，取决于你的任务分布。本文示例假设 60% 简单、30% 中等、10% 疑难任务时，Balance 模式比全部使用 Sol medium 便宜约 18%，同时疑难任务得到了更强的模型；Cursor 官方公布的早期客户数据为比全部使用 Opus 4.8 节省 30%～50%。你应该用自己一到两周的真实日志回放来估算。

路由器支持 Claude、Gemini 或国产模型吗？

当前版本只转发 OpenAI Responses API 格式的请求，所以原生支持 OpenAI 模型，以及任何提供 Responses 兼容接口的服务。要接入其他厂商，可以在上游放一个 LiteLLM 这类兼容网关，再把其模型加入 candidates；但跨厂商切换会让缓存完全失效，粘性参数应调得更高。

如何校准 cap 能力分？

从日志中挑出 20～50 个有明确结果（测试通过或失败）的历史任务，分别用各候选重跑，统计每个候选在不同难度区间的通过率，再调整 cap 使 success_prob 的预测与实际通过率接近。之后每次模型更新都应重做一次，因为新模型的能力曲线会变化。

路由器会不会增加延迟？

几乎不会增加模型推理之外的明显延迟。本项目的特征提取和选模都是本地规则计算，不额外调用模型，开销通常在毫秒级。Augment Code 指出，基于模型的分类器每次路由可能增加 50～200 毫秒，这也是本项目默认不用模型做分诊的原因；如需更高精度，可以把 difficulty() 替换为 Luna 分类调用，并接受这部分延迟。

Codex 连接路由器后报模型不存在或上下文长度异常怎么办？

先确认 model_provider 指向了自定义提供方，且 env_key 对应的环境变量已设置为路由器令牌。auto-balance 这类名称不在 Codex 的内置模型目录中，客户端可能采用默认的上下文设定；如出现上下文不足，可在 Codex 中为该名称补充模型目录元数据，或者直接在命令行用 -m gpt-6-sol 绕过路由器，确认是路由问题还是客户端问题。

多人团队部署需要改什么？

至少改三处：把内存中的会话状态和每日花费改为 Redis 存储，以支持多实例；为每位成员签发独立令牌，并在日志中记录令牌对应的成员；把 config.yaml 纳入 Git 管理，变更走代码审查。企业还应把路由日志接入现有的审计系统，并限制可访问上游 API Key 的人员。

模型更新后需要改代码吗？

通常只需改配置。新模型上线后，在 candidates 中新增一行、填写官方价格和初始 cap，用 simulate.py 预演，再用历史任务回放校准即可；旧模型下线时从 allow_models 中移除。只有当新模型的 API 参数发生变化（例如推理强度取值不同）时，才需要改动请求改写逻辑。

参考来源

• GitHub Changelog：Configure cost and quality in Copilot auto model selection
• GitHub Changelog：Copilot CLI 支持自动选模
• Cursor 官方博客：Introducing Cursor Router
• OpenAI：Introducing GPT‑6 Sol and Luna
• OpenAI API：GPT‑6 模型迁移指南
• OpenRouter：GPT‑6 Astra 价格与参数
• byteiota：Copilot Auto 三档与 AI Credits 计费分析
• Augment Code：Coding Agent 模型路由指南
• Entelligence：2026 年 LLM 路由工具对比

内容核验日期：2026 年 09 月 25 日