企业官网建设流程全解析

先说结论：WorkBuddy 这类 Agent 工作台，如果只是当成普通聊天框来用，就太浪费了。真正让它拉开差距的，是能把多个模型通道揉在一起，按任务类型自动挑出最合适的模型。我花了两天时间，把手头能用的免费模型资源全部理了一遍，在 WorkBuddy 里接入了 14 个免费通道，并成一个入口，再靠一套路由规则把“日常对话、写代码、读长文、翻译、画图理解”这五类任务自动分流到不同模型上。实测下来，想做的事基本不用手动切模型，体验相当顺。

这篇文章把这套东西完整拆开讲：为什么要把免费通道统一收口、14 个通道怎么选型、路由规则怎么写才能对所有任务永久生效、以及我踩过的那些限流和超时的坑。适合已经在用或准备用 WorkBuddy 的朋友，也适合想把免费模型资源利用到极致的人。整个方案不花一分钱，本地模型兜底也能保证断网或接口全挂时不至于完全停工。

1. 先想清楚：14 个免费通道为什么要并成 1 个入口

1.1 免费模型资源的真实状态：散、碎、不稳定

免费模型这东西，互联网上其实很多，但问题从来不是“有没有”，而是“好不好用”。打开浏览器能搜出一堆公益 API、个人分享接口、开放平台免费额度，真要用起来，每个都是一套独立的 BaseURL、API Key、模型名和限流规则。今天这个平台送了 50 万 token，明天那个社区接口还能用，后天可能就 401 了。把这些东西堆在桌面上，每次换个任务都要重新复制粘贴地址和密钥，光切换成本就能把人劝退。

更麻烦的是各模型的擅长领域差异极大。同一个问题，代码生成用 DeepSeek 的模型可能一次过，用某个通用对话模型就得反复调；一份 20 页的 PDF 要总结，普通上下文窗口塞不下，必须换长文本模型；翻译任务拼的是语言理解力，跟代码推理模型又不是一挂的。也就是说，免费模型不是“一个打十个”，而是“十个各打一个”，这就要求你得有个东西能在它们之间自动调度。

1.2 统一入口解决的核心问题不只是“少记几个密码”

把 14 个免费通道并成一个入口，看起来像是省了记 API Key 的事，实际价值远不止这个。先说你最直观的感受：原来在不同模型之间切换，对话上下文是断裂的。你在 A 通道聊了一半的问题，切到 B 通道之后，B 什么都不知道，还得重新贴一遍背景。而统一入口之后，WorkBuddy 的会话上下文一直保持在同一个对话里，内部路由换模型，外部对话不中断，这才是“一个入口”真正的含金量。

其次是失败兜底。免费通道天生不稳定，429 限流是家常便饭，有时候上午能用下午 502。如果只有一个通道，接口挂了你只能干等；但当你把 14 个通道编排进同一入口，并写清楚失败切换规则，A 挂了自动走 B，B 超时就落到本地模型，整个过程用户无感。这个容错能力，在实际干活的时候比模型本身的天花板还重要。

1.3 自动路由的边界：不是越聪明越好

自动路由要解决的是“大多数情况下的最优选择”，不是“所有情况下的绝对精确”。我见过有人把路由规则写得极其复杂，要嗅探任务意图、要算上下文长度、要评估成本，结果规则本身出错率比模型还高。我的建议很简单：按任务大类走固定映射，保留手动切换的入口，规则只处理高频场景，低频特殊需求直接手动指定模型。

边界想清楚了，后面的配置才不会失控。路由规则真正要服务的是两类人：一类是模型多到切不过来的重度用户，另一类是啥都想白嫖的学生党和个人开发者。团队场景其实不太建议纯免费通道，后面我会单独说原因。

2. 通道盘点与模型画像：14 个通道到底怎么选

2.1 四类常见免费模型服务，我各要了几个

免费通道的来源，我一般分成四类，每一类的可靠程度和适用场景都不一样。

第一类是官方平台的免费额度。国内不少大模型平台注册就送 token，DeepSeek、智谱、通义、Kimi、百度千帆这些都有，有的还定期搞活动。这类通道质量最稳，合规性和隐私保护也相对靠谱，适合当主力通道。

第二类是海外聚合平台的免费模型。像 OpenRouter 这类服务，一个 Key 能访问几百个模型，其中有不少是免费的。这类通道好处是换模型方便，坏处是免费模型往往排队严重、速度不稳定，适合做备胎。

