企业级 AI 架构 · 06 模型不可知与路由｜把正确的模型，连到正确的工具

企业级 AI 架构 · 06 模型不可知与路由｜把正确的模型，连到正确的工具

系列第 06 篇。上一篇的基准已经证明"没有全能王模型"，那多模型到底怎么选、怎么切、怎么组织工具？照旧三方对照。

呼应 00 总览的中央论点：路由与模型不可知，是控制平面对"用哪个执行器"的确定性调度——模型不该自己挑模型，调度权在模型之外。

---

一、WorkBuddy 的权威主张：模型不可知 + 按意图组织工具

WorkBuddy 的一条明线是模型不可知，混元、DeepSeek、GLM、Kimi、MiniMax、Claude 等几十个模型都能路由（此处仅举例，非穷举），不让产品绑死在单一模型上。这背后有个朴素的理由：不同任务该用不同模型，模型会涨价、会掉线、会迭代，产品得有腾挪空间。

但"多模型"不是把几个名字塞进下拉框那么简单。真正的路由至少要看四件事：

• 任务类型：研究、编码、图像、数据还是文档；
• 能力约束：上下文长度、工具调用、结构化输出、多模态；
• 经济性：每一步的 Token 成本与延迟；
• 历史表现：某个模型在某类工具链上的成功率。

而"把正确的模型连到正确的工具"，靠的是 MCP（模型上下文协议）。MCP Server 向 Agent 提供三种原语：

原语	是什么	谁驱动
Resources	只读内容（文档、数据）	Agent 主动拉取
Tools	可执行的动作	模型驱动
Prompts	提示模板	用户驱动

MCP 有一条设计原则特别实用：按用户意图组织工具，不照搬底层 API。比如"创建 Issue"在底层可能是"创建 + 加描述 + 打标签 + 加附件"四个接口，但对 Agent 应该只暴露一个 create_issue 工具。一个可用的工具，至少要说明三件事：什么时候调用、参数怎么填、结果怎么接着处理。

再往上，是 2026 年 8 月 WorkBuddy 披露的真实路由架构，"路由 + Skill 市场"：意图分类 → Skill 调度 → Skill 内部子路由 → 执行。每个 Skill 是自包含的 mini-Agent，路由只负责"把请求送到对的 Skill"。这等于说：模型不可知解决"换什么脑子"，路由解决"谁来接这个活"。

第三方实证支持「按意图组织工具」：检索式预筛选使 Opus 4 工具使用基准准确率 49% → 74%；MCP-Zero 在约 2800 个工具上比全量注入省约 98% token；Cursor 只暴露索引使 MCP 相关任务总 token 减少 46.9%。书的反面警示同样关键：工具数量超过一百个时，即使先进模型也容易在工具选择上出错——这正是「按需暴露、按意图组织」的工程理由，也是本篇主张的实证支撑。

图：请求经路由层按成本 / 能力 / 合规选 provider，换模型 = 换插件。

（WorkBuddy 闭源，以上是公开方法论，只当"标准答案"。）

---

二、Pi 怎么做：用一层 pi-ai 抹平模型差异

Pi 的"模型不可知"，落在一个统一的抽象层 pi-ai 上。（一手来源：github.com/earendil-works/pi，见 README.md / AGENTS.md）

pi-ai 抹平了 OpenAI、Anthropic、Google、Azure、Bedrock、Mistral、Groq、xAI、OpenRouter、Ollama 等十余家的接口差异——换模型，不用换整套工具，只改配置：

// 示意：切换 provider（字段以 Pi 官方为准）
{
  "provider": "anthropic",      // 换成 openai / google / deepseek / ollama ...
  "model": "claude-sonnet-4"
}

示意片段，基于 Pi 官方文档；字段以官方为准，完整配置见付费交付包。

这带来一个对团队很实在的好处：把"Agent 工作流"和"模型供应商"拆开。供应商涨价、限流、掉线时，换一个 provider 就行，工作流不用动。这正是 WorkBuddy"模型不可知"主张在开源侧的一个干净落地。

