把 AI 助手装回自己家:腾讯云开源的 Octop,到底想解决什么问题

先把身份说清：Octop 不是动物，是腾讯云开源的一个自托管 AI 助手平台，项目仓库在 github.com 的 TencentCloud/Octop 名下，官网是 octop.cloud。想法不复杂——找一台你自己的机器，电脑、NAS、小服务器都行，跑起一个进程，家里人或小团队每人一个账号，各自养一队 AI「专家」，对话和文件就放在这台机器里。

• 01
  先说它是个啥
• 02
  自托管怎么又热了
• 03
  怎么装
• 04
  一台机器一家人用
• 05
  为什么叫“专家”
• 06
  AgentTeams 谁来传话
• 07
  知识库和记忆
• 08
  技能、连接器与 MCP
• 09
  在群里喊它
• 10
  浏览器、终端、远程桌面
• 11
  ACP 写代码的人看
• 12
  定时、安全和边界

这两年用 AI 助手，基本都是一个路子：注册个账号，登录，在别人的服务器上聊。方便是方便，就是用着用着会别扭。一家人想共用，每个人都得开一份；把工作文档、家庭资料往对话框里贴，心里又总有点不踏实；更别说你平时干活根本不在那个网页里，你在飞书群里、在微信里、在本地文件夹和终端里，它都够不着。

Octop 想换个办法：别租了，自己在机器上跑一个。

下面这些都来自它的官方仓库和公开文档，能对上的我都尽量对上了。哪些是文档里写明的，哪些是我看完之后的判断，我会分开说。没说清的地方，我就直说没说清，不替它脑补。

Octop 是腾讯云开源的自托管 AI 助手平台，主要给家庭和小团队用。

它有个挺反潮流的选择：不拆微服务。Web 控制台、命令行、消息通道、定时任务，全塞在同一个 Python 进程里。敲一行octop run就都起来了，不用再单独装 Redis、消息队列那一套。对想自己部署的人来说，这点其实很关键——很多人不是不会用，是卡在装都装不起来。

不管你是从网页发消息，还是在飞书群里 @ 它，又或者是定时任务到点触发，最后都走进程里的同一条处理管线，官方叫 HarnessProcessor，再分给对应的 Agent。状态存在~/.octop/下面，默认用 SQLite，开了 WAL。进程重启了，用户、Agent、通道、任务还能从数据库里捞回来，不至于一重启就清零。

技术栈没什么神秘的：后端 Python + FastAPI，前端 React + TypeScript，调度用 APScheduler，跟编程工具协作走 ACP。

还有个容易误会的地方得提前说：Octop 本身不是大模型，它不自带“聪明”。你得给它接模型，官方预设了几家供应商，也支持兼容 OpenAI API 的自定义服务，或者 Ollama 这种本地模型。说白了，它管的是账号、专家、工作区、记忆、技能这些组织方式，脑子要你自己配。

自托管不新鲜，玩 NAS 的人玩了十几年了。放到 AI 助手上又被提起，理由倒不复杂。

一个是数据放哪。助手越能干，你喂的东西就越私密，工作文档、表格、聊天摘要，什么都有。自托管默认是把对话、工作区文件、凭据都放在你机器的~/.octop/里，备份、迁移、删掉，都你自己决定。听起来挺好，但这里有个坑必须拆开说：存放在本地，不等于处理也在本地。你要是接的是云端模型 API，提问照样要发给模型厂商去算；你用了外部连接器、消息平台，内容也会经过那边。只有你配的是 Ollama 这类本地模型，又不调外部服务，才算全程没出这台机器。所以自托管给你的是“我知道东西存哪、能自己处置”，不是一句“绝对不出门”就能打发的。

再一个是共用的账。云端按人头收费，一家四口再加个小工作室，叠起来不便宜。自己这边呢，一台闲置电脑、一台 NAS，或者一台入门云服务器跑一个进程，大家共用一套，剩下的主要就是模型 API 的用量钱。

还有就是在不在场的问题。高频要帮忙的事，往往都在本地：整理这台机器上的文件、开浏览器填个表、SSH 上去看一眼服务器、在群里接句话。助手就住在这台机器上，确实离得近一点。

代价也别回避。机器关了、进程挂了，助手就离线了，没人替你兜底。安全也得自己守，要是把服务扔到公网上还不改默认密码，那就真是在递钥匙了，后面第十二章会细说。Octop 在这件事上挺务实：先用单进程加 SQLite 把门槛压低，让人能跑起来，规模的事以后再说。我觉得这个顺序是对的，先能用，再谈大。

安装给了四条路，丰俭由人。

