最近开发者圈子里被反复刷屏的一个消息，就是“腾讯开源了 WorkBuddy？”。我第一眼看到这个标题也有点懵，CodeBuddy 我是熟，WorkBuddy 又是什么？等我把仓库和文档翻了一遍，又在自己电脑上完整跑通之后，才弄明白这事的真正含义：腾讯这次不止开源了一个叫 WorkBuddy 的 AI 工作台界面，还带了一个叫 Octop 的本地运行时。Octop 才是真正把 AI 工作台整体搬回你自己电脑的关键组件。
如果你平时重度依赖 AI 工具写代码、整理文档、跑数据处理，同时又反感在线工作台把数据锁在云端，那这套组合值得你静下心来看完。简单说，WorkBuddy 负责提供聊天、技能管理、任务编排这些看得见的部分，Octop 负责把任务落到本地执行：调用本地模型、跑本地脚本、读写本地文件。两者合在一起，就是一个“数据不出本机、技能随手扩展”的 AI 工作环境。
我前后折腾了两个晚上，中间踩了不少坑，也整理出一些文档里没写的经验。下面这篇文章不是官方教程，就是我完整走一遍从安装到配置、再到运行第一个本地 Agent 任务的过程，顺手把所有坑位和调优方法标出来。如果你也想把 AI 工作台从网页后台搬回自己的电脑，直接照着做就行。
1. WorkBuddy 和 Octop 在解决什么问题：在线 AI 工作台的三个痛点
1.1 为什么大家都在想把 AI 工作台搬回本地
先聊现状。大多数人现在用 AI 工具的方式，无非是打开某个网页，或者在编辑器里装一个代码补全插件。遇到问题就粘贴一段代码问问 AI，让它生成回复，然后复制结果走人。这种模式的好处是开箱即用，坏处也特别明显。
第一个痛点是对话记录被锁在平台里。你在 A 工具里问过的上下文，B 工具完全不知道；想把你和 AI 之间那些有价值的对话整理成知识库，导出功能往往做得很烂，甚至不给导出。第二个痛点是数据不受控。你贴给在线 AI 的代码、文档、业务数据，都要经过别人的服务器，对很多团队来说这不是“信任不信任”的问题，而是合规要求根本不允许。第三个痛点是自动化能力弱。网页聊天框只能聊，不能直接帮你跑本地脚本、批量改文件名、按时拉取数据再生成报告。
WorkBuddy 和 Octop 的组合，本质上是把“聊天框”升级成“工作台”。工作台里有对话、技能列表、任务编排、模型配置、会话历史，而 Octop 负责把这些任务真正落到本机执行。打个比方，WorkBuddy 是驾驶舱，Octop 是发动机和传动系统，两者配合才能把 AI 的想法变成机器上的实际操作。像我这种喜欢把重复工作交给脚本的人，看到这套设计的第一反应就是：终于有个东西能把“聊”和“做”接起来了。
1.2 这个时间点为什么适合本地化部署
前几年说把 AI 工作台搬回本地，很多人会觉得不现实，因为本地跑不动大模型。但现在情况不一样了，本地模型的运行成本已经降到普通开发者能接受的范围。通过 Ollama、llama.cpp 这类工具，16GB 内存的电脑就能跑 7B、13B 参数的量化模型，做文本总结、格式转换、代码补全、简单问答完全够用。虽然能力上限比不过云端的大参数模型，但对日常 80% 的重复性工作已经绰绰有余。
另一件值得注意的事是模型 API 的价格虽然在降，可长期依赖单一供应商的风险始终在。模型供应商一旦调价、限流、调整能力版本，你的整个工作流都会跟着受影响。本地工作台把模型做成了可插拔模块，想换哪家就换哪家，甚至本地和云端混着用。这种“模型无关”的架构，比单纯追求“某一个模型更好用”要长远得多。
1.3 WorkBuddy、Octop 和 CodeBuddy 到底什么关系
聊这套项目之前，得先把名字理清。大家熟悉的 CodeBuddy 是腾讯推出的 AI 编程助手，主要场景在编辑器里，帮你补全代码、解释报错、生成单元测试。而这次开源的 WorkBuddy，定位明显不一样，它更像一个通用 AI 工作台，管理会话、技能、配置、任务编排。你可以理解成 CodeBuddy 是“结对程序员”，WorkBuddy 是“AI 工作台管家”。
Octop 的名字则让人联想到章鱼（Octopus），寓意像触手一样把工作台的任务伸向本地各种工具和服务。从项目文档里的分工来看，WorkBuddy 负责用户直接接触的界面和配置层，Octop 负责模型调用适配、本地命令执行、工具结果回传，也就是用户感知不到但任务能不能成全靠它的那一层。
| 项目 | 定位 | 开源状态 |
|---|---|---|
| CodeBuddy | AI 编程助手，聚焦编辑器场景 | 商业产品，不开源 |
| WorkBuddy | 通用 AI 工作台，管理会话与技能 | 本次开源 |
| Octop | 本地运行时，连接模型、命令和外部服务 | 本次开源 |
实际操作下来，我对“工作台和执行器分开”这件事的好感度很高。想接入一个新工具，不需要动工作台界面，只要在 Octop 层写一个适配器，工作台侧声明一下就能用。这套抽象比传统插件系统轻，也更好理解。
2. 部署环境与硬件选择：你的电脑够不够格跑这套 AI 工作台
2.1 配置门槛没有想象中高
我实际在两台完全不同的机器上验证过。第一台是 16GB 内存的 Mac mini，M1 芯片，跑默认配置加 Ollama 的 7B 量化模型，日常对话和技能调用响应速度可以接受，大概 2 到 4 秒出第一个 token。第二台是 32GB 内存的 Ubuntu 服务器，没有独立显卡，纯 CPU 跑 13B 量化模型，速度会慢一些，但也能完成离线任务。
如果你是那种只想把 WorkBuddy 当客户端的用法，后台接云端模型 API，那内存压力会小很多，8GB 内存的旧电脑也能带得动，因为推理计算不发生在本地。但如果想完全本地化，内存建议直接按 16GB 起步。有 NVIDIA 显卡会舒服很多，6GB 以上显存就能流畅跑 7B 级别的量化模型，效果和 CPU 完全是两个体验。
我做了一个简单的参考表，对号入座即可：
| 使用方式 | 最低配置 | 推荐配置 |
|---|---|---|
| 只做界面端，模型全部走云端 API | 8GB 内存、20GB 磁盘 | 16GB 内存 + SSD |
| 本地跑 7B 量化模型 | 16GB 内存 | 32GB 内存，或 8GB 显存独显 |
| 本地跑 13B 量化模型 | 32GB 内存 | 64GB 内存，或 12GB 显存独显 |
操作系统方面，Linux 最顺，macOS 的 M 系列芯片也没问题。Windows 用户建议优先考虑 WSL2 或者 Docker Desktop，别直接在 PowerShell 里硬刚，很多依赖在纯 Windows 环境下会踩到路径和大小写的坑。
2.2 动手前先把这几样工具装齐
部署之前把基础环境配好，能省掉后面一大半的折腾时间。我的建议清单如下：
- Git：拉取代码和切换版本用。
- Docker：官方推荐的部署方式是容器化，用 Docker Compose 管理 WorkBuddy 和 Octop 服务。
- Python 3.10 以上：Octop 的适配器和 Skill 脚本大多依赖 Python。
- Node.js 18 以上：WorkBuddy 的前端调试和本地开发服务会用到。
- Ollama（可选）：如果要跑本地模型，这是目前最省事的模型运行时工具。
这里特别提醒一下版本问题。Node 版本如果低于 18，依赖安装阶段会直接报错；Python 用系统自带的老版本也容易缺包。为了避免环境问题干扰后续体验，建议在项目目录里建一个独立的 Python 虚拟环境再开始安装。
2.3 Docker 还是裸机跑，我的选择
官方给的部署方式我更推荐用 Docker Compose，因为依赖隔离做得干净。Octop 要调用的 Python 包非常多，如果直接裸机装在系统里，很容易和你自己项目的包产生版本冲突。我之前图省事直接裸机跑，结果一个 YAML 解析库的版本和别人冲突，排查了半天才意识到问题。
但容器方案也有一个让新手头疼的地方：Octop 要调用宿主机命令、读写本地文件，容器默认隔离环境会把这些能力都封住。所以用 Docker 部署时，一定要把需要操作的工作目录和模型服务地址挂载进容器。我记得第一次跑的时候忘了把 Ollama 的地址映射进去，模型调用一直失败，看日志才发现是容器里访问不到宿主机。
一个简化版 docker-compose 配置大概是这个样子：
services: workbuddy: image: workbuddy:latest ports: - "8080:8080" volumes: - ./data:/data environment: - WORKBUDDY_STORAGE_DIR=/data - OLLAMA_BASE_URL=http://host.docker.internal:11434 extra_hosts: - "host.docker.internal:host-gateway"里面extra_hosts那一行作用很大，它让容器可以通过host.docker.internal这个固定域名访问宿主机上的 Ollama 服务。如果你不用 Docker，而是选择裸机运行，那就少这层映射问题，但要多花点精力维护 Python 依赖。
3. 实操记录：5 步把 WorkBuddy 和 Octop 跑起来
3.1 拉取代码并锁定稳定版本
WorkBuddy 刚开源那两天仓库更新很频繁，我的习惯是别直接用 main 分支部署，因为 main 上随时可能有未稳定提交。先到仓库主页找到最新 release 对应的 tag，再执行拉取：
git clone <workbuddy 仓库地址> workbuddy cd workbuddy git tag -l git checkout <稳定版本 tag>Octop 也一样：
git clone <octop 仓库地址> octop cd octop python -m venv .venv source .venv/bin/activate pip install -r requirements.txt如果你在拉取代码或安装依赖时速度不理想，先检查网络和镜像源配置。Git 仓库、包管理器和 Docker 都可以配置镜像源，这是社区里最常用的办法，我这里不展开。需要注意的是一旦修改了镜像配置，记得确认配置生效后再重试。
3.2 配置本地模型接口并启动系统
为了先跑通整条链路，我建议直接用 Ollama 拉一个 qwen2.5:7b，中文支持好，模型文件大小也适中。启动 Ollama 之后，先拉取模型：
ollama pull qwen2.5:7b ollama serve接下来到 WorkBuddy 的部署目录里，把环境变量模板复制一份：
cp .env.example .env打开.env文件，填入下面的内容：
WORKBUDDY_MODEL=ollama OLLAMA_BASE_URL=http://127.0.0.1:11434 WORKBUDDY_MODEL_NAME=qwen2.5:7b WORKBUDDY_STORAGE_DIR=./data启动前最好先用 curl 确认 Ollama 是否正常：
curl http://127.0.0.1:11434/api/tags能看到模型列表，说明模型服务没问题。再启动 WorkBuddy：
docker compose up -d打开浏览器访问工作台地址。如果能看到登录和聊天界面，说明 WorkBuddy 和 Octop 之间的最小链路已经通了。
3.3 编写第一个 Skill 技能包
WorkBuddy 里最有意思的是 Skill 机制。一开始我觉得这不就是插件吗，后来发现它的抽象比插件更轻。一个 Skill 就是一个描述文件加一个可执行脚本，通过触发词让工作台知道该在什么时候调用它。
我写的第一个技能是统计某个文件的字数。在技能目录下建一个word_count文件夹，里面放skill.yaml：
name: word_count description: 统计指定文本文件或目录的总字数并输出结果 trigger: 统计字数 script: scripts/word_count.py再建一个scripts/word_count.py：
#!/usr/bin/env python3 import sys, pathlib path = pathlib.Path(sys.argv[1]) if path.is_dir(): files = list(path.rglob("*")) else: files = [path] total = 0 for f in files: if f.suffix.lower() in {".txt", ".md", ".py", ".js", ".json"}: try: total += len(f.read_text(encoding="utf-8")) except UnicodeDecodeError: pass print(f"共统计 {len(files)} 个文件，总字数约 {total}")然后回到 WorkBuddy 对话框输入“统计字数 + 目录路径”，它会自动识别触发词，通过 Octop 在本地执行这个 Python 脚本，再把结果返回给你。整个过程不经过任何云端服务。第一次跑通的时候确实有种“原来 AI 也能使唤本地工具”的感觉。
3.4 混合路由：本地模型和云端模型一起用
全本地模型跑起来之后，能力天花板还是比较明显。一些复杂逻辑推理或者长文写作，7B 模型的表现和云端大模型差距还是有。于是我给它配了一条混合路由：简单任务走本地，复杂任务走云端。
在.env里增加：
WORKBUDDY_ROUTER=simple WORKBUDDY_ROUTER_MODEL_LOCAL=qwen2.5:7b WORKBUDDY_ROUTER_MODEL_CLOUD=tencent-hunyuan WORKBUDDY_ROUTER_THRESHOLD=0.6这个配置并不是特别精确，对个人使用足够了。它的思路是给任务打一个置信度分数，分数低就本地处理，分数高则交给云端模型。需要提醒一句，一旦接了云端 API，涉及这些请求的数据仍然会发到云服务商，不要想当然地认为本地工作台就等于所有数据都不出本地。需要严格隐私隔离的场景，请只保留本地模型。
4. 上手一周后的真实感受：这套组合的三个亮点和一块短板
4.1 数据留在本地的控制感，比想象中值钱
我自己的工作习惯是每个项目一个目录，WorkBuddy 支持把会话记录和文件索引都存到本地目录。配置了WORKBUDDY_STORAGE_DIR之后，所有对话记录都会以文件形式落在磁盘上。我顺手把这个数据目录做成了一个 Git 仓库，每天自动提交一次。这样做的好处是换机器可以完整迁移，回溯历史记录也方便，直接翻文件就能看到当时的上下文，不用去某个后台点导出。
这种感觉很像以前用在线文档，数据看似随时可访问，其实是“借”来的。一旦平台调整、账号异常，内容就可能找不回来。本地工作台至少让我对自己的数据保留完整控制权。回到一句话：你的电脑，你的数据，你的规则。
4.2 界面和执行器分离，任务编排变得很自由
WorkBuddy 和 Octop 拆成两层设计，刚开始我觉得有点多此一举，实际用下来才发现这是整套项目最值得借鉴的地方。工作台不需要关心每个工具怎么实现，只需要通过 Octop 调用；Octop 也可以脱离 WorkBuddy 单独被其他程序驱动。这意味着想接内部脚本，不必把逻辑写进界面，只要给 Octop 写一个适配器就行。
我实际搭过一个稍微完整点的流程：让 AI 扫描指定目录下的日报文件，提取关键指标生成摘要，再把摘要写入一个新的 Markdown 文件。整个过程没有写死逻辑，每一步都是独立技能，在 WorkBuddy 里通过对话自然组合触发。以前我要实现类似功能，得写一大堆脚本调度逻辑，现在只要维护各自的 Skill 就行，改动一处不影响其他部分。
4.3 生态和文档还处在非常早期，别指望开箱即用
好话说了不少，短板也得提。目前这套项目给我的感觉是“框架感”很强，但离“成熟产品”还有距离。文档写得很散，Skill 的规格在不同示例里甚至不完全一致；官方示例数量少，社区讨论也才刚刚开始。新手照着文档想一键搭好，大概率会卡在某个细节上。
仓库更新快也是把双刃剑。今天能用的配置，过几天拉一次更新可能就变了。我的应对方法是：部署时固定一个 release tag，不追 main 分支；每次更新前先看 changelog 和 issue，确认没有破坏性变更再升级。等社区生态起来之后再跟着主流走也不迟。
5. 常见问题排查与调优速查：踩坑记录全公开
5.1 我踩得最狠的六个坑
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
| docker compose 直接起不来 | 端口被占用 | 检查 8080、11434 等端口，修改 .env 对应绑定项 |
| 能打开界面但对话一直在转圈 | 模型服务地址不对 | 先 curl 模型服务地址，确认宿主机能访问 |
| 提示找不到 Ollama | 容器里访问不到宿主机 | 配置extra_hosts: "host.docker.internal:host-gateway"，再用http://host.docker.internal:11434 |
| Skill 无法触发 | 触发词太长或和已有技能冲突 | 把 trigger 换成短英文词，例如wc，避免口语长句 |
| 中文显示乱码 | 运行环境不是 UTF-8 | 执行export LANG=zh_CN.UTF-8，容器里加环境变量LANG=C.UTF-8 |
| Python 脚本运行报缺包 | 虚拟环境没激活或依赖没装全 | 重新执行pip install -r requirements.txt，确认当前用的是.venv解释器 |
这些坑大多不复杂，但每一个都足够让人卡上半小时。建议先把日志打开再看现象，WorkBuddy 和 Octop 的日志都会打印错误原因，比瞎猜高效得多。
5.2 从“能跑”到“好用”的几个调优技巧
第一，控制生成参数。写代码、整理数据类的技能，把 temperature 调到 0.2 以下，输出会稳定很多；做文案、创意类内容时再调回 0.7 左右。第二，本地模型优先选择量化版本，同样 7B 模型，Q4_K_M 量化比 FP16 省一半以上内存，响应速度提升明显，质量下降几乎感知不到。第三，给常用 Skill 设置好默认参数，避免每次都在对话里重复描述路径。WorkBuddy 支持在描述文件里声明默认参数，虽然配置时麻烦一点，但长期使用会顺手很多。
5.3 一个关于 Skill 安全和权限的提醒
本地工作台能调用本地命令，这既是优势也是风险。不安全的 Skill 等于给 AI 开了一个本机执行后门。我强烈建议做好三件事：第一，用低权限用户运行 Octop，不要直接给 root 或管理员权限；第二，限制 Skill 脚本能访问的文件路径，别让一个统计字数的脚本顺手读取你的私钥；第三，不要在任何配置里写死云端 API 密钥，通过环境变量注入，并把.env加入.gitignore。
我的习惯是给 Octop 单独建一个workbuddy-agent系统用户，这个用户只能访问指定工作目录。麻烦是麻烦一点，但至少不会出现某个 Skill 意外扫描整个家目录的情况。这类本地编排工具以后会越来越多，权限意识现在就要建立起来。
我自己折腾了几天之后最大的体会是，WorkBuddy 和 Octop 的价值不在于某个模型有多强，而是把 AI 工具的工作形态从“网页后台”拉回到了“本地工作环境”。日常那些重复性操作终于能在一个界面里统一调度，会话记录也能跟着自己的笔记仓库走。如果你也想试试这种自己掌控 AI 工作流的感觉，我建议从最简单的 Skill 开始，先跑通一个统计目录或者整理文件的小任务，再慢慢加复杂度。第一台拿来折腾的机器没必要追求高配置，先把链路跑通，再考虑升级显卡，这样踩坑的成本会低很多。