至于"路由"，Pi 走的是极简派的老路：不内置复杂的路由策略，把"选哪个模型"留给用户和扩展去定义。它保证的是"能接十几家"，而不是"替你决定该接哪家"。

---

三、DeepSeek Harness 怎么做：模型也只是一个插件

DSH 把"模型不可知"贯彻得最彻底，模型适配器本身就是一个插件。（一手来源：github.com/deepseek-ai/deepseek-harness，模型适配器即插件，见 README.md / docs/architecture.md）

虽然名字带 "DeepSeek"，但 DSH 是模型无关的：它走 OpenAI 兼容接口，原则上可以接别家的模型，而不是锁死在 DeepSeek 自己的阵容上。换模型 = 换一个模型适配器插件，和换 session、换存储、换沙箱是同一套动作。

这背后是它"一切皆插件"哲学的必然结果：既然连 UI 都能换，模型当然也只是配置树上的一个可替换节点。模型适配器不是随便挂的——它注册在 ctx.llm 这个"接缝（seam）"上，换模型就是换一层 seam 实现（官方 ADR-0010 即讨论 twin LLM adapters）。

标注：DSH 目前是 developer preview（写作时 v0.1.7-alpha.2，非 GA），插件接口仍在快速迭代、会有破坏性变更，本系列只做架构对照，不承诺逐行跟跑。

"模型不可知"要真做得到，有个前提：运行时得先知道有哪些模型、各自能吃多少上下文、最多吐多少 token。v0.1.3-alpha.1 把这块补了一截——模型探测支持自定义提供商的 models 对象与 Anthropic 原生模型列表，并回填模型名称、上下文窗口与最大输出 token。别把它当成"又多支持了一家厂商"：这类元信息正是路由决策的输入——上下文窗口决定能塞多少历史，最大输出决定一次能吐多长；没有它们，"按任务挑模型"就只能靠人肉维护一张表。把模型元信息做成可探测、可回填，是路由从"能换"走向"会选"的一步。

而 v0.1.5-rc.1 补的那一条，恰好点出了"模型不可知"的边界。 它给 DeepSeek 模型适配器新增了 DeepSeek-V41-Flash（即本系列据以校时的 DeepSeek V4.1 Flash，适配器名 deepseek-flash），支持文本、图片与会话历史中的系统提示词更新，并且——新会话默认使用该模型（配置文件显式指定模型时以配置值为准）。

而 0.1.6 这两版，把这条边界又往前推了一格。 一是默认模型清单变了：v0.1.6-alpha.2 移除了 V4 Flash 与 V4 Flash Vision Exp。这里要说清楚——被撤的不是 V4.1 Flash：commit 记录显示 09-09 加入 V41 Flash 时明确写着"保留 V4 模型"，09-16 才把老款清出默认列表，所以新会话默认仍是 DeepSeek-V41-Flash。真正的信息是："默认模型列表"本身是一份会被增删的清单，你若照着它写过白名单或路由表，就得重对一遍。

二是更硬的一条，也是本合集观察至今唯一一条不改就报错的默认值变更：v0.1.6-alpha.1 起 DeepSeek 适配器默认改用 Messages 协议，并支持通过 Files API 复用已上传图片；自定义 API 地址保留不变，但如果你手动配过旧的官方根地址，必须移除或改为 https://api.deepseek.com/anthropic。前几次默认值变更顶多是"行为悄悄变了"，这一次是"配置不跟着改，请求直接失败"——默认值第一次从"细则"变成了"门槛"。

到 v0.1.7-alpha.1，这道门槛又换了一种长相。 发布说明原话是：

官方 DeepSeek 适配器仅使用 Messages API，移除 Chat Completions 和 protocol 选项；旧配置需删除 protocol 并使用 Messages 兼容地址。

