朋友昨天问了我一个很有意思的问题：听说腾讯把 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 的复杂度，正好也留在你自己手里，一点点调出来。
