企业官网建设流程全解析

1. 为什么要把十几个免费模型通道塞进一个入口

我最初用 WorkBuddy 的时候，配置里只挂了一个模型通道。用着挺顺，但问题很快就来了：写代码的时候希望用擅长代码的模型，写文案的时候希望用擅长中文表达的模型，做结构化抽取的时候又希望用响应快、成本低的模型。每次切换都要手动改配置、重启会话，一天下来光折腾配置就浪费不少时间。

后来我把能找到的免费通道都接进来，一口气配了 14 个。结果更乱了——通道多了，选择困难反而更严重。每次发起任务都要想“这次该用哪个”，比只有一个通道的时候还累。

真正的转折点是我意识到：通道数量本身不产生价值，自动路由才产生价值。把 14 个免费通道并成 1 个入口，让系统根据任务类型自动决定走哪条通道，这才是这套方案的核心。这篇文章就把我踩过的坑、调通的配置、以及路由策略的设计思路完整拆开讲一遍。

这套方案适合几类人：一是手上有多个免费模型额度、想物尽其用的开发者；二是希望在不增加成本的前提下提升任务成功率和响应速度的独立开发者；三是想理解“网关 + 路由”这套架构到底怎么落地的人。哪怕你只用 WorkBuddy 做日常问答，看完也能把配置改得更顺手。

需要先说明一点：下面涉及的所有通道配置、路由规则、字段命名，都是基于我实际跑通的版本整理的。不同版本的 WorkBuddy 在字段细节上可能有差异，但整体思路是通用的。你照着改的时候，重点理解“为什么这么设计”，而不是死记字段名。

2. 拆解 WorkBuddy 的模型配置结构

2.1 models.json 到底管什么

WorkBuddy 的模型通道配置集中在一个models.json文件里。这个文件的核心作用就一件事：告诉 WorkBuddy “有哪些模型可以用、怎么调用它们”。它不负责决定“什么时候用哪个”，那是路由层的事。把这两件事分开理解，后面配置起来会清晰很多。

一个典型的通道条目包含几个关键字段：通道标识（id）、显示名称（name）、接口地址（baseURL）、鉴权信息（apiKey）、模型名（model）、以及可选的参数覆盖（如 temperature、maxTokens）。我第一次配的时候把 id 和 name 混着用，结果路由规则里引用的 id 和实际配置对不上，排查了半小时才发现是命名不一致。这个坑后面会专门讲。

models.json的结构大致是这样：

{ "providers": [ { "id": "channel-a", "name": "通道A", "baseURL": "https://example-a.com/v1", "apiKey": "your-key-a", "model": "model-name-a", "priority": 1, "tags": ["code", "fast"] }, { "id": "channel-b", "name": "通道B", "baseURL": "https://example-b.com/v1", "apiKey": "your-key-b", "model": "model-name-b", "priority": 2, "tags": ["writing", "long-context"] } ] }

这里我额外加了两个自定义字段：priority和tags。priority用于同类型通道之间的排序，tags用于路由匹配。这两个字段不是所有版本都原生支持，但即使不支持，你也可以在路由层自己维护一份映射表。我倾向于直接写在配置里，维护起来更集中。

2.2 通道的三种典型差异

14 个通道不是随便凑数的，它们之间存在实实在在的差异。理解这些差异，才能设计出合理的路由策略。我把它们归为三类：

能力差异是最直观的。我实测下来，某些通道在代码补全任务上的准确率明显高于其他通道，但在中文创意写作上就表现平平。反过来也一样。如果不做区分，一律走同一个通道，等于主动放弃了其他通道的优势。

性能差异容易被忽略。有些通道首字延迟很低，适合交互式问答；有些通道虽然慢，但一次能吞很长的上下文，适合处理长文档。把长文档丢给低延迟通道，往往因为上下文长度限制直接失败。

稳定性差异是最需要提前考虑的。免费通道普遍存在限流，区别只是频率和触发条件。我在配置里给每个通道标注了“限流敏感度”，路由时优先选择当前更稳的通道，失败后再降级到备选。

2.3 为什么不能只靠“默认通道 + 手动切换”

有人可能会想：我配一个默认通道，需要的时候手动切一下不就行了？我一开始就是这么干的，结论是：手动切换的成本被严重低估了。

