玄姐聊AGI公众号文章2026-10-11

腾讯开源版 WorkBuddy 架构设计拆解

科技与互联网

玄姐聊AGI

公众号 · 36 篇文章

查看主页 →

大家好，我是玄姐。

PS：AI 落地点击预约直播。

最近陪企业做 AI 原生研发体系落地，被问得最多的已经不是「用哪个大模型」，而是：「玄姐，有没有一个能私有化部署、多人共用、还能真正干活的 AI 助手底座？」

巧了，腾讯云开源了一个项目，正好踩在这个点上：Octop。

开源地址：https://github.com/TencentCloud/Octop

它的官方一句话定位是：A smarter, self-hosted AI assistant, multi-user, multi-agent.一个更聪明的自托管 AI 助手，多用户、多 Agent。MIT 协议，截至发稿 GitHub 已有 8.4k Star。

因为产品形态和腾讯的 WorkBuddy 高度相似，业内有人把它称为「开源版 WorkBuddy」。今天就从架构师视角，把 Octop 一层层拆开看。

PS：WorkBuddy 更多案例深入免费学习去这里，扫码直达：

1.打开 AITutor 新一代 AI 原生学习伙伴：www.aiaitutor.com 2.在首页输入"Workbuddy”就能看到更详细更丰富案例。3.包含了图文、视频、播客、闪卡、代码、测验等9种学习模态。

一、先说结论：Octop 到底是什么

一句话概括：Octop 是一个「部署在你自己机器上的、全家和小团队共用的 AI 助手」。

自托管：所有配置、数据、工作区都放在本地 ~/.octop/ 目录，对话和凭证不出你的机器。
多用户：一个管理员加多个成员，JWT 认证，工作区、模型配置、渠道彼此隔离。
多 Agent：每个用户可以拥有自己的一支「专家团队」，每个 Agent 有独立人设、Skills、记忆和工作区。
能干活：不只是聊天，还能操控浏览器、执行终端命令、远程桌面、跑定时任务、把编码任务委派给 Claude Code、Codex 这类编码 Agent。
全渠道：Web 控制台、CLI，以及飞书、钉钉、企业微信、微信、QQ、Telegram、Discord 都能接入。

官方给的目标用户是家庭和小团队，但我认为，它的架构设计对企业做 AI 助手平台同样很有参考价值。

二、总体架构：一个进程，四个 Harness 库

2.1 单进程，不要消息队列

这是 Octop 最反直觉、也最值得学习的设计。

很多人一想到「多用户多 Agent 平台」，脑子里就是一整套重型架构：网关、消息队列、Worker 集群、Redis、任务调度中心。Octop 反其道而行之：

Web 控制台、CLI、IM 渠道、定时任务，全部跑在同一个 Python 进程里，统一进入一个进程内的处理器（HarnessProcessor）。
没有 Redis，没有消息中间件，没有 Worker 舰队。
所有状态落在控制面数据库：默认 SQLite（WAL 模式），也可以切换到 PostgreSQL。进程重启后，直接从数据库重建全部状态。

为什么敢这么做？因为它的目标场景是家庭和小团队，并发量不高。用单进程换来的是极低的部署和运维成本：一条命令装好，一条命令跑起来。

这背后是一个非常朴素的架构原则：不为臆想的规模提前设计。这和我上一篇讲的「简单优先」是同一个道理。

2.2 组合四个 Harness 库，而不是自研运行时

Octop 本身更像一个「组装层」，核心能力来自四个独立的 Harness 库：

组件	职责
Octop Harness（harness-agent）	Agent 对话运行时，基于 LangGraph
Octop Gateway（harness-gateway）	IM 消息桥接与归一化，把各家 IM 的消息统一成一种格式
Octop Memory（harness-memory）	分层召回 + 全文检索的记忆系统
Octop Browser（harness-browser）	基于 CDP 协议的浏览器自动化

这种拆法的好处很明显：运行时、网关、记忆、浏览器四块可以独立演进，也可以被其他项目单独复用。

2.3 核心组件与分层

从代码结构看，Octop 有几个关键角色：

OctopServer：服务入口，基于 FastAPI + uvicorn。
DatabasePool：数据库连接池，对接 SQLite 或 PostgreSQL。
UserManager：多用户管理与隔离。
ExpertCatalog：专家目录，管理内置专家库和专家市场。
HarnessAgentManager / AgentRuntime：Agent 生命周期管理与运行时。

每个 Agent 内部：HarnessAgent（运行时）、HarnessProcessor（IM / UI / 定时任务的统一入口）、ChannelManager（渠道管理）、CronManager（基于 APScheduler 的定时任务）。

还有一个特别值得企业借鉴的细节：领域核心（infra/）不依赖 HTTP 层，路由只是薄适配层，启动时由组合根统一装配单例。而且仓库里专门放了一份 AGENTS.md，用来约束 AI 编码 Agent 在改代码时不能破坏这些架构边界。

这一点非常认同：在 AI Coding 时代，架构约束不能只写在人的脑子里，要写成 AI 能读懂、能遵守的规范。这正是 SDD（规范驱动开发）的核心思想。

