最近一段时间我一直在本地折腾 DeepSeek、Qwen 和 Ollama 这套组合结果桌面标签页越开越多一个网页在聊 DeepSeek一个控制台在跑 Ollama 命令还有一个在翻 Qwen 的文档API Key 散落在记事本里会话记录也是一段一段的中间串不起来特别难受。后来我找到一个小众但很对味的方案——一个纯前端、零后端的本地优先大模型工作台仓库代号就叫 Lab。它把 DeepSeek、Qwen、Ollama 和 Claude 全部收进同一个浏览器窗口会话记录只存在本地不用起任何后端服务装完就是一套可以长期用的大模型工作台。如果你平时主要用 ChatGPT 网页版或者某个平台自带页面可能对这个项目没太大感觉。但如果你像我一样手上有好几个模型的 API Key又跑着本地 Ollama 模型那你一定会理解“把所有模型塞进一个界面还能统一管理会话”这件事有多爽。这篇文章我就从架构设计、核心功能拆解、部署配置到踩坑排查完整讲一遍这类纯前端工作台到底怎么玩适合哪些人有哪些坑。1. 为什么要选纯前端零后端的本地优先后端架构1.1 传统大模型工具的架构代价先说说市面上主流的大模型聊天工具是怎么做的。Open WebUI 是很优秀的项目功能多、插件多、用户体系也完整但它是典型的前后端一体架构部署需要 Docker底层还要起 Python 服务数据默认放在数据库里。如果你想在多台设备上用还得配反向代理、考虑认证整套下来已经接近一个小型软件项目了。LobeChat 也很出名界面漂亮插件生态丰富但它的默认部署方式是 Next.js 前后端一体至少需要一个 Node 服务在跑。Chatbox 这类桌面应用看起来是“装个 App 就能用”实际上它内置了运行时本质上是把一个后端进程打包进了客户端。不是说这些方案不好而是对很多只是想“本地聊个模型、管理一下 API Key”的人来说它们的架构成本明显偏高。我个人的需求其实很朴素不用装 Docker不用维护数据库不用注册服务器打开浏览器就能用会话记录我自己能控制。这种需求下纯前端方案就是最优解体积小、启动快、没有服务端可以崩数据归属于浏览器本地隐私性天然更好。1.2 纯前端为什么也能驱动大模型你可能会问没有后端浏览器怎么调大模型这里的关键在于几乎所有主流模型服务商都提供了 HTTP API而浏览器本身就是一个 HTTP 客户端。当你把 API Key 配置好后前端直接向模型的 API 端点发起请求拿到响应渲染到页面上逻辑上完全说得通。但浏览器直连有一个前提就是服务端必须允许跨域访问也就是返回 CORS 响应头。好消息是很多云服务商的 API 已经支持浏览器跨域比如 DeepSeek 开放平台的接口、OpenRouter 这类聚合平台的接口都能从浏览器直接调用。Ollama 是跑在本地的服务默认本地监听跨域策略也可以通过环境变量放开所以纯前端方案在技术上完全可行。这样一来整个工作台可以做成完全静态的网站一个 HTML 文件加一堆 JS 资源构建完之后往任何静态托管平台一扔就能用。没有独立的 API 代理层没有会话数据库所有状态都落在浏览器自己的存储里。整个架构轻到令人发指是我喜欢它的核心原因。1.3 本地优先到底意味着什么本地优先这个概念的含金量用一次就懂。传统在线工具把对话记录存到服务端你删除账号或者服务商跑路数据说没就没。本地优先方案则把所有会话历史、Prompt 模板、模型配置全部保存在浏览器本地存储中比如 IndexedDB 和 localStorage。你在本地聊了什么模型厂商并不知道因为聊天内容是以参数形式直接发出去的并不会经过任何第三方服务器存储。本地优先的另一个直接收益就是离线可用。你只要配好 Ollama 本地模型把网线拔了照样能用特别适合在飞机上、地铁里或者网络不稳定的场景。我自己经常在通勤路上用笔记本电脑继续处理之前的工作会话完全不受网络影响。当然本地优先也有代价换设备时配置和数据不会自动同步。我一般会在旧设备上把常用 Prompt 模板复制一份新设备上重新粘贴配置。不过换个角度想这也意味着你没有把数据交给任何人隐私安全是自己掌控的这在现在的环境里反而是一种难得的优点。1.4 和主流方案的对比方案是否需要后端数据存储位置安装成本适合人群Open WebUI需要 Docker Python数据库高团队协作、功能需求全面LobeChat 自部署默认需要 Node 服务数据库/对象存储中高喜欢插件生态和精致 UIChatbox 桌面端客户端内置运行时本地数据库文件中喜欢独立 App 的用户纯前端工作台Lab 这类不需要浏览器本地存储极低个人日常、本地模型、隐私敏感场景2. 深入拆解 Lab 工作台的核心能力2.1 统一 Provider 抽象层屏蔽所有模型差异一个模型工作台如果只支持一个模型那根本不需要特意做。Lab 这类项目真正的技术难点是把差异巨大的各家 API 协议统一起来。DeepSeek、Qwen、Ollama 都遵循 OpenAI 的 /chat/completions 接口格式请求体和响应结构基本一致处理起来还算轻松。但 Claude 走的是 Anthropic Messages API请求结构完全不同连消息格式、流式事件类型都不一样。所以项目内部一般会有一个 Provider 抽象层。前端统一维护一套内部的消息结构比如数组里每项是角色加内容。发给各家模型时再根据当前选择的 Provider 把内部消息转换成对应 API 的请求格式响应回来时再反向解析成统一结构。这样你在界面上切换模型时对话上下文格式不会有任何感知差异用起来特别顺滑。我自己在配置时最直观的感受是同一个会话里想从 DeepSeek 切到 Ollama 继续聊上下文依然是连贯的因为底层消息历史是同一份只是发送时协议转换方式变了。习惯了这种统一体验之后再让我回各个平台分别聊就会感觉很割裂。2.2 流式输出是体验的核心处理不好就是灾难大模型响应动辄几百上千字如果等完整返回再展示用户体验是灾难性的。所以所有主流前端工作台都会做流式输出。这里用到的底层能力是 SSE 配合 fetch 的 ReadableStream也就是浏览器收到的是分段抵达的文本流前端每拿到一段就追加到对话气泡里实现类似打字机的逐字输出效果。Lab 这类纯前端项目对流式处理的精细程度直接决定了使用体验。我上手之后发现的细节是不同模型对流式的支持程度不一样DeepSeek 的 deepseek-chat 流式返回比较标准内容一段段来DeepSeek 的 deepseek-reasoner 会在流式过程中先返回思考过程再返回正式回答Ollama 自带 OpenAI 兼容端点流式格式也基本一致Claude 则有自己的流式事件类型比如 message_start、content_block_delta 这些解析逻辑完全独立。所以如果你看项目源码会看到每个 Provider 都有单独的流式解析器这就是为了应对这些差异。用户侧的感知是打字流畅、中断及时而这些体验是靠大量细节堆出来的。2.3 会话管理和 Prompt 模板的本地化存储会话管理是工作台的基本功。纯前端项目一般会把每个会话保存为独立的记录包含会话标题、消息列表、使用的模型配置、创建时间等信息存储位置选 IndexedDB。IndexedDB 的好处是能存结构化对象容量远大于 localStorage适合存储长对话历史。Prompt 模板这个功能我也非常依赖。我平时写文章、写代码、做翻译、做总结每个场景都有固定的指令前缀。在 Lab 里这些模板可以保存下来新建会话时一键选择不用每次重复输入。模板同样存在本地不会上传换模型也能复用。这里有个小建议如果你从别的工具迁移过来先花半小时把你的常用 Prompt 模板整理好再开始日常使用后面的效率提升非常明显。我就是在迁移时顺手整理了大概十几个模板现在工作流丝滑很多。2.4 多模型会话切换与并发调用既然把多个模型塞进了一个工作台合理的操作逻辑应该是随时切换当前会话使用的模型而不是每个模型开一个独立聊天窗口。Lab 这类项目一般会支持会话级别和全局级别两种模型选择方式全局设置里配置好所有 Provider 和默认模型新建会话时直接继承单个会话内部也可以临时切换模型切换后后续消息使用新模型历史消息继续保留。有些项目还支持把同一个 Prompt 并行发给多个模型然后把所有回答同时渲染出来方便横向对比。这个功能对做 prompt 评测或者模型选型的场景特别有用。我自己在对比 Qwen 和 DeepSeek 的中文写作能力时就经常用这个功能效率比开多个窗口高很多。3. 从零部署到跑通四个模型3.1 把项目跑起来Lab 这类纯前端项目交付形态通常是一个基于 Vite 的静态 Web 应用。你只需要把项目代码拿到本地然后按常规前端项目流程启动即可。# 拉取项目代码以 Git 为例 git clone [项目地址] lab-workbench cd lab-workbench # 安装依赖 npm install # 本地开发模式启动 npm run devnpm run dev 启动后终端会打印一个本地地址一般是 http://localhost:5173。浏览器打开这个地址工作台界面就出来了。如果你不想动命令行也有更省事的路径项目发布时构建出来的 dist 目录是一堆纯静态文件随便找个静态服务器甚至双击 index.html 都可能直接打开部分功能会受浏览器安全策略限制建议还是用静态服务器方式。我自己现在的用法是构建一次之后放到树莓派上的 Nginx 静态目录里全家设备都能通过局域网访问体验和在线服务一样但服务端只有一个几十兆的轻量 Web 服务干净利落。3.2 接入本地的 Ollama 模型Lab 支持 Ollama 是它最吸引我的一点因为 Ollama 是本地模型运行的事实标准之一。先确保你电脑上装好了 Ollama然后拉取你需要的模型# 拉取 Qwen 2.5 7B 作为日常模型 ollama pull qwen2.5:7b # 再拉一个轻量的 DeepSeek R1 蒸馏版做测试 ollama pull deepseek-r1:7b接下来非常关键的一步让浏览器能够访问 Ollama 的服务。Ollama 默认监听 http://localhost:11434并且默认只允许来自本机的特定请求浏览器页面直接调用可能会被跨域策略拦截。解决办法是给 Ollama 设置一个环境变量让它接受浏览器来源的跨域请求。在 macOS 或 Linux 下# 允许所有来源访问 Ollama export OLLAMA_ORIGINS* ollama serve在 Windows 下可以通过系统环境变量添加 OLLAMA_ORIGINS值为 *然后重启 Ollama 服务。设置好之后在 Lab 的配置页面新建一个 Ollama ProviderAPI 地址填 http://localhost:11434/v1模型列表会自动读取到本机已经拉取的模型。选好模型直接就能本地对话断网也能用。这个体验我建议每个人都试一次真的会上瘾。3.3 配置 DeepSeek 和 Qwen 云 APIDeepSeek 的接入比较简单。先去 DeepSeek 开放平台注册账号创建 API Key然后在 Lab 里选择添加 OpenAI 兼容 ProviderAPI 地址填 https://api.deepseek.com部分环境需要填 https://api.deepseek.com/v1两者等价模型名填 deepseek-chat 或 deepseek-reasonerAPI Key 粘贴你申请的 Keydeepseek-chat 是通用对话模型日常写作、问答、翻译都够用。deepseek-reasoner 是深度思考模型会在回答前生成一段推理内容适合处理逻辑推理、复杂分析类任务。配置好之后两个模型都能在同一个工作台里切换使用。Qwen 这边走的是阿里云百炼的 OpenAI 兼容接口。同样需要先开通百炼服务拿到 API Key然后配置 OpenAI 兼容 ProviderAPI 地址填 https://dashscope.aliyuncs.com/compatible-mode/v1模型名填 qwen-plus 或 qwen-turbo按需选择API Key 填百炼的密钥有一点需要注意Qwen 的模型名体系里qwen-plus、qwen-turbo、qwen-max 这些是平台命名跟你在 Ollama 本地看到的 qwen2.5:7b 不是一回事。云端 API 必须使用平台定义的模型标识不要直接搬运本地模型名。3.4 配置 Claude 时的 CORS 问题Claude 的接入比较特殊。Anthropic 官方 API 使用的是自己的 Messages API而不是 OpenAI 兼容格式所以在选择 Provider 类型时需要选择 Anthropic 类型而不是 OpenAI 兼容类型。API Key 在 Anthropic Console 创建模型名类似 claude-sonnet-4-20250514 或者 claude-3-5-sonnet-20241022以官方控制台给出的模型 ID 为准。不过在实际使用中浏览器直连 Anthropic 官方 API 可能会遇到 CORS 限制。如果你在 Lab 里配置完 Claude 后发送消息报跨域错误不要慌一般有两条路一是通过支持 CORS 的模型聚合服务去接 Claude比如 OpenRouter 这类平台这种方式在纯前端项目里非常常见二是本地起一个极轻量的转发服务把请求从浏览器转发到 Anthropic API这就等于你给 Claude 单独配了一个本地跨域助手。我个人目前的用法是Ollama 本地模型做日常草稿和总结DeepSeek 做主力日常问答Claude 处理需要长上下文和精细化写作的任务。一个页面四个模型切换成本几乎为零。3.5 构建发布成可长期使用的应用配置好之后最后一步是把工作台构建成正式版本方便长期使用。Vite 项目的构建命令npm run build构建完成后项目根目录下会生成一个 dist 文件夹里面就是全部静态资源。你把这个文件夹扔到任意静态托管平台即可。比如用 GitHub Pages、Vercel 静态部署或者在家里电脑、树莓派上装一个 Nginx / Caddy把 dist 目录指过去局域网内所有设备都能访问。我自己现在是构建一次放到家里服务器上手机、平板、工作电脑都能打开同一个地址使用。因为数据存储在各自的浏览器本地所以每台设备上的会话记录是独立的这个符合本地优先的设计哲学不一定适合所有人但对我这种单设备深度使用场景来说很合适。4. 典型问题排查与避坑经验4.1 CORS 跨域报错这是纯前端方案绕不开的第一大坑。在浏览器控制台看到 Access-Control-Allow-Origin 相关的报错时先确认你是不是访问的官方 API 域名的正确版本。Ollama 的跨域需要在 Ollama 服务端设置 OLLAMA_ORIGINS云服务商的跨域则要看对方是否开放了浏览器跨域。DeepSeek 和 OpenRouter 这类平台实测可以直连Anthropic 官方 API 在浏览器直连可能被限建议改用聚合平台或本地转发。4.2 Ollama 拉取模型速度慢很多人卡在第一步ollama pull 模型的时候速度感人。这个一般是网络环境造成的下载瓶颈解决方案一般有两个方向一是配置国内可用的镜像源通过环境变量指向镜像地址再拉取二是找一台网络条件好的机器先把模型拉下来再通过离线方式导入。Ollama 社区对这个问题的讨论很多不同网络环境下最优解不一样需要自己实测几次。4.3 流式输出中途断流如果对话输出到一半突然停了可能是网络不稳定导致连接中断。这时候工作台一般会显示重试或者继续生成的按钮不会让你手动复制重来。我自己遇到过的另一个情况是某些模型在长输出时响应时间太长超过了浏览器的默认等待时间这个建议到 Lab 的设置里把超时时间调大一点。我的经验值是把超时调整到 120 秒以上基本能覆盖绝大多数场景。4.4 API Key 的安全边界要清楚纯前端工作台最需要注意的一点是你的 API Key 保存在浏览器本地真实存在于前端代码可访问的存储里。这本身不是问题但意味着你不能把这个工作台随便部署到公网上让别人用因为任何能打开页面的人都可以从浏览器开发者工具里拿到你配置的 Key。如果你的工作台只给自己用限制为本机访问或者局域网访问风险是可控的。如果你非要部署到公网建议使用短期额度受限的 API Key或者干脆给工作台套一层访问认证但这又违背了零后端的初衷。很多纯前端项目其实默认就是这个定位你一定心里要有数。4.5 长会话带来的卡顿和上下文问题对话越长浏览器内存占用越高这跟纯前端还是后端无关主要是长文本渲染和大模型上下文窗口的物理限制。Lab 这类工作台一般会提供上下文长度限制设置超过限制后自动截断早期消息。我遇到卡顿时一般会手动开一个新会话或者把长会话里的关键结论复制出来存入模板然后清空上下文继续。这个习惯能让你在任何模型工作台里都保持高效。4.6 模型切换后答非所问如果你在一个会话里从 DeepSeek 切换到 Ollama 本地模型发现后面的回答质量骤降不要急着怀疑工作台的问题。大概率是本地模型参数规模太小接不住前面云模型的高复杂度上下文。我现在的做法是把复杂任务分到专用会话里同一个会话内只用同类模型避免因上下文风格混杂带来的效果下降。根据我个人实际使用的体会这类纯前端本地优先工作台最打动我的不是某个花哨功能而是它把主动权完全交还给了用户。你的 API Key 你自己管你的数据在本地你选择哪个模型就直连哪个模型没有任何中间商。如果你也在多个模型平台之间来回切换或者对对话数据的隐私比较敏感真的建议花一个下午把这类工作台搭起来配上 Ollama 和几个云端模型体验一下所有入口统一、数据本地可控的感觉。这个投入绝对值回票价。