手动切换的问题不在于“切”这个动作本身，而在于“判断该切哪个”这个决策。任务类型稍微模糊一点，你就要停下来想：这个任务算代码还是算写作？这个任务对延迟敏感吗？当前哪个通道没被限流？这些判断每次都要重新做，累积起来非常消耗注意力。

更麻烦的是，手动切换依赖你记得住每个通道的特性。14 个通道，你能记住几个？我最多记住五六个，剩下的全靠翻配置。自动路由的价值就在于：把“记住特性 + 判断匹配”这件事交给规则，你只需要发起任务。

3. 把 14 个通道并成 1 个入口的路由层设计

3.1 路由的本质是一次“任务分类”

自动路由听起来很玄，拆开看其实就两步：先判断这个任务属于什么类型，再根据类型选择通道。第一步是分类，第二步是映射。难点全在第一步。

我试过几种分类思路。最早是按关键词匹配，比如任务里出现“代码”“函数”“报错”就归为代码类。这个方法简单，但误判率高。比如“帮我写一段介绍这个函数的文案”，既有“函数”又有“文案”，关键词匹配就懵了。

后来改成按任务的结构特征分类，效果好很多。我用的判断维度包括：输入长度、是否包含代码块、是否要求特定输出格式、是否涉及多轮对话。这几个维度组合起来，基本能覆盖大部分场景。具体规则后面会给。

3.2 路由规则的优先级设计

路由规则不能是平铺的，必须有优先级。否则多条规则同时命中时，系统不知道该听谁的。我的优先级设计是这样的：

1. 显式指定优先：如果任务里明确写了“用 XX 通道”，直接走指定通道，跳过所有自动判断。
2. 格式要求优先：如果任务要求输出 JSON、表格等结构化格式，优先选结构化能力强的通道。
3. 任务类型匹配：按代码、写作、翻译、总结等类型匹配对应通道。
4. 延迟敏感匹配：交互式短任务优先低延迟通道。
5. 兜底默认：以上都不命中时，走默认通道。

这个顺序的逻辑是：越明确的需求越优先。显式指定最明确，所以排第一。格式要求比任务类型更具体，所以排在类型匹配前面。兜底放最后，保证任何任务都有通道可用。

3.3 一个可落地的路由配置示例

下面是我实际在用的路由配置结构。它不是 WorkBuddy 的原生格式，而是我在配置层之上加的一层映射。你可以把它理解成“路由表”：

{ "routes": [ { "match": { "explicit": true }, "target": "specified-channel" }, { "match": { "outputFormat": "json" }, "target": "structured-channel", "fallback": ["channel-a", "channel-b"] }, { "match": { "taskType": "code" }, "target": "code-channel", "fallback": ["channel-c", "channel-d"] }, { "match": { "taskType": "writing", "inputLength": "long" }, "target": "long-context-channel", "fallback": ["channel-e"] }, { "match": { "latencySensitive": true }, "target": "fast-channel", "fallback": ["channel-f", "channel-g"] } ], "default": "channel-a" }

每个路由条目都有target和fallback。target是首选通道，fallback是首选失败后的降级顺序。这个设计的关键在于：永远不要让任务因为单个通道失败而彻底失败。免费通道的不稳定性是常态，降级链是必需品。

4. 14 个通道的实测表现与选型依据

4.1 我实际配置的通道清单

下面这张表是我当前在用的通道清单。通道名称我做了脱敏处理，重点看它们的定位和实测表现：

这张表不是拍脑袋填的，是我连续两周记录每次调用的延迟和失败情况后统计出来的。延迟分三档：低（1 秒内）、中（1 到 5 秒）、高（5 秒以上）。限流频率也分三档，根据失败重试次数估算。

4.2 选型时最容易犯的三个错误

错误一：只看能力，不看稳定性。我一开始把能力最强的通道设为主力，结果它限流最频繁，一天要降级十几次。后来把稳定性纳入考量，主力换成了能力中等但几乎不限流的通道，整体体验反而更好。

错误二：通道越多越好。我一度配了 20 多个通道，结果维护成本急剧上升。很多通道特性重叠，路由时根本区分不出来。砍到 14 个之后，每个通道都有明确分工，维护起来清爽很多。通道数量应该由“有多少种明确的任务类型”决定，而不是“能找到多少个免费额度”决定。