三、多用户多 Agent：每个人都有一支专家团队

3.1 专家库与专家市场

Octop 把 Agent 包装成了「专家」：

内置专家库：按场景预置了一批专家，用户可以随时切换。
专家分享：用户可以把自己调教好的专家发布出去，Skills 和子 Agent 也能进入共享资源池。
MBTI 人格：提供 16 种 MBTI 人格模板，还配了一个互动测试，帮你选出合适的 Agent 人设。

人格这个设计看起来有点「玩」，但背后的逻辑是对的：同样的模型，不同的人设和专家画像，会产出风格完全不同的结果。把这件事产品化，降低了普通用户调教 Agent 的门槛。

3.2 AgentTeams：从单兵到团队

Octop 目前处于 Beta 阶段的 AgentTeams，由一个协调者调度多个专家，共同完成多步骤任务。

这和 WorkBuddy 正在主推的「专家团」方向非常接近。多 Agent 协作，是 AI 助手从「能回答」走向「能交付」的必经之路。

3.3 隔离是多用户的生命线

多用户平台最怕什么？串数据。Octop 的隔离做在几个层面：

认证层：JWT 认证，一个管理员账户，其余为普通成员。
数据层：资源归属在数据库层面强制校验。
工作区层：每个 Agent 都有独立工作区，工作区后端可插拔，支持本地磁盘、Docker 沙箱、COS / S3 对象存储。

四、全渠道接入：一条消息管线打通所有入口

Octop 支持的入口非常全：

Web 控制台：默认启用，地址是 http://127.0.0.1:8088。
CLI：完整的命令行工具。
IM 渠道：飞书、钉钉、企业微信、微信、QQ、Telegram、Discord，还可通过网关扩展更多。
API：HTTP / SSE 接口。
定时任务：用自然语言或斜杠命令设置，例如「每天早上 9 点帮我汇总昨天的行业新闻」。定时任务既可以直接推消息，也可以先让 Agent 跑一遍，再推送结果。

关键在于：所有入口最终都汇入同一条消息管线。不管消息来自飞书还是 Web，Agent 看到的是统一格式，处理逻辑只写一份。

这对企业很有启发：很多公司的 AI 助手，飞书一套、企微一套、Web 再一套，逻辑各写各的，最后维护成本爆炸。入口可以多，管线必须一条。

五、执行能力：从「能聊」到「能干」

5.1 Browser AI+ 与 Terminal AI+

Browser AI+：基于 Playwright 的无头 Chromium，能填表单、截图、采集信息。
Terminal AI+：控制台内置交互式终端，Agent 可以执行命令。
远程桌面：支持实时串流远程桌面，操控图形界面应用。

5.2 ACP 双向集成

这是 Octop 里技术含量最高的设计之一。ACP（Agent Client Protocol）是一个 Agent 与客户端之间的通信协议，Octop 做了双向支持：

往里接：执行 octop acp，通过 stdio 把 Octop 的 Agent 暴露给 Zed、OpenCode 这类编辑器和 Agent 工具。
往外派：对话中可以把编码任务委派给 OpenCode、Claude Code、Codex、CodeBuddy 等编码 Agent 去执行，并带有权限闸门。

这意味着 Octop 不跟专业编码 Agent 抢活，而是做「调度者」：日常事务自己干，写代码的活派给最擅长的编码 Agent。这是一个非常清醒的产品边界判断。

5.3 知识库、插件与连接器

知识库（RAG）：上传文档即可构建检索增强知识库。
插件系统：第三方工具包在控制台一键开关。
连接器生态：接入腾讯系套件（文档、会议、新闻等），并可通过 OAuth 应用和 MCP 网关继续扩展。

六、记忆系统：Portable Memory

Octop 的记忆由 Octop Memory 提供，有两个关键特点：

分层召回 + 全文检索：不是简单把历史对话全塞进上下文，而是分层组织，按需召回。
可迁移（Portable）：记忆跟着工作区走，工作区迁移，记忆也一起迁移。

同时还提供了 octop memory list 和 octop memory slim 命令，用来查看和瘦身记忆。

记忆要能「瘦身」，这一点很关键。我在上一篇讲知识飞轮时强调过：过期知识污染上下文，比没有知识更危险。记忆系统不能只会加，还要会减。

七、安全治理：给 Agent 戴上护栏

能操作浏览器、能执行 Shell 的 Agent，如果没有护栏，就是一颗定时炸弹。Octop 的安全机制有五层：

多用户隔离：JWT 认证 + 数据库层面的归属校验。
工具审批：高风险工具调用需要人工批准。
Shell 命令防护：可编辑的允许 / 拒绝规则。
PII 脱敏：自动识别并脱敏个人敏感信息。
执行隔离：基于 bubblewrap 的沙箱隔离，以及 Docker 沙箱工作区。

AI 自主性越高，治理就越要前置。这也是企业 AI 原生研发体系里「治理度量」这一块要解决的问题。

八、Octop 和 WorkBuddy 对比

两者的对比：

