直接在博文开头讨论腾讯开源的 Octop 项目，把它定位成连接 AI 工作台和本地模型的中间层。顺着“为什么要把工作台搬回本地”这条线展开，讲清楚架构、实操配置、模型选择、踩坑记录，最后再聊几句更进阶的玩法。整体尽量口语化，像同行之间交流经验那样写。
1. 为什么要把 AI 工作台搬回自己电脑
1.1 云端助手讲过的三个故事，如今都有点尴尬
过去两年，各家 AI 编程助手的故事都差不多：你在 IDE 里装个插件，它把你的代码、注释、上下文统统传到云端，然后一个“比你更懂你代码”的大模型帮你补全、解释、改 bug。这个故事有三个前提：你的代码可以出网、你的数据值得信任云端、供应商的模型永远够聪明。三个前提在个人开发者和小团队场景里往往都不成立。
先说数据。还没上线的项目、甲方合同相关的代码、内部工具脚本，这些东西你真的敢一股脑塞给云端吗？很多公司明文规定代码不允许上传第三方服务。个人开发者虽然没那么多条条框框，但“我本地跑得好好的模型，凭什么要让别人看我的代码”这种直觉也很真实。
再说成本。云端助手按席位收费，一年下来也不少。而且不管你这个月写不写代码，钱照扣。本地模型不一样，硬件是自己的，电费几块钱，模型权重是开源免费的，唯一要付出的就是折腾时间。对于我这种常年折腾开源项目的人来说，这笔账非常好算。
最后是模型选择问题。云端给你什么模型你就得用什么模型，升级降级都是人家说了算。我想用 Qwen 试试，想用 DeepSeek 试试，想用 7B 模型追求极速响应，或者用 32B 模型换点智商，云端助手能满足吗？基本不能。
1.2 本地优先的三根支柱：隐私、成本、模型自由
所以“本地优先”这个词这两年越来越热，不是没有道理。它不是要你跟云端彻底决裂，而是把选择权拿回来。本地优先的三根支柱，我理解是这样：
隐私：代码不出本机，日志不出内网，模型在自己的 GPU 上跑。你写什么、改了什么都只有你自己知道。对于写内部工具、研究性代码、或者只是不想被“记录习惯”的人来说，这一条就是最大的吸引力。
成本：一次硬件投入，长期零边际成本。云端按 token 计费也好，按席位计费也好，用得越多越心疼。本地模型虽然前期要买显卡或者租一台带 GPU 的机器，但跑起来之后，每多问一个问题，成本几乎为零。
模型自由：今天试 Qwen2.5-Coder，明天换 DeepSeek-Coder，后天想试试 Llama，就是一个命令的事。哪个模型在当前任务上表现好就用哪个，还可以同时跑多个模型做对比。这种“模型自由”虽然听起来不如“最强模型”酷，但实际用起来会发现它非常实在，因为你总能找到一个合适尺寸的模型匹配当下的硬件和任务。
这三根支柱立住了，剩下的问题就变成了：我熟悉的 AI 编程助手界面，能不能接上本地模型？于是 Octop 出现了。
2. Octop：在 IDE 和本地模型之间做“翻译官”
2.1 它到底解决了什么痛点
腾讯开源的这个 Octop，名字挺有意思，像章鱼，触手很多，什么都能接。它解决的问题其实非常具体：那些 AI 工作台、编程助手，默认只跟官方云端服务通信，我不想要云端，但我想继续用它的界面和交互。
拿 WorkBuddy 来说，它是腾讯生态里的 AI 工作台产品，跟 CodeBuddy 同源，核心能力是代码补全、对话、任务执行这些。这类产品的默认配置是连官方云端 API，你在配置里填一个 API Key 就能用。但如果你想把模型换成自己电脑上的 Qwen，配置界面里根本没有这个选项，因为它压根没打算让你这么干。
Octop 就是来打破这个局面的中间层。它在你本地跑一个代理服务，伪装成 OpenAI 兼容的 API 接口。WorkBuddy 以为自己还是在跟云端说话，实际上请求被 Octop 接收，然后转发到你指定的本地推理后端，比如 Ollama、LM Studio、vLLM 这些。请求路径是这样的：
WorkBuddy (IDE) → Octop (本地网关) → Ollama/vLLM → 本地模型这个设计妙在哪？它不要求 WorkBuddy 做任何改造，只要你把 API 地址改成 localhost 上的一个端口，把密钥改成任意字符串，剩下的事情 Octop 全包了。也就是说，你不用等腾讯官方给你加本地模型支持，你自己就能搞定。
2.2 架构和请求流，一次说清楚
Octop 的架构如果画成图，就是中间一个网关方块，左边是各种 AI 工作台客户端，右边是各种推理后端。它做的事情其实就是四件事：接请求、认身份、选路由、转发响应。
- 接请求：监听一个本地端口，暴露 OpenAI 格式的
/v1/chat/completions、/v1/completions这类接口。 - 认身份：校验客户端传过来的 API Key，这一步主要是让流程走通，并不真的验证什么，你配置里写什么，客户端就得填什么。
- 选路由：根据客户端请求里的模型名或者配置里的映射关系，决定转发到哪个后端。比如请求里写
model: qwen2.5-coder-7b，就转到 Ollama；写model: deepseek-32b，就转到 vLLM。 - 转发响应：把后端的输出翻译回 OpenAI 格式，原样返回给客户端。
中间还可以插很多层逻辑，比如记录日志、统计 token 消耗、限制特定模型只允许特定用户访问。这些能力对个人用没啥感觉，但放到团队里就是刚需了。
2.3 兼容层：为什么 OpenAI 格式是行业的“普通话”
你可能想问，为什么非得是 OpenAI 兼容格式？因为现在市面上几乎所有大模型推理服务都在兼容 OpenAI 的 API 协议。这个协议事实上成了 AI 领域的“普通话”，大家都会说，大家也都听得懂。
对 Octop 来说，选 OpenAI 格式做兼容层成本最低。WorkBuddy 不用改，Ollama 原生支持 OpenAI 兼容接口，vLLM 也支持，连 LM Studio 都支持。大家都在说同一种语言，中间只需要一个会“接话茬”的人，这就是 Octop 的角色。
这个选择背后还有个更深层的好处：以后无论出了什么新的 AI 工作台，只要它支持自定义 OpenAI API 地址，就能用 Octop 接到本地模型上。你今天的配置，明天换了新工具大概率还能用。这种投资是能复利的。
3. 实操：从零把 WorkBuddy 接到本地模型上
3.1 环境准备与后端选型
先说硬件底线。如果你只跑 7B 级别的量化模型，8GB 显存的显卡就能跑得不错，16GB 内存的纯 CPU 机器也能凑合，但速度会惨不忍睹。想跑 32B 级别模型，建议至少 24GB 显存，或者用多张显卡拼起来。我个人测试下来，Qwen2.5-Coder-7B 这个尺寸在代码补全和简单问答上已经完全可用了，32B 版本适合处理复杂的重构和跨文件分析。
后端选型，我的建议是：
| 场景 | 推荐后端 | 理由 |
|---|---|---|
| 个人电脑快速体验 | Ollama | 安装简单，命令直观，模型管理方便 |
| 有显卡的本地服务器 | vLLM | 吞吐量高，支持并发请求，适合多人使用 |
| Windows 图形界面控 | LM Studio | 鼠标点一点就能下载模型，不用敲命令 |
| 需要跟现有 Python 生态集成 | SGLang / vLLM | API 标准化好，定制空间大 |
我第一次搭的时候选了 Ollama，因为它最省心。下载安装之后一行命令拉模型，再一行命令起服务，基本没有学习成本。
3.2 Octop 安装与配置
Octop 的安装有两种方式，一种是用预编译的二进制文件，一种是从源码构建。我个人建议直接用二进制，省时间，除非你要改源码。
Linux/macOS 下用 Homebrew 可以一条命令装好。Windows 用户到项目 Release 页面下载对应压缩包，解压之后把可执行文件路径加进 PATH 就行。
装好之后，核心是一个配置文件。Octop 的配置思路是：你定义多个上游后端，然后给每个后端绑定一个模型名。客户端请求model=某个名字时，Octop 就知道该转给谁。大致长这样：
providers: - name: ollama type: ollama api_base: http://localhost:11434/v1 api_key: ollama - name: vllm-server type: openai-compatible api_base: http://192.168.1.20:8000/v1 api_key: vllm-key models: - name: qwen2.5-coder-7b provider: ollama - name: deepseek-coder-33b provider: vllm-server server: port: 8118 api_key: workbuddy-local-key这里注意几个细节。server.api_key是给 WorkBuddy 填的密钥，你可以随便写一个，只要客户端和服务端对得上就行。模型名要跟 WorkBuddy 里配置的模型名一致，大小写敏感。api_base指向后端服务的地址，Ollama 默认是 11434 端口，vLLM 默认是 8000 端口。
配好之后启动服务：
octop --config ./config.yaml看到日志里输出监听0.0.0.0:8118就说明成功了。顺手用 curl 验证一下：
curl http://localhost:8118/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer workbuddy-local-key" \ -d '{ "model": "qwen2.5-coder-7b", "messages": [{"role": "user", "content": "用 Python 写一个快速排序"}] }'能收到正常响应，说明 Octop 到后端模型的链路已经通了。
3.3 在 WorkBuddy 里指向本地服务
WorkBuddy 这边的配置就简单了。打开设置，找到模型供应商或者自定义端点的地方，把 Base URL 填成http://localhost:8118/v1，API Key 填配置里写的workbuddy-local-key，模型名填qwen2.5-coder-7b。
这里提醒一句：不同版本的 WorkBuddy 配置入口位置可能不一样，有的叫“自定义模型”，有的叫“OpenAI 兼容端点”，多翻翻设置页，一般都在 AI 模型相关的区域。填完之后保存，新建一个会话试试，如果能看到模型开始流式输出，那就大功告成了。
我第一次配置的时候卡在了一个很蠢的地方：把 Base URL 填成了http://localhost:8118，少了/v1后缀。WorkBuddy 实际请求的路径是/v1/chat/completions，而 Octop 的/v1路由是挂在根路径下面的，少了这部分直接 404。这个坑大概率很多人会踩，后面排查部分再细说。
3.4 模型选择与配参经验
模型选型这事，我给三条经验。
第一条，先小后大。刚搭好的时候不要直接上 32B 模型，先用 7B 或 14B 把链路跑通，确认 Octop、WorkBuddy、后端三者的兼容性没问题，再换大模型。否则你排查半天都不确定是链路问题还是模型能力问题。
第二条，量化等级要匹配显存。Ollama 里下载模型的时候会默认选一个量化版本，比如 Q4_K_M。如果你的显存还有富余，可以试试 Q6 甚至 Q8，代码生成的准确率会有一点点提升。但显存不够的话强行上高量化会导致上下文缩短甚至直接 OOM，得不偿失。
第三条，代码任务优先选 Code 系列模型。通用模型对话能力强，但代码补全和结构化生成方面，代码专用模型优势明显。Qwen2.5-Coder、DeepSeek-Coder 这些都是经过代码语料专门训练的，日常写代码体验好很多。
我在实际使用中最顺手的组合是：日常补全用 7B 量化模型，延迟低、不打断思路；复杂重构或者需要跨文件理解的对话，手动切到 32B 模型，虽然慢一点，但分析结果明显更靠谱。
4. 常见问题与排查实录
4.1 我踩过的坑和解决方式
搭这套环境的过程中，我踩过的坑也不少，挑几个典型的说说。
第一个坑是连接被拒绝。WorkBuddy 里配好地址之后，怎么调都提示连不上。排查半天发现是 Octop 启动的时候只监听了127.0.0.1，而 WorkBuddy 插件跑在 WSL 里，访问不到 Windows 宿主机上的服务。解决办法很简单，把 Octop 的监听地址改成0.0.0.0，让所有本机接口都能访问。
第二个坑是模型名字写错。Ollama 里下载的模型全名很长，比如qwen2.5-coder:7b-instruct-q4_K_M，如果你在 Octop 配置里写的模型名跟真实的 tag 完全对不上，后端会直接报模型不存在。我的习惯是先把 Ollama 的ollama list结果复制出来，对着模型全名写配置。
第三个坑更隐蔽，是上下文溢出。7B 模型默认上下文长度有限，我一开始没限制 WorkBuddy 发送的上下文长度，遇到大文件的时候模型直接报错，日志里出现 context length exceeded。解决办法：在 WorkBuddy 里把上下文长度调小一点，或者在 Octop 转发的时候限制输入的最大 token 数。毕竟本地模型的 KV Cache 是吃显存的，上下文越长，显存占用越高，也越容易出问题。
4.2 一张问题速查表
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| 请求 404 | Base URL 少写了/v1 | 检查 WorkBuddy 端点地址是否以/v1结尾 |
| 连接被拒绝 | 端口没监听或地址绑定不对 | 查看 Octop 日志，确认监听地址，必要时改0.0.0.0 |
| 模型不存在 | 模型名跟后端实际 tag 不一致 | 用ollama list核对完整模型名 |
| 输出断断续续 | 上下文溢出或显存不足 | 降低上下文长度、换更小量化模型 |
| 响应极慢 | 模型在 CPU 上跑或者后端排队 | 检查后端日志，确认是否启用了 GPU 加速 |
| WorkBuddy 报鉴权失败 | API Key 跟 Octop 配置不一致 | 对比 WorkBuddy 和 Octop 配置中的密钥 |
这六个问题覆盖了九成以上的故障场景。我的经验是，遇到问题第一时间看 Octop 的日志，日志里会把请求转发到哪个后端、后端返回了什么状态码都打出来，比在 WorkBuddy 里瞎猜高效太多。
4.3 延迟、上下文与性价比的实测认知
用了一段时间以后，我对本地模型的性能边界有了比较具体的认知。7B 量化模型在 4080 级别显卡上，代码补全的响应延迟大概是 300 到 800 毫秒，这个速度对交互式补全来说是可以接受的。32B 模型延迟会增加到 3 到 8 秒，适合对话式分析，不适合逐字补全。
上下文长度是另一个影响体验的重要因素。默认情况下，7B 模型用 8K 上下文，32B 模型可能撑到 32K。但实际使用中，上下文越长，首 token 延迟越高。原因很简单，模型需要重新处理前面所有的 token。所以我一般建议把 WorkBuddy 的自动上下文设置关掉，手动控制发送给模型的代码量，这样既省显存又提速。
性价比方面，本地模型的优势主要在长期、高频使用场景。如果你一天要问上百次 AI，云端按 token 计费的话是一笔不小的开销，本地模型跑得再慢也是自己的机器在算。但如果只是偶尔用一用，云端助手反而更方便，不用管硬件和配置。这个取舍没有绝对答案，看个人使用频率。
5. 一些更进阶的玩法
5.1 局域网统一推理服务器
如果你有多台电脑，可以考虑配一台专门的推理服务器放局域网里。服务器装 vLLM 或者带多张显卡的 Ollama，笔记本和工作站上都装 WorkBuddy，API 地址指向服务器的 IP。Octop 统一挂在服务器上，所有客户端的请求都走同一套配置。
这样做的好处有三个：模型只部署一份，配置只维护一份，贵显卡只买一张。我实际搭过用一台 4090 机器带三台开发机，每人分到 12GB 显存左右的独立算力，体验完全够用。比每台机器都配显卡省钱多了。
5.2 多模型路由与 A/B 测试
Octop 支持多个模型路由，这意味着你可以把同一个工作台同时接到多个模型上。比如配置两个模型，一个叫qwen-coder-7b，一个叫deepseek-coder-33b，在 WorkBuddy 里随时切换。
这个玩法在模型评测的时候特别有用。我以前对比模型都是开两个窗口，手动复制代码和结果，来回切换很痛苦。现在直接在 WorkBuddy 里切换模型，同样的提示词发给不同模型，输出能直接对比，效率高很多。
5.3 团队共享与隔离策略
最后说一说团队场景。虽然 Octop 本身是给个人用的工具，但它的架构天然支持多人共享。把 Octop 部署在服务器上，多个团队成员通过 WorkBuddy 连上来，共用同一批模型。敏感一点的团队可以在配置里加一层简单的鉴权，每个成员用不同的 API Key，Octop 在日志里能区分每个 key 的请求来源。
数据隔离这块，本地部署最大的优势就是所有代码和提示词都留在内网，不需要经过任何外部服务。团队内部可以把 Octop 当成一个私有化的 AI 网关，把数据边界牢牢控制在组织内部。
我个人在实际操作中的体会是，这套方案最打动人的地方不是某一个技术点，而是那种“所有东西都在自己掌控中”的感觉。模型是我挑的、硬件是我跑的、配置是我改的，出了问题我能看日志、能调参数、能换后端，而不是只能提工单等回复。如果你也是喜欢折腾的人，Octop 这条路值得走一遍，把 AI 工作台搬回自己电脑之后，你会发现原来那些被封装好的黑盒，其实都挺简单的。