错误三：忽略降级链的设计。只配首选通道，不配降级，等于把稳定性完全押在单个通道上。我现在的做法是每个任务类型至少配两条降级通道，重要任务配三条。

4.3 通道健康检查的简易实现

免费通道随时可能挂掉，所以需要一个轻量的健康检查。我的做法是每隔一段时间发一个极短的探测请求，记录响应时间和是否成功。探测请求要足够短，避免消耗额度：

import time import requests def health_check(channel): start = time.time() try: resp = requests.post( f"{channel['baseURL']}/chat/completions", headers={"Authorization": f"Bearer {channel['apiKey']}"}, json={ "model": channel["model"], "messages": [{"role": "user", "content": "hi"}], "max_tokens": 1 }, timeout=10 ) latency = time.time() - start return {"ok": resp.status_code == 200, "latency": latency} except Exception as e: return {"ok": False, "latency": None, "error": str(e)}

这个检查不需要跑得太频繁，我一般每 30 分钟跑一次。结果写回一个状态文件，路由时优先选择状态为健康的通道。注意max_tokens设成 1，把消耗降到最低。

5. 路由策略的调优过程与踩坑记录

5.1 第一个坑：id 命名不一致导致路由失效

前面提过这个坑，这里展开讲。我最初配置通道时，models.json里用的 id 是channel_a（下划线），但路由表里写的是channel-a（连字符）。结果路由规则全部不命中，所有任务都走了默认通道。我以为是路由逻辑没生效，排查了半天才发现是命名不一致。

这个坑的教训是：id 命名规范要统一，并且最好在配置加载时做一次校验。我现在的做法是加载配置后，检查路由表里引用的每个 target 和 fallback 是否都存在于通道列表中，不存在就报错。这样能在启动阶段就发现问题，而不是等到任务失败才发现。

def validate_routes(providers, routes): valid_ids = {p["id"] for p in providers} for route in routes: targets = [route["target"]] + route.get("fallback", []) for t in targets: if t not in valid_ids: raise ValueError(f"路由引用了不存在的通道: {t}")

5.2 第二个坑：任务分类过于激进

我一开始的分类规则写得很细，把任务分成了十几种类型。结果发现很多任务落在分类边界上，判断不准。比如“帮我优化这段代码的注释”，既像代码任务又像写作任务，规则给不出明确答案。

后来我把分类收敛到五类：代码、写作、翻译、总结、通用。每类只保留最核心的判断特征，边界模糊的一律归为通用。分类变粗之后，误判率反而下降了。分类的目的是路由，不是精确描述任务。够用就行，不需要追求完美分类。

5.3 第三个坑：降级链顺序不合理

降级链的顺序我改过好几次。最初是按通道编号顺序降级，结果经常降级到一个同样不稳定的通道，连续失败。后来改成按“稳定性优先”排序，把最稳的通道放在降级链前面，效果好很多。

现在的降级链排序原则是：先看健康状态，再看限流频率，最后看能力匹配度。健康状态是动态的，每次路由时实时判断。限流频率是统计值，定期更新。能力匹配度是静态配置。

5.4 第四个坑：忽略上下文长度限制

有一次我让系统处理一份很长的文档，路由到了低延迟通道，结果因为超出上下文长度直接报错。降级链里的下一个通道也是短上下文通道，又失败。最后才降级到长上下文通道，但已经浪费了两次调用。

这个坑的教训是：路由匹配时要把输入长度作为硬性条件。超过某个长度的任务，直接跳过所有短上下文通道，不要浪费降级次数。我在路由规则里加了一条：输入长度超过阈值时，只考虑长上下文通道。

6. 让路由规则对所有任务生效的配置技巧

6.1 全局规则与局部规则的分离

WorkBuddy 支持给任务定规则，但规则的作用范围需要明确。我的做法是把规则分成两层：全局规则对所有任务生效，局部规则只对特定任务类型生效。

全局规则包括：健康检查、降级链、超时设置、重试次数。这些规则不区分任务类型，所有任务都适用。局部规则包括：任务分类、通道匹配、参数覆盖。这些规则按任务类型区分。

分离的好处是：改全局规则时不会影响任务分类，改任务分类时不会影响降级逻辑。我见过有人把所有规则写在一起，改一处牵动全身，维护起来很痛苦。