对照一下：0.1.6 是"默认换了，另一条路还在"——你仍可显式写 protocol: chat_completions 把它改回去（当然还得配旧根地址）；0.1.7 是把另一条路整个删掉，protocol 这个选项不存在了。门槛从"默认选了一条路"变成"只剩一条路"。 到 v0.1.7-alpha.2 又出现第三种长相：spill-policy 里的 maxInlineBytes 要改名成 maxInlineTokens——那条不在路由这一层，但性质一样：配置里一个键改了名，你没跟着改，它就静默失效（不报错）。 所以这一篇的"默认值治理"，diff 的清单要多两类东西：被删掉的选项、被改名的键。

一条默认值，把两件事同时说清了：

第一，它没有违背"模型不可知"。 模型适配器仍然是插件，仍然挂在 ctx.llm 这个接缝上，你照样可以按自己的合规与成本要求把它换成别家的适配器。接口层的解耦是完整的。

第二，"可换"和"已换"是两回事。 对没有显式写配置的人来说，这次升级已经把他们迁到新模型上了——换脑子这件事发生了，只是没有人拍板。这就是"模型不可知"这类主张的边界：它保证的是你有得选，不保证默认值中立。DSH 是 DeepSeek 自己的产品，默认给自家最新模型是合理选择；但对把 agent 接进企业的人来说，这意味着升级动作本身就带着一次模型迁移，而它不会单独提醒你。

所以路由这一层真正要落到治理上，只有一句话：默认值是"没有写进配置的配置"，必须被当成配置来管。 你显式钉住的模型写在哪里、谁改得动、升级时怎么 diff 出默认值的变化——这三件事不做，"模型不可知"就只是一句口号，因为最不设防的那条路径（什么都不配）永远是最多人走的那条。

---

四、三方对照：模型与路由，三种"解耦"程度

维度	WorkBuddy（方法论之尺）	Pi（极简派，可跟跑）	DeepSeek Harness（极繁派，dev preview）
模型不可知	混元/DeepSeek/GLM/Kimi/MiniMax/Claude 等路由（仅举例）	pi-ai 统一十余家 provider	模型适配器插件（OpenAI 兼容）
默认模型	产品侧选定，用户可切	用户显式配置，无强默认	随版本更新而变（v0.1.5-rc.1 起新会话默认 DeepSeek-V41-Flash；v0.1.6-alpha.2 又把 V4 Flash 系列移出默认列表）
默认协议	产品内部约定	OpenAI 兼容	v0.1.6-alpha.1 起 DeepSeek 适配器默认改 Messages 协议，旧官方根地址须改；v0.1.7-alpha.1 起移除 Chat Completions 与 protocol 选项（只剩 Messages 一条路）
路由	路由 + Skill 市场（意图→Skill→子路由）	不内置，用户自定	插件组合（不强制路由）
工具组织	MCP 三原语 + 按意图组织工具	按需注册工具（extension）	工具即插件，按模式挂载
换模型成本	产品侧路由，用户无感	改一行配置	换一个插件；但不配置的人会被默认值带着走

速记一句话：模型不可知的本质是"把大脑和身体解耦"，WorkBuddy 用路由 + Skill 市场做调度，Pi 用 pi-ai 抹平接口、路由留给用户，DSH 把模型本身变成插件。三者一致的方向是：别让产品（和你的工作流）被某个模型绑架。但要补一句——解耦的是接口，不是默认值；默认模型会随上游版本变，治理时得把它当配置管，而不是当常量信。

---

相关阅读（系列互链）

本篇是【企业级 AI 架构】技术深轨，与公众号《AI思想的东方注脚》哲学引子、本体智能 / FDE 系列同源联动——同一观点不重复讲，按兴趣深潜：

• 《阴阳平衡：推理优化》（AI思想的东方注脚·E13）——路由的本质是平衡：效果、成本、速度三者的"阴阳"
• 《精气神：算力模型数据》（AI思想的东方注脚·E14）——被路由的三个要素，这篇逐个拆开讲

下一篇：07 · 多 Agent 与组织协作——单个 Agent 会了，一支 Agent 队伍怎么带。

---

模型路由 #模型不可知 #成本控制 #企业级AI

关注公众号「农夫三拳有点癫」，第一时间读到本系列更新。