腾讯 Octop 拆解把AI 同事装进一台机器为什么它坚持单进程TL;DR 速览事实校准TencentCloud/Octop并非新项目——仓库创建于 2026-07-08、v1.0.0 发布于 2026-09-149-17 被 36氪 报道后才大范围出圈MIT 协议、Python 3.12架构核心不用外部队列或消息代理Web 控制台 / IM 通道 / 定时任务全部经由进程内的一个处理器控制面默认 SQLiteWAL启动时从数据库重建状态四个 Harness 运行时harness-agent模型路由/工具/技能/检查点、harness-gatewayIM 归一化、harness-memory分层召回记忆跟工作区走、harness-browserCDP 自动化它解决的具体问题多用户隔离——一台机器一套服务每个成员有独立工作区、记忆和专家配置JWT 做权限边界上生产前必须处理默认口令admin/octop首登必改远程桌面与浏览器自动化会显著扩大攻击面社区版没有 SLA9 月 17 日36氪 发了一篇文章标题是《腾讯悄咪开源了一个WorkBuddy》。文章对象是一个叫 Octop 的开源项目作者把它的能力逐条对比之后认为它像一个可以自己部署、自己改造的开源版 WorkBuddy——多 Agent、专家体系、Skills、MCP、知识库、自动化、本地工作区这些能力基本覆盖。同一篇报道里也明确写了腾讯并没有把 Octop 定义成 WorkBuddy 的开源版本。有一条事实需要先校准它决定了你该怎么理解这个项目Octop 的仓库创建于 2026 年 7 月 8 日v1.0.0 版本发布于 9 月 14 日。也就是说它不是这两天才出现的项目而是开源两个多月、刚发 1.0 之后被媒体翻了出来。这个背景很重要——它意味着下面讨论的架构决策经过了两个月的实际使用迭代而不是一份设计文档。一、四个运行时拼成一个进程Octop 的技术栈是可以直接读出来的Python 3.12、FastAPI uvicorn、控制面数据库默认 SQLiteWAL 模式可选 PostgreSQL、前端 React 18 TypeScript Vite Ant Design、调度用 APScheduler、ACP 走 agent-client-protocol。真正有意思的是它把运行时拆成了四个Harness组件然后在同一个进程里组合起来组件职责harness-agentAgent 运行时模型路由、工具、技能、会话检查点harness-gateway多平台 IM 通道桥把各渠道消息归一化成同一条处理管道harness-memory分层召回 全文搜索记忆随工作区迁移harness-browser基于 CDP 的浏览器自动化支持持久化 profile这个拆法解决的是典型的多入口问题一个自托管助手要同时面对 Web 界面、飞书/钉钉/QQ/企业微信/Discord 这类 IM 通道以及定时任务。如果每个入口各写一套处理逻辑状态和权限会立刻分裂。Octop 的做法是先归一化再统一处理。二、为什么坚决不用消息队列这是整个架构里最值得单独拎出来的一条。绝大多数多入口 异步任务的系统默认会引入消息队列或代理来解耦。Octop 的选择相反所有入口都路由到一个进程内的HarnessProcessor不引入外部队列。这个决定换来三件事按重要性排序第一部署门槛降到一条命令。没有额外中间件要装、要配、要保活。对目标场景家里的机器、小团队的服务器、NAS来说这是决定性的——不是每个想跑 AI 助手的人都愿意维护一套 Kafka 或 RabbitMQ。第二重启安全状态全在数据库里。整个进程的状态在启动时从控制面数据库重建。默认就是本地的 SQLiteWAL文件可选 PostgreSQL。这意味着重启不是恢复过程而是重读状态——没有内存里的任务队列在重启时丢失的问题。第三数据边界清楚。所有对话、工作区、凭证都在~/.octop/下配合完全离线可跑的设计隐私边界就是文件系统边界。代价也很明确单进程意味着吞吐上限受单机限制横向扩展不是它的设计目标。这一点在评估时必须接受——它是给一台机器服务一家人或一个小团队设计的不是给多租户 SaaS 设计的。三、多用户隔离和一件被名字掩盖的设计Octop 的名字取自 Octopus章鱼定位是多用户、多 Agent。它解决的问题很具体几个人共用一个 AI 助手时记忆混在一起就没法用了。它的处理方式多用户 JWT 认证 admin 角色。管理员建多个成员账号每个成员的记忆、工作区、专家配置相互隔离JWT 承担权限边界。每个成员可以挂多个专家。官方给的用法是群里 不同专家干活三餐搭配问营养师、租房合同问法律顾问、代码重构丢给代码审校。专家模板库在启动时扫描infra/agents/experts/library/。另外内置 16 种 MBTI 人格模板——功能上不影响能力但对家庭共用的场景使用意愿确实不一样。每个 Agent 有独立的工作区、provider、通道和 cron。但这里面最有价值的一条设计藏在harness-memory的一句话描述里记忆跟着工作区走不跟模型走。大多数助手的记忆绑在会话或者某个模型上换了模型就断片Octop 的记忆基于工作区构建因此本地跑 Ollama 处理日常、遇到复杂推理切云端大模型工作区、历史上下文、偏好和任务记录都还在。工作区还能整体打包迁移——换台机器、换套模型另一个 Agent 接着干。对自托管场景来说这是关键一环。自托管的一个隐含前提是我会换模型成本、能力、可用性都会变如果每次换模型都等于重新交底长期使用的成本会高到无法接受。我自己的判断习惯是评估一套自托管系统先看它的状态放在哪、能不能整体搬走。放不进一个目录、或者搬走就断片的设计长期用起来成本很高。墨衍 里我把素材、选题和分发记录攒在一处本质也是同一个考虑——别让记录散在几个工具里。四、ACP 双向与权限门控ACPagent-client-protocol这块的设计方向值得单独说它是双向的。往内IDE 和终端 AI 可以通过octop acp调用 Octop。往外Octop 也能把编码任务委派给 OpenCode、Claude Code 这类外部 coding agent——带权限门控。这个双向 门控的结构和前几天那批把执行边界钉死的做法是同一个思路能力可以外接但外接的每一步要有明确的授权检查点。其余能力清单按官方口径安全机制多用户 JWT 隔离、工具调用审批、shell 命令护栏、PII 脱敏。执行面Terminal AI浏览器里的交互式 shellAI 辅助执行与排查、Browser AIheadless Chromium网页操作、截图、采集支持持久化登录态、远程桌面Linux / Windows / macOS控制台里看屏幕控输入headless Linux 可一键拉起隔离桌面。存储后端可插拔本地磁盘、Docker 容器、COS、S3、PostgreSQL 等。知识库对私有文档做 RAG语义检索把回答落回自己的语料。插件第三方插件可安装管理内置插件按需开关。APIHTTP / SSE / WebSocket 全量编程访问/api/docs默认关闭需要在config.json里把enable_api_docs设为true才开——这个默认值是个好设计别改成 true 就部署到公网。五、上手三步以及上生产前的风险清单安装macOS / Linux 一键Windows 走 PowerShellcurl-fsSLhttps://finnie-1258344699.cos.ap-guangzhou.myqcloud.com/octop/install.sh|bashoctop init# 建数据库、JWT 密钥、首个管理员octop run# 启动 API Web 控制台之后打开http://127.0.0.1:8088使用。CLI 侧还有octop chat、octop acp和管理命令生产环境官方推荐走 Docker Compose。上生产之前这五条按优先级排一、默认口令必须首登就改。默认账号admin、密码octop。如果服务暴露到公网弱口令就是最大的洞——这是官方自己在文档里点出来的风险。二、远程桌面与浏览器自动化会显著扩大攻击面。这两项能力的本质是让 AI 操作你的机器能力越强被滥用的后果越直接。三、权限体系要按最小可用配。有工具审批和 shell 护栏不等于自动安全配置才是真正的边界。四、社区版没有 SLA。付费 SaaS 出问题有人管自托管出问题自己修——这笔成本要提前算进决策而不是出事后才认。五、核心运行时仍在陆续开源。想直接读全部源码做深度改造的人得先确认当前版本的完整度。六、这套东西适合谁适合数据敏感、要求本地可控的小团队需要家庭或多成员共用一套 AI 助手的场景想把模型、存储、IM 通道都换成自己那一套、不接受厂商锁定的人。不适合只想要打开就能用、不愿承担运维的人需要多租户 SaaS 级弹性和 SLA 的业务追求开箱即用体验、不想配模型和专家的团队。如果让我给一个落地的判断顺序先在一台闲置机器上跑octop initoctop run用一两个真实任务比如周报汇总、文档检索验证工作流再决定要不要接 IM 通道和远程桌面这类高权限能力。从低权限能力开始验证比先开满功能再回退安全得多。