第三类是本地模型服务。Ollama 跑 qwen2.5、llama3 这些，完全不花钱，数据不出本机，性能取决于你的电脑。它最大的价值是当全链路兜底：所有远端通道全挂时，至少还有本地模型能接住任务。

第四类是社区公益 API 和个人分享接口。这类通道我今天必须泼盆冷水：能用的确实有，但来路不明、没有服务保障、Key 随时会被回收，最关键的是数据隐私完全不可控。我自己的处理方式是只用来问无关紧要的问题，绝不拿它处理任何工作文档或个人敏感信息。这条原则，建议你也守死。

2.2 按任务画模型画像：什么活交给什么模型

自动路由的前提是你心里先有谱。我的经验是先把日常需求归纳成五类，再给每一类配上合适的模型画像：

别小看这张画像，它直接决定路由规则怎么写。你让一个代码模型去读 PDF，不是不行，但上下文窗口经常爆；让长文本模型去写代码，出来的代码质量大概率不如专业代码模型。“按任务选模型”听起来像废话，但把 14 个通道全堆到一个默认模型里，这个废话就是最容易犯的错。

2.3 我的 14 通道配置清单（可直接抄作业）

我实际在 WorkBuddy 里接入的通道如下，每个通道都标了定位和默认用途。注意这是我个人机器的配置，你照抄的时候要换成你自己的 API Key，公益通道尤其要以实际可用为准。

这套清单的关键不是数量多，而是分层明确。前八个通道是正经干活的主力，第九第十个是快聊用的，十三十四是纯粹薅羊毛的备用，十二十一则是最后的保命符。分层清晰之后，路由规则的优先级才能顺理成章地写出来。

3. 在 WorkBuddy 里落地：通道配置与全局路由规则

3.1 通道配置的基本结构，三件套缺一不可

无论 WorkBuddy 还是同类工具，自定义通道基本都逃不过三样东西：服务地址 BaseURL、API Key、模型名称。至于为什么一定要把 API Key 放到环境变量里而不是直接写死在配置文件里，是因为配置文件可能会同步到云端，也可能不小心分享给别人，一旦泄露，你的免费额度会被刷爆，严重的还会被封号。

我在 WorkBuddy 里的通道配置大致长这样，字段名可能因版本略有差异，但思路通用：

{ "channels": [ { "name": "deepseek-reasoner", "type": "openai-compatible", "baseUrl": "https://api.deepseek.com/v1", "apiKeyEnv": "DEEPSEEK_API_KEY", "models": ["deepseek-reasoner"], "priority": 1, "timeout": 60, "retry": 2 }, { "name": "ollama-qwen2.5", "type": "openai-compatible", "baseUrl": "http://localhost:11434/v1", "apiKeyEnv": "OLLAMA_API_KEY", "models": ["qwen2.5:14b"], "priority": 99, "timeout": 120 } ] }

配置里的timeout和retry是很多人忽略的重点。免费通道响应慢是常态，超时设太短会误判失败，设太长又会让整个会话卡住。我的经验是：官方通道设 60 秒，本地模型设 120 秒，社区公益接口设 30 秒就够了。retry一般设为 1 到 2 次，且只对超时和 5xx 错误生效，遇到 401 和 429 别盲目重试。

3.2 给 WorkBuddy 定几条全局规则，让路由对所有任务生效

“给 workbuddy 定几条规则，后续对所有任务都生效”这个需求，我在网上看到很多人问。其实这就是全局规则（Global Rules）的用武之地。WorkBuddy 这类工具通常支持一个全局规则文件或系统级设置，里面的规则会作为系统提示词的一部分注入每次任务，所以能对后续所有任务生效。

我的全局规则里最关键的一段，是明确要求 WorkBuddy 按任务类型自动选择模型通道。你可以把它理解成给助手立规矩：开局就把选择逻辑说清楚，后面每次任务它都会自动遵守。实际写法大概是这样的：

