【开源】把 NAS 变成 AI 助手，全家共用数据不外传

大多数人的 NAS，24 小时开着，却只干着存电影的活。

你家的 NAS 现在多半在干三件事：存电影、备份照片、挂个下载器。它一年到头不停机，CPU 大部分时间在发呆，电费却一分不少交。

你把一份报价单粘进对话框的那一刻

先看一个场景。

做小生意的老周，想让人工智能帮他整理客户资料。他把一份报价单复制进某个云端助手，问了几个问题，回答挺像回事。三个月后他才知道，那份报价单在对方的服务器上留了一份——什么时候删、删不删，他说了不算。

换到开发者身上，问题更具体。想让 AI 读一遍本地文档库，得先把文档传上去；想让 AI 每天定时汇总行业新闻，得开一个云服务账号；想让家里人一起用，还得一人买一份订阅。

那你当然可以在自己的机器上跑。可真正动手时通常是这样的：装 Python、配虚拟环境、装依赖时某个包编译失败、换镜像源；数据库没起来，前端连不上；最后卡在端口占用上，抬头一看，凌晨一点。

NAS 玩家对这个流程更熟——当初图省事才买的成品 NAS，结果为了一个 AI 助手，又回到了命令行。

Octop：把 AI 装回你自己的机器

Octop 是腾讯云开源的自托管 AI 助手，MIT 许可，支持多用户、多 Agent 协作。据 README，该项目已有 8600 多 Star，当前版本 1.0.2b6，Python 3.12 起。

它不是「又一个聊天界面」。README 的原话是：把配置、对话、工作区和凭据都放在你自己的机器上（默认目录 ~/.octop/），同时给每个用户配一组能按场景切换的专业 Agent。

它跟云端助手最根本的差别，就一个词：在你这里。

一个实例，全家共用：多用户 + 多 Agent

家里几个人共用一套 AI，最容易乱的地方不是钱，是上下文。

你在问工作上的事，孩子拿同一个窗口问作业，历史记录串在一起，谁也不想再用。Octop 的做法是按用户隔离：每个账号有自己的 Agent、自己的供应商配置、自己的通道和定时任务，彼此看不到对方的工作区。

管理员只建一次，家里人各用各的。据 README，它能做到「一人管理，全家共用」，并且每个用户都能创建多个专家角色，各自的工作区、模型供应商、消息通道、定时任务都是独立的。

它还给 Agent 准备了 16 种 MBTI 人格模板。这个设定乍看像花活，但用起来有实际意义：同一个模型，配上不同的系统提示和性格，一个适合写公文，一个适合陪聊，切换成本比重新调提示词低得多。

和同类方案的差别：多数自托管方案默认单用户，多人共用要靠开多个实例、分不同端口；Octop 从设计上就是多用户，一套库、一次部署。

数据放哪儿：本地优先，不经过第三方

自托管这个词被用滥了，值得掰开看它到底管住了什么。

Octop 默认把所有东西放在 ~/.octop/：控制面数据库（默认 SQLite，可换 PostgreSQL）、JWT 密钥与通道 Token、每个 Agent 的工作区、日志，全在这一个目录里。备份、迁移、删除，都是对一个目录做操作，不需要登任何后台。

# 数据根目录，所有内容都在这里 ls ~/.octop/ # agents/  secrets/  logs/  octop.db

权限也是分层的。README 提到做了 JWT 多用户隔离、工具审批、Shell 命令防护和敏感信息脱敏——高风险命令要按护栏规则显式批准才会执行。规则文件在本地，你可以自己改：

# 编辑 Shell 命令的允许 / 拒绝规则 vi ~/.octop/security/tool_guard/

升级路径也考虑到了数据安全：octop update 只替换程序本身，保留 ~/.octop/ 下的数据；README 建议跨版本升级前先跑一次 octop backup。

和同类方案的差别：SaaS 类助手的数据保留策略写在服务条款里，你只能选择接受；这里的保留策略是一个你能 ls 出来的目录。

知识库 + 可迁移记忆：AI 记得住你的事

通用模型最大的短板不是聪明程度，是它记不住你。

Octop 里有两套机制在补这个缺口。

一套是知识库，基于文档的 RAG 检索。把你自己的资料放进去，回答就会锚定在私有语料上，而不是靠模型泛泛而谈。同一实例内还能共享语料，家里人问同一份资料，得到的是同一套答案。

另一套是 Octop Memory，分层记忆加全文检索。它有一个细节挺关键：记忆是随工作区迁移的。意思是换机器、换部署环境时，记忆跟着目录走，不会因为重装一次就清空重来。

记忆会随时间膨胀，所以它配了维护命令，可以先备份再精简：

octop memory list      # 列出可参与维护的 Agent octop memory slim      # 备份并精简记忆库

README 里说明了顺序：先看影响范围，确认无误再加 --confirm 执行，执行期间聊天不受影响。

和同类方案的差别：很多方案的「记忆」是往上下文里塞历史对话，越塞越贵也越乱；这里是独立的记忆层，还能主动瘦身。

微信、飞书、钉钉都能当入口

工具能不能用起来，一半取决于入口顺不顺手。

Octop 支持飞书、钉钉、QQ、微信、企业微信这几类 IM 通道，Web 控制台默认开启。也就是说，家里人不需要记一个网址、也不用来学新界面，在平时用的聊天软件里发消息就行。通道各自需要什么凭据（App ID、App Secret、Bot Token 等）README 里列得很清楚。

