Octop：一个跑在 ~/.octop/ 里的多用户 AI 助手平台

场景：一个家庭、一台机器、五个 Agent 同时干活

想象这个场景：你在家里的服务器上跑了一个进程。你的伴侣在飞书上问它"今天天气怎么样"，它在飞书里回答；你妈在钉钉上问它"帮我查一下医保"，它在钉钉里回答；你在 Discord 上让它"帮我跑一段 Python 代码"，它在终端里执行并返回结果。五个 Agent，五个用户，三个 IM 平台，一个进程，所有数据都在 ~/.octop/ 目录下。

这就是 TencentCloud 的 Octop 想做的事。

386 颗星一天涨上来，不如 BrowserSkill 的 1350 颗那么炸裂，但 Octop 解决的问题完全不同：BrowserSkill 是"让 Agent 用你的浏览器"，Octop 是"让一个进程服务全家/全团队的 AI 需求"。

"数字生命体"：从一个工具到一个物种

Octop 的 README 里有一句话很扎眼："It's not just a tool — it's a digital life form that can operate in parallel."

"数字生命体"这个说法有点夸张，但它指向一个真实的设计选择：Octop 不是一个单线程的 chatbot，而是一个多 Agent 并行运行的系统。

具体来说，Octop 的架构是：

• 单进程：一个 octop run 启动所有东西——web dashboard、CLI、IM channels、cron。不需要 docker-compose，不需要微服务编排。
• 多用户：JWT 做用户隔离，一个 admin 管理全家/全团队，其他用户共享同一个进程但拥有独立的工作空间。
• 多 Agent：每个用户可以同时跑多个 Agent，Agent 之间可以协作（ACP 双向通信）。
• 多渠道：Web Dashboard、飞书、钉钉、QQ、Discord、企业微信、HTTP/SSE/WebSocket，所有渠道共享同一个控制面。

这个架构的核心洞察是：家庭和小团队的 AI 助手需求，不是"一个更强的 chatbot"，而是"一个能同时服务多个人、多个渠道的 AI 基础设施"。

MBTI 人格模板：给 Agent 一个"性格"

Octop 有一个很奇特的功能：16 个 MBTI 人格模板。你可以给每个 Agent 分配一个 MBTI 类型，比如 INTJ 的 Agent 偏向逻辑分析，ENFP 的 Agent 偏向创意发散。

这个功能乍看像噱头，但仔细想想有道理。LLM 的"人格"本质上是 system prompt 的产物。不同的 system prompt 会让同一个底层模型表现出截然不同的行为模式。MBTI 模板本质上是预设的 system prompt 集合，让用户不需要自己写 prompt 就能得到不同性格的 Agent。

这和 OpenAI 的 GPTs、Anthropic 的 Claude personas 是同一个思路：把 system prompt 工程产品化。区别在于 Octop 把 16 个 MBTI 类型作为默认选项，而不是让用户从零开始写。

"所有数据在 ~/.octop/"：隐私作为默认选项

Octop 最核心的设计约束是：所有数据留在本地。README 里反复强调"all data under ~/.octop/"。

这个约束带来几个设计后果：

1. SQLite 默认：不需要装 PostgreSQL，开箱即用。PostgreSQL 是可选的，用于更大规模的部署。
2. 可插拔后端：本地磁盘、Docker 容器、PostgreSQL、COS/S3，四种后端可选。Agent 在隔离的边界内操作。
3. PII 脱敏：工具调用时自动脱敏个人身份信息。
4. Shell 命令护栏：Agent 执行 shell 命令前需要审批。

这些设计合起来，构成一个"隐私优先"的 AI 助手架构。对比 OpenAI ChatGPT、Anthropic Claude、Google Gemini 这些云端方案，Octop 的卖点是：你的对话、工作空间、凭证，全部在你自己的机器上。

Connector 生态：腾讯系全家桶 + OAuth + MCP

Octop 的 Connector 系统支持三类集成：

1. 腾讯系：腾讯文档、微博热搜、腾讯新闻等。这是 TencentCloud 出品的天然优势。
2. OAuth 网关：通用 OAuth 集成，可以接入任何支持 OAuth 的服务。
3. MCP 网关：Model Context Protocol，可以接入任何 MCP 兼容的工具。

MCP 支持是关键。MCP 正在成为 Agent 生态的标准协议（Anthropic 推出，OpenAI、Google 跟进）。Octop 通过 MCP 网关，理论上可以接入任何 MCP 兼容的工具，这大大扩展了它的能力边界。

ACP 双向：让 Agent 调用 Agent

Octop 的 ACP（Agent Communication Protocol）双向通信是一个亮点功能。octop acp 命令让 Octop 可以和 IDE/终端里的 AI（比如 OpenCode、Claude Code）双向通信。

这意味着什么？你可以在 Octop 的 web dashboard 里发起一个任务，Octop 把它委托给 IDE 里的 Claude Code 执行，Claude Code 的结果再回流到 Octop 的对话里。Agent 不再是孤岛，而是可以互相委托任务。

这个设计让我想起 Unix 的 pipe：cat file | grep pattern | sort。每个工具做好一件事，通过 pipe 串联。ACP 本质上是"Agent 之间的 pipe"，让不同 Agent 可以分工协作。

和其他自托管 AI 助手的对比

Octop 的差异化在于：它不只是 chatbot，而是一个"AI 操作系统"。远程桌面、浏览器自动化、终端 AI、IM 集成、cron 定时任务——这些功能让它更像一个"数字员工"，而不是一个"聊天窗口"。

适用场景与局限

Octop 最适合的场景：

• 家庭/小团队：3-10 人共享一个 AI 助手，需要多渠道接入。
• 隐私敏感场景：医疗、法律、财务，数据不能上云。
• 多 Agent 协作：需要不同 Agent 分工处理不同任务。
• IM 为主渠道：团队主要在飞书/钉钉上沟通。

局限：

• 单机部署：不支持分布式。所有 Agent 跑在一个进程里，扩展性有限。
• 腾讯系偏向：Connector 生态偏腾讯系，非腾讯系用户可能觉得不实用。
• Python 3.12+：版本要求较高。

深层洞察：从"个人 AI 助手"到"家庭 AI 基础设施"

过去两年的 AI 助手产品，绝大多数是"个人助手"：一个用户、一个对话窗口、一个 Agent。Octop 提出了一个不同的方向：家庭/小团队共享的 AI 基础设施。

这个方向的挑战在于：多用户隔离、多渠道接入、多 Agent 协作——这三个"多"加起来，复杂度远超单用户 chatbot。Octop 用"单进程 + JWT 隔离 + MCP 网关"的组合给出了一个可行的方案。

"所有数据在 ~/.octop/" 这个设计约束，是对"云端 AI"范式的反叛。它假设：有一群用户，他们愿意用便利性换取隐私。这群人是不是足够多，决定了 Octop 能走多远。

Octop 的 GitHub 仓库在 https://github.com/TencentCloud/Octop ，MIT 协议，pip install octop 即可上手。如果你有一个家庭服务器或小团队服务器，且想要一个"所有数据都在自己手里"的 AI 助手平台，Octop 是目前最完整的方案之一。

"一个进程服务全家"这个概念，可能会成为自托管 AI 助手的新标准。就像家庭路由器一样——你不需要每个房间都装一个，一个就够了。