朋友昨天问了我一个很有意思的问题听说腾讯把 WorkBuddy 开源了叫 Octop我当时就纠正了他一下——腾讯真正放出来的开源项目是 Octop你可以把它理解成一个自托管的 AI 工作台把 CodeBuddy 里 WorkBuddy 那套“让 AI 按你的流程干活”的体验拆成了能装到自己电脑上的底座。装上它之后AI 就不是网页里那个只能聊天的对话框了而是一个住在你本机的 Agent 工作台能读你指定的文件执行你写的技能按你定的全局规则调度模型。这篇文章适合谁想认真用 AI 干活又不放心数据隐私的开发者、想低成本跑 Agent 实验的个人用户以及嫌云端工作台不够可控的小团队。我会从 Octop 的定位讲起把架构逻辑、部署过程、第一个技能怎么跑通完整写给你看。1. 先搞清楚Octop 和 WorkBuddy 到底是什么关系1.1 Octop 不是“WorkBuddy 的替代品”是它的自托管底座先说结论腾讯开源的这个 Octop和网上很多人吵的“WorkBuddy”不是一回事但关系又很紧密。WorkBuddy 是 CodeBuddy 里那种 AI 工作台体验——你可以把它当作一个装了大脑和工具的操作系统AI 在里面不是单纯回答问题而是按你交代的任务拆步骤、调工具、写文件、给结果。而 Octop 是腾讯把这个方向上的能力开源出来让任何人都能自己部署一套类似的工作台。换句话说WorkBuddy 是产品形态Octop 是开源底座。为什么要把这两件事分开看因为很多读者一听到“腾讯开源了 WorkBuddy”就以为能装个完整客户端、登录账号直接用。实际上自托管项目的玩法恰好相反你拿到的不是成品软件而是一个框架、一组建模方式、一套技能定义规范。你要做的是把自己的需求填进去。这就像你买了一套精装房的图纸而不是直接领钥匙入住。Octop 的目标就是让你自己当“装修工”决定哪个房间放模型、哪个房间放工具、哪个房间放数据。1.2 它解决的三个核心痛点数据、技能、模型我上手 Octop 的第一感受是它没有重复造“ChatGPT 网页版”的轮子而是瞄准了 AI 落地到真实工作流里最让人头疼的三件事。第一是数据归属。用云端 AI 工作台你的代码、数据库结构、内部文档全都得传到别人服务器上。业务没跑起来还好真到了生产环节这一步心理门槛极高。自托管最大的优势就是所有对话记录、生成文件、技能定义都留在你自己机器上。第二是技能沉淀。Octop 里的“技能”不是简单的提示词模板而是可复用、可版本化、可分享的工作流单元。你写一个“分析日志并总结错误”的技能之后每次都能调用还能分享给同事。这在云端产品里往往被做成付费功能在 Octop 里就是你目录下的一个 YAML 文件。第三是模型选择权。自托管工作台天然支持你换模型本地跑一个开源模型、接任何 OpenAI 兼容接口、甚至未来出更好的模型后一键切换。你不需要等平台方适配因为底座就是你自己搭的。所以适合谁来用这个问题我的答案是只要你对“AI 怎么介入自己的工作”有想法而不是只想“AI 帮我聊个天”Octop 就值得你花一个下午折腾。2. 为什么要把 AI 工作台搬回自己的电脑2.1 数据所有权我不愿意把业务文件全交给云端这是我把工作台搬回本机的第一动机。你想象一个场景你手上有几十份客户沟通记录想用 AI 做月度复盘总结你负责的模块有几千行日志想让 AI 帮你找异常规律你电脑里还存着一堆团队成员写的文档想让 AI 按项目维度整理成周报。这些东西要发给云端 AI你能接受吗我第一次试云端 AI 工作台时也有点犹豫后来干脆给自己定了条规矩凡是涉及客户信息、内部代码、未公开文档的任务一律只在本地跑。Octop 这种自托管方案模型调用和数据处理都在你自己的机器上完成工作区默认路径就在你指定目录里。AI 想访问文件要走你给的权限想执行命令要在你定好的规则范围内所有中间产物都落盘在本地。对个人开发者来说相当于给自己的 AI 工作台上了一把物理锁。2.2 自托管带来的真实自由度换模型就像换插头云端工作台的模型是平台方决定的它给什么你就用什么。很多人吐槽的“今天模型变笨了”“上下文被截断”“敏感内容的审核规则突然变了”本质都是你没有控制权。自托管之后你的模型接入层是自己配的Octop 按 OpenAI 兼容接口的方式来抽象模型服务——这意味着你可以接本地跑的模型也可以接第三方 API或者将来转到任何支持 OpenAI 兼容协议的服务。我实测下来的体验是换模型真的就是改几行配置。今天我想省钱把模型指向本地 Ollama 里的量化模型明天有个任务需要更强推理能力我改成云端大模型。工作台本身不用动技能不用重新写对话历史理论上也能继续承载。这种“换插头”的自由度在云端产品里几乎不可能给你。还有一个隐蔽的好处本地模型跑数据每次请求的延迟虽然高一点但你不再心疼 token 费用实验成本直接归零。2.3 成本账自托管到底贵不贵很多人一听“自托管”就劝退觉得要买显卡、要组服务器。其实分场景算账会更清楚。先说最省钱的情况你已经有普通电脑16G 内存只做文本类 Agent 任务不跑本地大模型所有模型调用走 API。这种情况下Octop 本身的运行开销非常小电费可以忽略真正付费的就是 API token 钱。再说進阶情况你想完全本地推理拉一个 7B 参数左右的量化模型比如 Qwen 系列内存占用大概 6-10G普通游戏本能跑只是速度慢一些。最后是“重度玩家”场景想跑几十亿参数以上的模型那就得上推理服务器或者云端租卡这个成本取决于你多认真。我把两种模式放在一起对比过对比项云端 AI 工作台自托管 Octop数据存放位置第三方服务器本机/内网模型选择平台预设任意 OpenAI 兼容服务技能/规则定义受产品功能限制文件级可编辑、可版本管理初始成本订阅费或 token 费无软件费需要一点运维耐心长期成本高活跃场景下费用曲线陡主要看模型调用方式和硬件对于开发者来说Octop 不是替你省钱而是让你把钱花在“该花的地方”在本地跑流程按需调用模型而不是为平台的一揽子功能付费。3. Octop 的核心机制技能、Agent 调度与工具接入3.1 先理解“技能”它就像一个给 Agent 的操作说明书Octop 里最核心的概念叫技能Skill。不少第一次接触的人会把它和“提示词模板”搞混其实差别很大。提示词模板只是给模型的输入文本而技能是一份结构化定义它告诉 Agent“这个任务叫什么、在什么情况下触发、需要哪些输入、执行步骤是什么、最后期望什么样的输出”。你可以把技能理解成给 Agent 的操作说明书。现实里你带实习生不会只说“帮我处理一下日志”你会告诉他打开哪个文件、找什么关键字、统计出什么结果、按什么格式汇报。技能就是这份口语化说明的结构化版本。比如一个“分析日志错误”的技能至少应该包含技能名称analyze_log、技能描述用于读取指定日志文件并总结错误、输入参数file_path、执行提示怎么读文件、统计什么、输出什么格式。Octop 的 Agent 在干活之前会先看看你的需求再去匹配技能列表——如果技能描述写得清楚它就能自动调用如果描述太模糊Agent 就可能瞎猜结果就是“技能写了但没被触发”。这是我实践中遇到最多的坑后面会细说。3.2 Agent 的“规划-调用-反馈”闭环光有技能还不够Octop 的调度核心是一个 Agent 规划器。它的工作方式很像现实里的项目负责人收到你的任务后先拆解需要几步判断每一步该用哪个技能、要不要读文件、要不要写结果然后一步步执行执行完把中间结果做汇总。这个闭环大致分成四层规划plan、调用call、观察observe、总结conclude。通俗说就是Agent 先想好怎么做然后调用具体工具或技能做完看结果是否合理——不合理就换个思路合理了就整理成最终答案。这个机制的好处是你不用把每个任务的完整流程都写在一次提示里只要把技能准备好Agent 自己会像流水线一样把它们串起来。我第一次在 Octop 里跑通这个闭环时不自觉想起当年带新人的经验你给一份清清楚楚的 SOP他就能独立处理七成任务剩下三成不确定的他会拿着中间结果回来问你。Octop 就是这个“较真的新人”而技能是让这个新人靠谱的关键。3.3 工具接入把外部能力挂到工作台上Octop 的另一个让我觉得值得关注的点是它怎么接外部工具。现在的 Agent 框架基本都围绕 MCP 这类标准化协议来打通工具层Octop 也不例外。你可以把 MCP 理解为 AI 世界的“USB-C 接口”以前每个工具都要单独定制连接线现在大家统一接口标准插上就能用。常见的挂载工具包括本地文件系统读写、网络请求、数据库查询、文档检索等。拿我写文档的场景举例我可以给 Octop 挂一个“知识库检索”工具当工作台遇到不了解的术语时会自动检索我的笔记目录而不是凭空编造。这一步对“让 AI 在专业领域不那么蠢”非常关键——因为模型训练数据里显然不会有你们公司内部的技术细节。工具扩展需要注意权限边界。给 Agent 挂工具前先想清楚最小权限原则它只能读哪些目录、只能执行哪些命令、只能写哪些路径。Octop 的配置里通常可以约束这些范围别一开始就给它一个“整个硬盘随便读写”的特权。我的建议是初期只挂“只读文件系统”和“指定目录的写入”两个工具跑熟之后再逐步放开。4. 实操把 Octop 装到自己的电脑Docker Compose 部署4.1 环境准备装好 Docker你只需要两条命令安装 Octop 的常见方式是用 Docker Compose因为它把服务、依赖、存储都打包好了不用你手动装各种运行环境。传统安装方式不是不行但你要自己处理 Python/Node 环境、依赖版本冲突、进程守护等问题麻烦不少。用 Docker 的话拉下镜像、跑起来就能用升级也简单。以我常用的部署流程为例你至少需要一台能跑 Docker 的主机Windows 装 Docker Desktop、macOS 装 Docker Desktop、Linux 装 Docker Engine以及 Docker Compose v2 插件。我这里用端口 8320 举例实际以 Octop 官方 README 为准。git clone https://github.com/Tencent/octop.git cd octop cp config.example.yaml config.yaml docker compose up -d这里多提一句如果你是本机部署Docker Desktop 在 Windows/macOS 上记得给容器分配足够的资源。我一开始用默认配置跑本地模型时容器动不动被杀后来把内存上限调到 8G 才稳定。Linux 服务器一般没这个问题但也要注意磁盘空间镜像和模型文件加起来可能十几个 G。4.2 配置文件新手必看的 3 个关键参数模型、存储、工作区启动服务之前最重要的就是改配置。Octop 的配置文件是 YAML 格式你不需要改太多东西重点关注三块。第一块是模型接入。以 OpenAI 兼容接口为例你要配置 base_url、api_key、model 名称。如果接本地模型base_url 指向本机的模型服务地址api_key 随便填一个占位符即可如果接第三方 API就填对应的地址和密钥。第二块是存储。Octop 默认会用本地数据库保存会话和任务记录你可以指定它的存储路径这样容器重装后数据不会丢。第三块是工作区目录。这是 Agent 能读写文件的根目录对应你的业务数据目录一定要单独规划好不要直接指向系统根目录或家目录。server: host: 0.0.0.0 port: 8320 storage: type: sqlite path: ./data/octop.db model: provider: openai-compatible base_url: http://host.docker.internal:11434/v1 api_key: ollama model: qwen2.5:7b workspace: root: ./workspace按照我踩坑的经验模型这块最多人出错的是 base_url。如果你用 Ollama 作为本地模型服务它默认监听 11434 端口并且提供 /v1 兼容接口。在 Docker 容器里访问宿主机服务要用 host.docker.internal 这个特殊域名而不是 127.0.0.1。这个细节第一次部署时几乎必踩直接记住就行。4.3 启动与验证从空容器到可用工作台配置改完执行 docker compose up -d 后等一两分钟看日志。第一次启动要拉镜像时间取决于你的网络和镜像体积。启动成功后用浏览器打开 http://localhost:8320正常应该能看到 Web 界面。有些版本会要求设置管理员账号或者在启动日志里给一个一次性访问令牌你按提示操作即可。docker compose logs -f octop看到日志稳定输出、没有报错就算搭好了。这时先别急着用复杂功能我用一个小任务验证链路让工作台读一个我放在 workspace 目录里的文件然后总结内容。这个任务很简单但能确认“模型调用通没通”和“文件读写路径对不对”两件大事。如果模型返回错误多半是 base_url、api_key、model 名三者之一没配对如果文件读不到就去看 workspace root 设置和容器挂载路径。4.4 接入模型的两种方式本地模型和在线 API 怎么选我在实际使用中Octop 通常会同时准备两种模型接入方式按任务切换。第一种是接本地模型比如 Ollama。先拉一个合适规模的模型我推荐从 7B 左右的量化模型开始兼顾效果和内存占用。启动 Ollama 后用上面那个配置就能对接上。本地模型的优点是不花钱、数据不出本机缺点是速度慢、推理能力强弱取决于你的显存和内存。第二种是接在线 API。这时 base_url 指向服务商的 OpenAI 兼容地址api_key 填真实密钥model 填对应的模型名。在线模型明显更聪明特别适合复杂推理、长文本总结这类任务。我的做法是把“默认模型”设为在线大模型处理日常高难度任务把“实验模型”设为本地小模型跑批量测试、预审文档、探测技能是否触发。这样的组合兼顾效果和成本。5. 第一次上手写一个“规则 技能”让工作台听你的5.1 给整个工作台定几条全局规则让它对所有任务都生效Octop 里有一个很多人刚开始忽略、但我觉得价值极大的功能全局规则。它相当于给工作台上的所有任务加了一层“宪法”每个任务都必须遵守。当时我看到这个设置的第一反应是这不就是我一直想要的“给 AI 立规矩”吗全局规则里可以写什么我举几个例子所有任务默认只允许在工作区目录内读写文件执行任何写操作之前必须先输出将要执行的命令并等待确认回答问题时如果信息不足明确说“这个信息我不掌握”不要编造涉及敏感的内部术语时优先检索知识库工具而不是凭模型记忆回答。把这些规则写进配置后不管后面跑多少个任务、调多少个技能这些约束始终生效。global_prompt: - 你是运行在本机的 AI 工作台助理。 - 所有任务默认使用工作区路径不得读取该路径以外的文件。 - 执行任何写操作前先输出将要执行的命令等待用户确认。 - 信息不足时明确说明不得编造内容。这一步能极大减少“AI 自作主张”的情况。比如有一次我让它整理一份项目周报它擅自读了我桌面上的一个重要文档——后来加了路径限制规则这种情况就再没出现过。你给 AI 的规则越明确它的行为越可控。5.2 创建一个最小可用的技能日志分析完成了全局规则我们来写第一个技能。我建议从日志分析开始因为日志文件结构清晰、出错容易识别很适合验证链路。先在技能目录下新建一个 YAML 文件内容按下面的结构写name: analyze_log description: 读取指定日志文件统计 ERROR 级别出现次数列出前 10 条错误消息并给出可能的修复建议。 inputs: - name: file_path type: string required: true prompt: | 你是一个日志分析助手。读取指定文件 {file_path}。 按以下步骤执行 1. 统计 ERROR 级别日志的总数。 2. 列出出现次数最多的前 10 条错误消息。 3. 基于错误内容给出可能的修复建议。 最后用简洁的中文输出报告。看到没有技能本质上就是你以前写在提示词里的那段“操作规范”只不过现在它被结构化、命名、登记在案。Agent 在收到“帮我看看这个日志文件”这类请求时就会去匹配 analyze_log 这个技能然后自动传入 file_path 参数。技能定义文件建议放在统一目录并纳入版本管理这样以后每次修改都有历史记录。我自己会把技能文件当成代码来维护——写注释、写单元测试用不同日志样本验证输出格式、定期 review。Agent 的可靠性很大程度上就是靠这些细节堆出来的。5.3 验证技能是否被正确触发技能写好之后真正的考验来了Agent 会不会在任务进来时主动调用它。在对话界面里直接发一条指令比如“总结一下 workspace/logs/app.log 中的错误。”然后观察 Octop 的响应过程。如果技能被正确触发你会看到它先加载技能定义读取文件再执行分析步骤最后输出结构化的报告。如果技能没被触发就要回头看两个地方。一是技能描述是否足够清晰。描述里如果只写“分析日志”四个字Agent 大概率不知道什么时候该用它。二是你的请求是否和技能描述匹配。技能描述里的关键词越贴近真实任务用语触发率越高。我第一次测试就遇到一个哭笑不得的问题技能写好了但请求里说的是“看看日志里有什么问题”技能描述里用的是“统计 ERROR 次数”Agent 没匹配上。后来我改技能描述写成“用于日志分析场景特别是排查错误、统计异常、定位故障”触发率立刻高了。这说明技能描述要覆盖“用户可能怎么描述这个任务”而不是只写“这个技能能干什么”。6. 常见问题与排查技巧实录6.1 技能不触发模型在自由发挥这是新手最容易遇到的问题。现象是技能文档写得明明白白可对话时 Agent 完全无视它自己脑补答案。排查顺序我建议这样先检查技能描述是否覆盖用户请求的说法再看请求里是否指定了技能名有些场景直接点名更可靠最后看全局规则是否存在冲突比如你在全局规则里要求“先别急着调用技能先做信息收集”结果 Agent 就真的不调用技能了。我的经验是技能触发这块最值得投入时间优化是“描述”。宁可把描述写得像产品说明书一样详细也不要只写一句话。可以把常见触发短语直接写进去比如“日志分析”“错误统计”“排查故障”这些短语就是 Agent 做匹配时的重要参考。6.2 容器一升级数据和配置全丢了所有 Docker 部署都要面对的坑容器是“一次性”的数据必须放在挂载卷里。如果你的 Octop 用了 sqlite 存储又没有把数据目录挂出来那么一旦容器重建聊天记录和任务历史就可能清空。解决办法很简单把 storage 路径、技能目录、工作区目录全部挂载到宿主机目录。我做了一次整理之后就再没提心吊胆过升版本的事——先把 docker-compose.yml 备份一份再停老容器、拉新镜像、起新容器数据和技能文件都在本机磁盘上安然无恙。顺带说一句定期备份这些目录也很重要它们才是工作台真正的“记忆”。6.3 本地模型太慢、上下文总被截断如果你跑本地模型大概率会遇到两个问题生成速度让人着急或者对话稍微长一点就报上下文超限。前者通常是硬件资源不够后者是模型配置里的上下文长度没调好。我的建议是文本量大但又不需要太高推理质量的任务用更小的量化模型需要强推理但文本量不大的任务才用稍大的模型。同时在配置里把 context_length 调成模型实际支持的值别盲目往大了设。如果你发现性能一直上不去也可以考虑把“文件读取初步筛选”这类预处理任务丢给脚本只把“筛选后的结果”喂给模型减少上下文压力。6.4 权限过大的隐患给 Agent 划一条安全边界自托管不代表可以不管安全。你的 Agent 跑在本机权限如果放太开一旦被恶意提示词诱导可能做出越权操作。我见过一些同学直接把整个家目录挂给工作台还允许自动执行命令——风险非常大。建议至少做四件事工作区只挂载一个专用目录不要挂载整个磁盘文件系统工具默认只读需要写入时单独开白名单路径网络请求工具尽量限制请求域名服务端口别暴露到公网需要远程访问时用内网穿透或使用带认证的反代。Agent 再聪明它也是个执行器边界安全必须由你自己负责。问题可能原因排查与解决技能没触发技能描述与用户请求不匹配重写描述加入常见触发短语模型返回乱码/报错base_url、api_key、model 配置错误检查 OpenAI 兼容接口三要素对话历史丢失存储目录未挂载到宿主机挂载 sqlite 目录备份 data 文件夹本地模型速度极慢模型过大或内存不足换量化模型、调低上下文长度Agent 读取了不该读的文件工作区范围限制失效收紧挂载路径加全局路径规则我个人的习惯是每次新增一个技能先在测试工作区跑三遍——一遍标准输入、一遍空输入、一遍故意给错路径。三遍过了再挪到正式工作区用。Octop 这类工具最怕的不是模型笨而是你连“让它做什么”都没写清楚。你把它当成一个特别较真的新同事规则写明白技能写细致它就能帮你分担大量重复劳动剩下那些调试 Agent 的复杂度正好也留在你自己手里一点点调出来。