维度	WorkBuddy	Octop
官方定位	全场景 AI 办公工作台	开源、自托管的 AI Assistant
目标用户	普通用户	开发者、家庭、小团队、企业
交付形态	产品	MIT 开源，可二次开发
数据位置	官方服务	本地 ~/.octop/
核心能力	专家、专家团、Skills、MCP、连接器	专家库、AgentTeams、Skills、MCP 网关、连接器、ACP

一句话：WorkBuddy 要的是用户，Octop 要的是开发者。产品形态相似，但服务的是两类不同的人。

九、5 分钟上手

9.1 安装

四种方式任选：

一键脚本：macOS / Linux 用 install.sh，Windows 用 install.ps1 或 install.bat，脚本会自动配好 Python 环境。
PyPI：pip install octop。
Docker：使用仓库里的 docker/docker-compose.yml，默认端口 8088。
桌面客户端：从 GitHub Releases 下载，支持 Windows、macOS、Linux 和飞牛 FnOS。

9.2 启动

octop init    # 初始化数据库、JWT 密钥和管理员账户octop run     # 启动 API 和 Web 控制台

浏览器打开 http://127.0.0.1:8088 即可使用。想常驻后台，用 octop service start 注册为系统服务。

9.3 常用命令

octop agent      # 管理 Agentoctop channel    # 管理 IM 渠道octop models     # 管理模型octop provider   # 配置模型提供方octop skills     # 管理 Skillsoctop plugin     # 管理插件octop cron       # 管理定时任务octop acp        # 通过 ACP 暴露 Agentoctop memory slim --all   # 记忆瘦身octop backup     # 备份octop update     # 升级

模型方面，支持 OpenAI 兼容 API、通义千问（DashScope）、Ollama 本地模型等，可以按 Agent 单独配置。

十、Roadmap：它要往哪走

官方路线图（仅供参考，可能调整）：

已完成：共享资源池、专家分享、PC 客户端。
进行中：AgentTeams（Beta）、移动端（封闭测试）。
计划中：浏览器与终端增强、自进化技能、Managed Agents、Project 工作区、云边协同、插件市场、对话式控制面。

其中我最关注两个：自进化技能和云边协同。前者意味着 Agent 能从使用中沉淀新技能，后者意味着本地私有部署和云端能力可以打通，这两件事做好了，它就不只是个人助手，而是有机会成为企业 AI 助手底座。

十一、判断：企业能从 Octop 学到什么

11.1 适合谁直接用

个人和小团队：想要一个数据不出门、多人共用、能接飞书钉钉的 AI 助手，Octop 开箱即用。
企业 POC：想快速验证「内部 AI 助手」场景，Octop 是很好的起点，MIT 协议也方便二次开发。

11.2 企业直接上生产要注意什么

单进程的扩展性边界：单进程加 SQLite 适合低并发，企业几百上千人同时用，需要切到 PostgreSQL，并评估水平扩展方案。
权限体系：目前是「一个管理员 + 成员」的模型，企业需要对接自己的 SSO、组织架构和细粒度权限。
审计与合规：Agent 能执行 Shell、操控浏览器，企业需要补齐完整的操作审计和合规留痕。
项目仍在快速迭代：版本还在 1.0 测试阶段，接口和功能可能调整，上生产前要做好版本锁定。

11.3 最值得借鉴的四个设计

单进程优先：不为臆想的规模提前设计，先让系统简单可运行。
Harness 分层组合：运行时、网关、记忆、浏览器四块独立，可复用、可替换。
入口多、管线一条：所有渠道统一消息格式，处理逻辑只写一份。
用 AGENTS.md 约束 AI 改代码：把架构边界写成 AI 能遵守的规范，这是 AI 原生研发的基本功。

十二、总结

最后，用五句话把 Octop 浓缩一下：

定位：开源、自托管、多用户、多 Agent 的 AI 助手平台，被称为「开源版 WorkBuddy」。
架构：单进程 + 四个 Harness 库 + 一个控制面数据库，极简但完整。
能力：全渠道接入、浏览器与终端操控、ACP 双向调度编码 Agent、RAG 知识库、可迁移记忆。
治理：JWT 隔离、工具审批、Shell 防护、PII 脱敏、沙箱执行，五层护栏。
启发：AI 助手的竞争，正在从「模型能力」转向「Harness 工程能力」。

模型决定下限，Harness 决定上限。谁能把运行时、记忆、工具、渠道和治理这套工程体系做扎实，谁才能让 AI 真正从「能聊」走到「能干」。

好了，这就是我今天想分享的内容。如果你对企业级 AI 原生研发体系（Skills、SDD、Harness、Loop、知识本体、治理度量等）感兴趣，欢迎去 AITutor 领取福利。

AITutor 福利：AITutor 每个人的 AI 原生学习伙伴，业界最丰富 AI 实践和案例，4500+ 门多模态 AI 课程、7×24 小时 AI 导师已全面开放，快来免费体验吧。

打开 AITutor，新一代 AI 原生学习伙伴：www.aiaitutor.com
在首页输入「你想学习的 AI 知识」，就能看到更详细、更丰富的案例
包含图文、视频、播客、闪卡、代码、测验等 9 种学习模态

扫码直达：