更好用的是定时任务。Web UI、IM 消息和定时任务走的是同一条处理链路，所以你可以直接用自然语言描述一个定时任务，也可以走斜杠命令。

octop cron      # 管理定时任务 octop channel   # 安装与管理 IM 通道

举个能立刻用上的例子：每天早上八点让它抓一遍行业新闻，汇总成一份简报，直接推到你微信里。这件事在云端方案里要么做不到，要么得把抓取源交给别人托管。

另外还有浏览器能力和远程桌面。浏览器会话基于 Chromium，可以做网页自动化和截图；远程桌面允许你在控制台里看屏并操作键鼠，覆盖 Linux、Windows、macOS。

和同类方案的差别：多数自托管助手给你一个 Web UI 就结束了；这里把你已经在用的聊天软件直接变成入口。

还能把编码任务丢给别的 AI

如果你平时用 Claude Code、Codex 这类编码工具，Octop 里有个容易被忽略的能力：ACP（Agent Client Protocol）。

它是双向的。

向内，Octop 可以把你的 Agent 提供给 IDE 和终端工具用：

octop acp --agent main

向外，你可以在对话里把编码任务委派出去。内置的出站 Runner 包括 OpenCode、CodeBuddy、Claude Code 和 Codex 四个，在控制台的 ACP 页面配置一次，之后在对话里就能直接调。

这解决的是真实工作流里的断裂感：写文档、查资料、改代码，本来要在三个窗口之间来回切换，现在可以在一个对话里完成，需要重度编码时再交给专门的工具。

和同类方案的差别：别的助手是终点，任务到它就停了；这里可以是一个中转站，把不擅长的那部分转交出去。

快速上手：三条命令跑起来

最短路径是 pip 安装，装完直接初始化：

pip install octop    # 需要 Python 3.12+ octop init           # 向导：建库、生成密钥、建管理员 octop run            # 启动 API + Web 控制台

默认访问 http://127.0.0.1:8088。octop init 是交互式的，会依次建好 SQLite 数据库、JWT 密钥和第一个管理员账号。

macOS / Linux 也可以走一行脚本安装，脚本会在 ~/.octop/venv 里建隔离环境，不动系统的 Python：

curl -fsSL https://finnie-1258344699.\ cos.ap-guangzhou.myqcloud.com/octop/install.sh | bash

装完记得开一个新终端，或重新加载 shell 配置，让 octop 进入 PATH。

NAS 和容器场景走 Docker，这是最省心的方式：

docker compose -f \   docker/docker-compose.yml up -d

想自己构建镜像也可以：

docker run -d -p 8088:8088 \   -v octop-data:/data/.octop \   -e HOME=/data octop:latest

第一次启动会生成一个随机管理员密码，写在 /data/.octop/credential.txt 里。如果不喜欢随机密码，用 OCTOP_DEFAULT_PASSWORD 环境变量指定，注意至少 8 位、且字母数字都要有。

对飞牛 FnOS 用户还有个更直接的选项：官方提供了 .fpk 安装包，可以在应用中心直接装，ARM 设备建议用 Docker 版，x86_64 也有免 Docker 的原生包。桌面端 Windows、macOS、Linux 都有原生客户端，不想碰终端的话直接下载安装就行。

顺手提醒一句：如果只是先试试，octop run 默认只监听本机；要给别人访问，再显式指定监听地址。

架构：故意做成单进程

回头看它的设计，有一个决定挺有意思：不引入外部消息队列和中间件。

README 的架构说明里，所有入口——Web UI、IM 消息、定时任务——都通过进程内的 HarnessProcessor 统一路由。默认用本地 SQLite（WAL 模式），需要时可以切 PostgreSQL；重启后从控制面数据库重建状态。

这意味着部署时少了一堆要维护的部件，也不用担心「消息队列挂了但 Web 还活着」这种半死不活的状态。

代码层面它拆成了四个可独立理解的子项目：

• Octop Harness
   —— Agent 运行时，负责模型路由、工具、技能和对话检查点
• Octop Gateway
   —— 多平台 IM 桥接，把各类入站消息归一成统一管线
• Octop Memory
   —— 分层召回与全文检索
• Octop Browser
   —— 基于 CDP 的浏览器自动化，支持持久化登录配置

技术栈也很常规：Python 3.12 + FastAPI + uvicorn，前端 React 18 + TypeScript + Vite。没有为了炫技引入冷门框架，这一点对打算长期自托管的人反而是好事——出了问题能自己查。

最后

它最打动我的不是功能列表，而是那个目录：~/.octop/。

你所有的对话、资料、凭据都在那里，备份是一个 cp，删除是一个 rm，迁移是拷一个文件夹。这种确定性，是云端订阅给不了的。

截至发稿，Octop 仍在快速迭代，README 的路线图里 AgentTeams 处于 Beta，移动端在内测，插件市场还在规划中。也就是说，现在的版本能干活，但还不是终点。

如果你也是那种把数据看得比较重的人，或者手上正好有台常年开机的 NAS 想给它找点正经活干，这个项目值得花半小时装一次。装完先别急着配置复杂功能，就用它把明天的新闻简报跑出来——跑通一次，你就知道它值不值得留下来了。