最近开发者圈子里被反复刷屏的一个消息就是“腾讯开源了 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 负责模型调用适配、本地命令执行、工具结果回传也就是用户感知不到但任务能不能成全靠它的那一层。项目定位开源状态CodeBuddyAI 编程助手聚焦编辑器场景商业产品不开源WorkBuddy通用 AI 工作台管理会话与技能本次开源Octop本地运行时连接模型、命令和外部服务本次开源实际操作下来我对“工作台和执行器分开”这件事的好感度很高。想接入一个新工具不需要动工作台界面只要在 Octop 层写一个适配器工作台侧声明一下就能用。这套抽象比传统插件系统轻也更好理解。2. 部署环境与硬件选择你的电脑够不够格跑这套 AI 工作台2.1 配置门槛没有想象中高我实际在两台完全不同的机器上验证过。第一台是 16GB 内存的 Mac miniM1 芯片跑默认配置加 Ollama 的 7B 量化模型日常对话和技能调用响应速度可以接受大概 2 到 4 秒出第一个 token。第二台是 32GB 内存的 Ubuntu 服务器没有独立显卡纯 CPU 跑 13B 量化模型速度会慢一些但也能完成离线任务。如果你是那种只想把 WorkBuddy 当客户端的用法后台接云端模型 API那内存压力会小很多8GB 内存的旧电脑也能带得动因为推理计算不发生在本地。但如果想完全本地化内存建议直接按 16GB 起步。有 NVIDIA 显卡会舒服很多6GB 以上显存就能流畅跑 7B 级别的量化模型效果和 CPU 完全是两个体验。我做了一个简单的参考表对号入座即可使用方式最低配置推荐配置只做界面端模型全部走云端 API8GB 内存、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_URLhttp://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 稳定版本 tagOctop 也一样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_MODELollama OLLAMA_BASE_URLhttp://127.0.0.1:11434 WORKBUDDY_MODEL_NAMEqwen2.5:7b WORKBUDDY_STORAGE_DIR./data启动前最好先用 curl 确认 Ollama 是否正常curl http://127.0.0.1:11434/api/tags能看到模型列表说明模型服务没问题。再启动 WorkBuddydocker compose up -d打开浏览器访问工作台地址。如果能看到登录和聊天界面说明 WorkBuddy 和 Octop 之间的最小链路已经通了。3.3 编写第一个 Skill 技能包WorkBuddy 里最有意思的是 Skill 机制。一开始我觉得这不就是插件吗后来发现它的抽象比插件更轻。一个 Skill 就是一个描述文件加一个可执行脚本通过触发词让工作台知道该在什么时候调用它。我写的第一个技能是统计某个文件的字数。在技能目录下建一个word_count文件夹里面放skill.yamlname: 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(encodingutf-8)) except UnicodeDecodeError: pass print(f共统计 {len(files)} 个文件总字数约 {total})然后回到 WorkBuddy 对话框输入“统计字数 目录路径”它会自动识别触发词通过 Octop 在本地执行这个 Python 脚本再把结果返回给你。整个过程不经过任何云端服务。第一次跑通的时候确实有种“原来 AI 也能使唤本地工具”的感觉。3.4 混合路由本地模型和云端模型一起用全本地模型跑起来之后能力天花板还是比较明显。一些复杂逻辑推理或者长文写作7B 模型的表现和云端大模型差距还是有。于是我给它配了一条混合路由简单任务走本地复杂任务走云端。在.env里增加WORKBUDDY_ROUTERsimple WORKBUDDY_ROUTER_MODEL_LOCALqwen2.5:7b WORKBUDDY_ROUTER_MODEL_CLOUDtencent-hunyuan WORKBUDDY_ROUTER_THRESHOLD0.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:11434Skill 无法触发触发词太长或和已有技能冲突把 trigger 换成短英文词例如wc避免口语长句中文显示乱码运行环境不是 UTF-8执行export LANGzh_CN.UTF-8容器里加环境变量LANGC.UTF-8Python 脚本运行报缺包虚拟环境没激活或依赖没装全重新执行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 开始先跑通一个统计目录或者整理文件的小任务再慢慢加复杂度。第一台拿来折腾的机器没必要追求高配置先把链路跑通再考虑升级显卡这样踩坑的成本会低很多。