最省事的是桌面客户端：去 GitHub 发布页下对应系统的包就行，Windows 有 x64 和 ARM64，macOS 分 Apple 芯片和 Intel，Linux 也有 x64 / ARM64。飞牛 NAS 用户还有 Docker 版和原生 FPK 包，能在应用中心装。装完跟着向导走完初始化。

想装在自己电脑或服务器上，可以用一键脚本。官方脚本会用 uv 在~/.octop/里建个隔离的 Python 环境，不动你系统的 Python，装完octop命令就进 PATH 了。已经在管 Python 环境的人直接 PyPI，一行pip install octop。要是打算长期跑，官方更推荐 Docker Compose，数据目录挂出来，重启不丢。

pip install octop     # 或用官方一键脚本 / 桌面客户端 / Docker octop run             # 启动控制台、通道与定时任务 # 启动后在浏览器打开本机 8088 端口的控制台

第一次启动会进设置向导：建数据库、生成 JWT 密钥、设管理员账号。紧接着就得配模型，选预设供应商或者填兼容接口，把 API 凭据备好。没模型的话，这平台就是个空壳，什么都聊不了。

数据库先别纠结，默认 SQLite 就够了。零配置，跟着数据目录走，备份就是拷文件。等真到了用户多、并发高、运维要求上来的那天，再按文档切 PostgreSQL 也不迟。长期跑的话，注册成系统服务或者用 Docker Compose 常驻就行。

很多人一听自托管，就觉得是一个人折腾的玩具。Octop 不是这个路子，它一开始就奔着多人共用去的。管理员把平台搭好，给每位成员建独立账号，登录走 JWT，用户之间是隔离的。

隔离做得还算彻底。每个人有自己的 Agent 列表、自己的工作区目录、自己的模型配置、自己的消息通道和定时任务。打个比方，孩子拿它整理学习资料，父母拿它记提醒，你拿它跟项目，住在同一套部署里，但对话、文件、凭据互相看不见。这点对家庭和小团队挺实在的：省的是部署成本，分开的是各自的空间。

能共享的地方它也没堵死。打磨好的专家可以分享给别人，知识库也能按需共享。

我看下来，它有点像合租：水电是共用的，房间是各住各的。管理员管模型、通道、安全这些麻烦事，成员在自己那摊里折腾就行。

Octop 里有个概念值得多看两眼：它不叫 Agent 叫“专家”。

现在大多数产品给你一个全能助理，什么都能聊。Octop 的想法反过来，它觉得你应该按活分工，养一组专家，用哪个切哪个。听着像营销话术，但落到配置上，还真不是一回事。

每个专家是独立的一套：工作区独立，文件和记忆不串；模型可以单独设，写作的用文笔好的，编程的换代码强的；技能清单、系统提示词、人格也都分开。工具权限更是单独的——这一点我觉得是对的，管日程的专家，实在没必要给它开终端执行命令的权限，给了就是给自己埋雷。

从零捏一个当然可以，但更省事的是从专家库起步。仓库里内置了一批模板，运维、新闻趋势、办公自动化、育儿助手这些方向都有，提示词和技能都预配好了，生成出来是独立副本，你随便改，不影响模板。用顺手了，还能把自己的专家发布回这台机器的专家市场，给家人同事复用。

还有个有点“整活”的设计：MBTI 人格模板。16 种人格加个互动测试，选完会生成一个 SOUL.md，定住专家的语气和做事风格。它肯定不涨智商，但相处感会变。你愿不愿意长期跟一个助手说话，语气其实占挺大比重，这点它抓得还挺准。

说明：以上四位是帮助理解「按岗位分工」的示意组合，具体可用模板以官方专家库为准；每位专家可单独配置模型、技能与权限，正是这套设计的要点。

专家一多，麻烦也来了。一件事横跨三个专家，你难道自己当传话筒，复制来粘贴去？

AgentTeams 就是来解决这个的，目前还是 Beta。把几位专家拉进同一个对话，找一位协调者（host）统一接活。

这个协调者的定位我觉得定得挺克制：它自己不干活。没有文件、浏览器、搜索这些工具，就干三件事——听懂你想要什么，把任务改写清楚，异步分给合适的成员，最后把结果汇总回来告诉你。成员还是在各自工作区里干活，隔离的原则没破。组队有个门槛，协调者之外至少得有两位成员，第一版还不支持团队嵌套，也不能跨用户共享。

有个细节文档里写得很明白，我觉得也该说出来：多专家协作的在途消息现在是放在进程内存里的，服务一重启，正在进行中的委派就丢了。这是第一版的取舍。单进程省事，账就记在这种地方。日常协作拿它跑跑没问题，但真有那种不能中断的关键长流程，别全押在 Beta 上，心里得有数。

