WorkBuddy原生深度适配的模型包括GLM-5.0（含Turbo）、GLM-4-Flash、混元-HunYuan-Pro及Kimi-K2.5-Thinking，它们与技能调用、文件处理等底层能力打通，稳定性高、响应快。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
WorkBuddy 当前支持切换的模型分三类：平台原生深度适配的国内主流模型、国际模型通道、以及完全自定义的 OpenAI 兼容 API 接入。不是所有列出的模型在每个设备或账号下都默认可用，能否调用取决于你的部署模式（小程序 / 桌面版 / 企业版）和网络环境。
哪些模型是 WorkBuddy 原生深度适配的？
原生适配意味着模型与 WorkBuddy 的技能调用、文件处理、上下文管理等能力做了底层打通，稳定性高、出错率低、响应快。目前明确标注为「原生深度适配」的有：
-
GLM-5.0（含GLM-5.0-Turbo）、GLM-4-Flash：文档生成、批量文件处理、格式转换最稳，尤其适合 Word/PDF/Excel 场景 -
混元-HunYuan-Pro（非免费版）：腾讯云账号直连，对腾讯生态内服务（如 Coding Plan、COS 文件）调用成功率最高 -
Kimi-K2.5-Thinking（注意不是旧版 Kimi-K2-Thinking）：仅限 Mac 微信直连版和桌面版可用，深度分析类任务（如合同条款比对、研报逻辑拆解）表现突出
⚠️ 容易踩的坑：Kimi-K2-Thinking 在小程序里仍存在 JS 脚本注入风险，生成 Word 时可能卡死；DeepSeek-V3 虽然列在模型列表中，但未完成技能链适配，调用 docx_skill 或 batch_pdf_merge 会直接报 skill_not_supported 错误。
Ollama 本地模型怎么配才真正能用？
Ollama 不是“选了就能跑”，必须手动配置推理参数，否则多数模型会因上下文截断或工具调用失败而静默退出。
使用固定的 Next.js/Tailwind/Prisma 技术栈构建并记录独立 SaaS 项目，仅将 FastAPI 用于 Python 工作负载，并遵循严格的架构规范。
- 必须显式设置
tool_choice为auto或指定函数名，否则插件调用不触发 -
input_context_length建议 ≥ 32768，低于此值会导致长文档解析中断（例如处理 >10 页 PDF 时突然停在第 7 页） - 图片输入需开启
vision_enabled: true，且模型本身要支持多模态（如llava-1.6-mistral），纯文本模型即使开了也返回空 - 路径必须写成绝对路径：
/Users/xxx/.ollama/models/blobs/sha256-xxx，相对路径或~符号会被忽略
国际模型通道的实际限制有哪些？
国际模型（OpenAI、Gemini、OpenRouter）走的是代理通道，不是直连，因此存在隐性约束：
-
OpenAI通道只认gpt-4o和gpt-4-turbo，填gpt-4.5会 fallback 到gpt-4o并静默提示“模型已降级” -
Gemini必须用gemini-2.0-flash-exp或gemini-2.0-pro-exp，旧版gemini-1.5-pro已被 WorkBuddy 后端屏蔽，选择后会卡在 loading 状态超 90 秒自动断开 -
OpenRouter需自行粘贴 API Key，且仅支持带openai-compatible标签的模型（如qwen/qwen2.5-72b-instruct），不支持原生 OpenRouter 协议的模型（如meta-llama/llama-3.1-405b-instruct）
这些通道在小程序里默认关闭，仅桌面版和企业版可见；Mac 微信直连版即使开启，也会因微信 sandbox 限制无法上传本地文件到 Gemini。
模型列表会随版本动态调整，但核心原则不变：优先用带「原生适配」标识的模型做技能任务，Ollama 本地模型务必核对 tool_choice 和上下文长度，国际通道别信名字——得看 WorkBuddy 后端实际放行了哪个具体版本。