# WorkBuddy 全局规则（对所有任务生效） ## 模型路由策略 1. 当任务属于代码生成、代码调试、Code Review 时，默认使用 deepseek-reasoner 通道；若该通道返回 429 或 5xx，自动降级到 deepseek-chat； 2. 当任务需要处理长文档（超过 8000 字）、PDF 总结、网页长文归纳时，默认使用 qwen-long 通道；若不可用，切换到 moonshot-v1-8k； 3. 当任务为中英或多语种翻译、中文润色时，默认使用 glm-4-plus；若不可用，切换到 qwen-plus； 4. 当任务为图像理解（截图、图表、照片描述）时，默认使用 qwen-vl； 5. 当任务为日常闲聊、快速问答、头脑风暴，默认使用 llama-3.1-70b（Groq）； 6. 当以上所有通道均失败时，使用 ollama-qwen2.5 本地模型兜底。

这里有个细节：规则指令要写得“可判定”。比如“长文档”要给出具体字数阈值，“代码任务”要列出典型行为，而不是泛泛说“智能选择”。因为模型对模糊指令的理解不稳定，你给它的标准越明确，它路由越准。实际测试中，把“超过 8000 字”改成“上下文提示超过 60% 或文件内容超过 8000 字”之后，路由命中率明显提升。

3.3 路由规则的实际判定逻辑：优先级是灵魂

全局规则是一层，通道配置文件里的优先级是另一层。我个人做法是把所有通道丢到一个逻辑分组里，按优先级从高到低排列，由 WorkBuddy 根据任务判断该走哪一个。

路由判定我建议遵守三个原则：先看任务类型，再看上下文压力，最后看失败反馈。伪代码逻辑如下：

function route(task): if task is image_understanding: return "qwen-vl" if task is code_task: if deepseek_reasoner_available(): return "deepseek-reasoner" else: return "deepseek-chat" if task is long_text: if context_token_count() > threshold: return "qwen-long" else: return "moonshot-v1-8k" if task is translation: return "glm-4-plus" if task is casual_chat: return "llama-3.1-70b" # 兜底 if all_failed(): return "ollama-qwen2.5"

优先级为什么要硬编码而不是让模型自己选？因为模型自己选往往会受训练偏好影响，一个模型总觉得自己什么都能干，结果就是它永远优先调用自己，路由形同虚设。规则必须硬性指定“这个任务类型只能走这些通道”，模型只是执行者，不是决策者，这是保持路由稳定性的关键。

3.4 验证路由是否命中：不看日志等于白配

配完规则一定要验证，而且不能只验证一次。同一类任务连续测 10 次，看路由结果是否稳定；再故意把某个主力通道的 Key 改错，看是否自动降级到备用通道。WorkBuddy 的会话日志或调试面板会显示出实际调用的是哪个通道、耗时多少、返回码是什么。

我在第一次配完路由的时候，就遇到过“规则写了等于没写”的情况：所有任务都还是走默认模型，日志里根本没有命中路由分支。排查后发现是全局规则文件的保存位置不对，工具加载的是缓存副本。当时把文件删掉重新放了一遍，重启工作台，规则才真正生效。这个坑提醒大家：改完规则之后，一定要确认“当前任务实际使用的模型”这一栏发生了变化，而不是只看规则文件是否保存成功。

4. 实操过程与踩坑指南

4.1 从零接通的完整流程记录

如果你也想复刻这套 14 通道方案，这里把整个操作流程串一遍，按顺序做基本不会乱。

第一步，先把所有能注册的官方平台账号注册好，领取免费额度，拿到 API Key，存进系统环境变量。第二步，下载并安装 Ollama，把 qwen2.5 和 llama3 两个模型拉下来备用。第三步，打开 WorkBuddy 的设置面板，找到模型服务或通道管理入口，逐个添加刚才整理出来的通道，每加一个就用“发送测试消息”验证一次。第四步，把所有通道加入统一分组，并设置好优先级顺序。第五步，编辑全局规则文件，把 3.2 节那段路由策略粘进去，替换成你自己的通道名。第六步，重启 WorkBuddy，打开日志面板，逐类任务测试路由是否生效。第七步，故意停用主力通道，验证失败切换和本地兜底是否正常。

整个流程看起来不复杂，但第一次全走完我花了大约一个下午，主要时间都耗在“这个模型名在对应平台叫什么”上。免费模型平台的模型标识经常变，有的是deepseek-chat，有的叫glm-4-plus，还有叫ernie-speed-128k的，填错一个模型名就是 404。经验是：先去各平台文档里把准确的模型 ID 复制下来，再填进 WorkBuddy，不要靠记忆手打。

4.2 常见错误与排查速查表

实际操作中遇到各类报错的概率相当高，下面这张表是我自己整理的问题排查清单，覆盖了免费通道接入时 90% 的坑：