助手这东西，单次回答准不准是一回事，用久了记不记得事是另一回事。Octop 在这块分了两层：知识库，和长期记忆。

知识库走的是 RAG。把文档放进去，专家回答前先去检索相关片段，再照着原文说，尽量少凭模型记忆瞎编。家里能放设备手册、课程资料，团队能放项目文档、规章、历史方案。它还能共享，一家人共用一个家庭档案库，这种用法还挺自然的。

长期记忆在底层是 harness-memory 提供的，分层，支持全文检索。有个点在自托管场景下挺讨喜：记忆是跟着工作区走的。你换机器、做迁移，或者把某个专家的工作区打包带走，记忆也跟着走，不会一换部署就失忆。当然记忆这东西也有麻烦的一面，记错了、记多了，都得你自己定期回去看、去删。好处是数据在本地，你至少删得动、管得着。

如果说模型是脑子，技能就是手。Octop 按 Agent 粒度管技能，敲octop skills list --agent main就能看某位专家启用了哪些，再按需增删。专家库模板里预置了技能组合，新专家拉起来不至于两手空空。

再往外是 Connector。通过 OAuth 接外部服务，官方主推的是一键接入腾讯系的文档、资讯这类服务。同时它还给了 MCP 网关。MCP 现在算是 Agent 圈的通用插头了，只要是按 MCP 提供的工具和数据源，都能挂进来。这就意味着 Octop 的上限不完全取决于它自己写了多少插件，外面的生态有多大，它就能接多大。日历、数据库、公司内部工具，理论上都能往上挂——当然，理论和你实际配起来顺不顺，是两回事，文档在这块写得不算特别细，真要接内部系统，估计还得自己多试。

存储后端也能换。工作区可以放在本地磁盘，可以塞进 Docker 容器里隔离，也可以挂到 PostgreSQL 或 COS/S3 对象存储上。权限和隔离跟着后端走。给权限大的编程专家套个容器，这个做法挺实际的，至少出事时有个边界。

控制台做得再好，要专门打开才能用，频率就是上不去。Octop 的处理是把消息平台桥接进来，所有通道跟 Web 控制台、定时任务共用同一条管线。你在飞书里问它，它依托的还是同一套状态，不是各聊各的。

官方支持的通道有飞书、钉钉、企业微信、QQ、微信、Telegram、Discord 等。接入方式就是各平台那套机器人凭证，飞书要 App ID 和 App Secret，钉钉是 App Key 和 App Secret，企业微信要 Corp ID 和 Agent Secret，QQ、Discord 用 Bot Token。凭证统一存在本地数据目录的 secrets 里。

接通之后，感觉会变。助手不再是你点开的那个网页，更像群里多了一个人。团队群里 @ 研究专家要个竞品摘要，家庭群里让管家记一笔开销，微信里随手转篇文章让它归档进知识库——入口越日常，人越容易想起来用它。这点我觉得比多几个功能更重要。

很多活的最后一公里不在对话框里，在网页表单里，在服务器命令行里，在那些必须开图形界面的软件里。Octop 为此塞了三件东西，官方叫浏览器 AI+、终端 AI+ 和远程桌面。

浏览器 AI+ 是基于 Chromium 的无头会话，底层走 CDP，支持持久化配置。能做网页自动化、信息采集、截图、远程浏览。持久化这点有用，登录状态能留着，那些必须登录才能操作的后台页面才有戏。

终端 AI+ 是把交互式 Shell 直接搬进浏览器控制台，AI 在边上帮你执行命令、排障。服务器半夜出问题，你不用先折腾本地终端，打开控制台就能上手，这个场景想得还挺具体的。

远程桌面是在控制台里实时看屏、用键鼠操控，Linux、Windows、macOS 都覆盖。碰上没有图形界面的 Linux 服务器，还能一键搭个隔离桌面，去跑那些非 GUI 不可的软件。

三件套放一起，定位就很清楚了：它不想只会聊天，它想去操作现场。但能动手，权限问题就绕不开了，所以安全得单独说。

如果你写代码，这章可能是 Octop 最有辨识度的地方。ACP 是编辑器/终端和 Agent 之间交换任务的协议，Octop 对它的支持是双向的。

一个方向是入站。运行octop acp --agent main，你的 Octop 专家就能以 ACP 服务的形式被 Zed、OpenCode 这类客户端调用。你在编辑器里干活，背后站着的是带着你知识库和记忆的那个自家专家。