6.2 规则生效的验证方法

规则配好之后，怎么确认它真的生效了？我的做法是构造一批测试任务，覆盖各种类型，然后看路由日志。日志里记录每个任务命中了哪条规则、走了哪个通道、是否降级。

def log_routing(task, matched_route, target, fallback_used): print(f"[路由] 任务类型={task['type']} " f"命中规则={matched_route} " f"目标通道={target} " f"是否降级={fallback_used}")

测试任务要覆盖：显式指定、JSON 输出、代码任务、长文任务、延迟敏感任务、以及一个故意模糊的任务。如果这六类任务都能路由到预期通道，说明规则基本正确。

6.3 规则冲突的处理

多条规则同时命中时，按优先级取最高的一条。但有时候优先级相同，就需要一个兜底判断。我的做法是：优先级相同时，取匹配条件更具体的那条。比如“代码任务 + 长输入”比“代码任务”更具体，优先命中前者。

如果实在无法判断，就记录一条警告日志，人工介入调整规则。我一般每周看一次警告日志，把频繁冲突的规则合并或拆分。

7. 日常使用中的实用心得

7.1 给通道打标签比记通道名有用

14 个通道，名字很难记住。但标签很好记：code、fast、long、json、writing。路由时按标签匹配，比按通道名匹配直观得多。我现在的配置里，通道名只是给人看的，标签才是给路由用的。

标签可以多个，一个通道可以同时有code和fast标签。路由时按标签组合匹配，灵活度很高。比如“代码 + 低延迟”就匹配同时有这两个标签的通道。

7.2 定期清理低效通道

免费通道会变化，有的会失效，有的会限流加剧。我每个月清理一次通道列表，把连续失败率高的通道移除，把新发现的稳定通道加进来。通道列表不是一成不变的，需要持续维护。

清理时我会看两个指标：成功率和平均延迟。成功率低于某个阈值的通道，先降级为备用；连续两个月都低，直接移除。延迟明显高于同类的通道，也考虑移除。

7.3 保留一个“最终兜底”通道

不管路由怎么设计，都要留一个最终兜底通道。这个通道的要求不是快，也不是能力强，而是几乎不会失败。我用的兜底通道响应慢、能力一般，但半年下来几乎没失败过。当所有其他通道都不可用时，它保证任务至少能完成。

兜底通道不参与正常路由，只在降级链全部失败后启用。它的存在价值是“保底”，不是“好用”。

7.4 路由日志要定期看

路由日志是调优的依据。我每周花十分钟看一遍日志，重点关注三类情况：频繁降级的任务、路由到兜底通道的任务、以及路由结果和预期不符的任务。这三类情况往往指向配置问题。

比如我发现某类任务频繁降级，查下来是首选通道的上下文长度不够。调整路由规则后，降级次数明显下降。这种优化不看日志是发现不了的。

8. 关于这套方案的边界与后续扩展

这套方案的核心是“分类 + 映射 + 降级”，不依赖特定平台或特定模型。只要你的工具支持多通道配置，就能套用这个思路。WorkBuddy 只是我用的载体，换成其他支持多通道的工具，逻辑是一样的。

需要提醒的是，自动路由不是万能的。它解决的是“选择通道”的问题，不解决“通道本身能力不足”的问题。如果所有通道在某类任务上都表现不好，路由再优化也没用。这种情况下，要么换通道，要么调整任务本身。

后续我打算在路由层加一个简单的反馈机制：任务完成后记录成功与否，用这些数据动态调整通道优先级。现在的优先级是静态配置的，如果能根据实际表现自动调整，应该会更省心。不过这个机制要小心设计，避免因为偶发失败就误判通道质量。

另外，通道的鉴权信息管理也值得单独做一层。现在 apiKey 直接写在配置里，如果配置泄露会有风险。后续考虑把敏感信息抽到环境变量或独立的密钥文件里，配置里只留引用。这个改动不大，但安全性提升明显。

最后分享一个我用了很久的小习惯：每次新增通道时，先单独测试它，确认能正常调用、延迟可接受、限流不严重，再写进路由配置。不要一次性加一堆通道然后一起调，那样出问题很难定位是哪个通道的锅。一个一个加，加一个测一个，稳扎稳打。