这里特别说一下 429 限流。免费通道的限流一般分两种：每分钟请求数限制和每天 token 数限制。前者表现为短时间内连续报 429，后者表现为早上还能用下午就挂了。排查时先分清楚是哪一种，再决定是加冷却时间还是换通道。我为了减少 429 对工作的打断，特意在配置里把低优先级的公益通道的并发请求数设得很低，让它们只作为后备力量，不参与抢任务。

4.3 免费通道稳定性实战心得与安全底线

免费通道最大的谎言就是“永久可用”。今天能用的公益接口，明天可能就换了地址；官方送的 token，用完了就是完了。所以整套方案必须在设计上接受这个现实：所有免费通道都是消耗品，路由规则要写得很容易替换，通道配置里的 Key 过期时，顺手改一下环境变量就行，而不是每次都要重新搭一套规则。

安全底线上，有一条我每次都强调：免费通道，尤其是社区公益接口，只配处理无关紧要的日常问题。别把公司代码、未公开文档、个人隐私发过去，因为你根本不知道接口背后是谁在跑、日志落在了哪里。本地模型的价值在这个维度上尤其大：能本地跑的绝不发远端，能走官方通道的绝不走社区接口。这既是安全习惯，也是对自己数据的保护。

5. 路由之外的进阶建议：让这套方案更好用

5.1 把 Skills 和路由规则接起来，效果更大

WorkBuddy 的 Skills 机制很有意思。它相当于给助手装了一堆“专项能力包”，比如某个 Skill 专门负责写 SQL、某个 Skill 专门负责整理会议纪要、某个 Skill 专门负责生成正则表达式。如果你只是让 Skill 干活但不告诉它用哪个模型，效果一般；但如果你在 Skill 描述里写明“本 Skill 所有任务默认走 deepseek-reasoner”，路由命中率会明显提高，因为 Skill 本身就是任务类型的最强信号。

我在实际使用中给三个高频 Skill 绑定了特定通道：SQL 生成绑定代码模型，长文总结绑定长文本模型，翻译润色绑定 GLM。结果就是同一个命令，绑定前的输出质量和绑定后的输出质量不在一个档次上。建议你也把 WorkBuddy 里最常用的那几个 Skill 翻出来，逐个确认它们走的模型通道是不是最优解。

5.2 缓存目录与日志治理

跑免费模型的时候，另一个容易忽略的问题是缓存和日志。WorkBuddy 默认会把会话记录、模型返回结果、附件缓存都放在系统缓存目录下，时间长了会越来越大。你可以在设置里把缓存目录改到空间充足、方便清理的位置，比如专门的D:/workbuddy-cache。日志这块建议只保留路由相关的日志级别，不然免费通道频繁重试会刷出大量 Error 日志，反而掩盖真正的问题。

5.3 进阶：本地模型兜底与自定义通道扩展

如果你对本地模型感兴趣，可以再进一步：把 Ollama 部署成多模型多端口的服务，一个端口跑通用对话，一个端口跑代码模型，WorkBuddy 里分别配置为两个独立通道。逻辑上不复杂，但确实能增强整套路由的应变能力。比如断网状态下，远端通道全挂，本地通道依然稳定输出。

自定义通道扩展方面，密钥管理是重中之重。我个人的做法是维护一个.env文件（仅保存在本地，不加入版本控制），里面放所有通道的 API Key，WorkBuddy 读取环境变量来获取。这样即使配置文件不小心发给别人，也不会泄露密钥。

5.4 推荐的自检清单：配置安全回顾

最后分享一份我每次调整通道后都会过一遍的自检清单：

• 新加入的通道是否先跑通了测试消息；
• 环境变量是否已配置，配置值是不是最新的；
• 全局规则文件保存位置是否正确；
• 主力通道的优先级是否高于备用通道；
• 本地 Ollama 服务是否在开机自启；
• 社区公益通道是否被标记为“不用于敏感任务”；
• 日志中该走deepseek-reasoner的任务是否真的走了；
• 缓存目录是否还有足够空间。

这套 14 通道并 1 入口的方案，不追求“模型数量最多”，追求的是“每个任务都有最合适的免费模型在干活，且整个过程不需要你关心通道细节”。WorkBuddy 只是载体，路由思路和选型原则才是可以迁移到任何同类工具的核心资产。把复杂留给配置，把简单留给使用，这不只是工具调优，也是做事的思路。