另一个方向是出站。在控制台启用acp_runner后，Octop 专家能在对话里把编程任务委派出去，内置 Runner 覆盖 OpenCode、CodeBuddy、Claude Code、Codex 等，公开资料里还能看到 Kimi Code、Cursor CLI、Pi。前提是这些工具得预先装在跑 Octop 的主机上，并完成各自登录。委派也不是无条件放行，带权限门控的。

octop acp --agent main   # 把自己的专家开放给编辑器 / 终端客户端 # 或在控制台启用 acp_runner，让专家把编码任务委派给 # OpenCode / CodeBuddy / Claude Code / Codex …

这个分工我觉得是顺的：Octop 负责懂你、懂上下文、守在消息通道里，专业编程智能体负责在仓库里干细活。需求在群里提一句，管家先澄清拆分，再转给编程智能体执行，结果回到原对话里。链条不算短，但至少是在你自己机器上转完的。

定时任务底层是 Cron，配置方式倒是照顾了普通人。你可以直接用自然语言说“每天早上八点把天气和日程推到家庭群”，也可以用斜杠命令和可视化界面精确管，CLI 里有octop cron list这类命令。底层调度是 APScheduler，跟消息管线共用入口。说白了，定时任务就是到点替你给指定专家发一句话，早报、巡检、定期汇总、纪念日提醒，都能用这个模型拼。

一个能执行命令、能操作浏览器、手里还握着一堆平台凭据的系统，安全真不是加分项。Octop 官方列的机制包括：JWT 多用户隔离，账号之间默认互不可见；工具审批，专家调用敏感工具前要过权限关，ACP 委派也一样；Shell 命令防护，允许/拒绝规则放在~/.octop/security/tool_guard/，管理员能编辑；还有敏感信息脱敏，尽量别让隐私在输出和日志里裸奔。再加一句老话：改默认密码，公网暴露时更是。

这里我有点保留：机制列出来是一回事，普通家庭用户会不会真的去配命令规则、去开审批，是另一回事。如果默认配置不够严，光靠文档提醒，效果可能有限。这块文档里也没展开讲默认到底严到什么程度，我没法替它下结论。

适合谁，其实不难判断。家里有常开的电脑、NAS 或小服务器，愿意花半小时把初始化走完，又希望全家或小团队共用一套、还介意数据出门的人，值得折腾一下。手里有好几个模型 API 想统一管，或者本身是开发者，想把消息通道、知识库和编程工具串起来的人，也对路。

没必要凑热闹的人也挺明确：没有任何常开设备，也不想买云服务器的；对可用性要求特别高，比如要拿它跑不能断的业务值守的；还有就是只想随手聊聊，根本用不上多用户和自动化的——这种真没必要，直接用个云端 App 更省心，别给自己找事。

真要上手，我的建议是别贪多。第一周就干三件事：用桌面客户端或 Docker 把它跑起来，改掉默认密码，接好一个你最常用的模型，先跟默认专家聊熟。第二步再从专家库挑两三个模板改成自己的，建个小知识库，把常查的资料扔进去。第三步接一个消息通道、设一个定时任务，让它每天能准时露一次面。这三步稳了，再去碰 ACP 委派和远程桌面。还有，高权限专家的审批和命令规则，别等出事了再补，第一天就配上。

有常开的机器、愿意自己管数据和权限的人，Octop 值得花个周末试试；没有常开设备、只想打开就聊的人，就别折腾了，云端产品更适合你。它不是什么都好的东西，就是给“想把助手放自己家里”这件事，提供了一个目前还算完整的开源选项。

wang

写 Home Assistant 智能家居，也写各种 AI 工具的实际用法。不堆参数，只说清楚一件东西到底适不适合你。

觉得这篇有用，点个「赞」和「在看」，或者转给正在折腾 AI 助手的朋友；你家或团队里已经在跑自托管助手了，也欢迎留言说说踩过的坑。

• 项目官方仓库（功能、架构、安装、CLI、通道凭证、ACP、安全机制均以此为准）：github.com/TencentCloud/Octop ；中文说明在该仓库的 README_CN.md
• 项目官网：octop.cloud
• 1.0 GA 与桌面 / NAS 安装包信息：51allai.com/posts/2026/09/tencentcloud-octop-1-ga/
• 上手体验（含专家库、知识库与桌面客户端初始化梳理）：woshipm.com/ai/6466835.html
• 单进程架构与取舍分析：alphasignal.ai/news/tencent-releases-octop-a-self-hosted-multi-user-ai-platform-in-one-process
• 本文为原创解读：功能描述基于上述公开资料归纳概括，未大段复制任何来源原文；文中分工卡片与流转示意为帮助理解的示意，不代表产品真实界面；4 张配图为与主题匹配的定制插画，非产品截图。