腾讯云开源了 Octop，一个面向个人、家庭和小团队的自托管 AI 助手。它不是只在网页里提供一个聊天入口，而是把多用户、多 Agent、长期记忆、知识库、即时通信、定时任务和浏览器操作放进同一套本地系统。
项目发布 v1.0.1 时，GitHub 已获得约 4,200 个 Star。这个增长速度说明需求很明确：很多人想要的不只是一个会回答问题的模型，而是一套可以长期运行、多人使用、能接入真实工作入口的 Agent 基础设施。
#一台机器上的 Agent 团队
Octop 的核心抽象不是「一个用户对应一个助手」，而是每个用户都可以拥有多个 Agent。每个 Agent 有独立的工作区、模型提供商、渠道和定时任务，还能从专家库里选择不同角色。
这让它更像一个共享的 Agent 工作站：管理员维护一套部署，家庭成员或团队成员分别使用自己的 Agent；写周报、整理资料、管理日程、网页操作等任务，可以交给不同专家处理。系统也提供 16 种 MBTI 人格模板，但真正有用的部分不是人格标签，而是角色配置可以复用和切换。
#Web、聊天软件和自动任务共用一个控制面
Octop 同时提供 Web 控制台、CLI、HTTP/SSE/WebSocket 接口，并能接入飞书、钉钉、QQ、Discord 和企业微信。无论请求从网页、群聊还是定时任务进入，最终都会走同一条处理链路。
Octop Web 控制台，可管理聊天、Agent、连接器、渠道、定时任务、知识库与插件
控制台把聊天、Agent、连接器、消息渠道、Cron、知识库、插件和 ACP 集中到一起。对普通用户来说，这比单独配置模型、机器人、定时器和知识库更接近一个完整产品；对团队来说，也意味着权限和运行状态有了统一入口。
#单进程是它最明确的架构选择
Octop 采用 Python 与 FastAPI 构建后端，前端使用 React。默认用 SQLite 保存控制面数据，也可以切换 PostgreSQL。Agent runtime、消息网关、记忆、浏览器自动化和定时调度被组合进一个进程，不依赖额外的消息队列。
这个选择的好处是部署简单：一次启动就能得到 Web、CLI、聊天渠道和定时任务；重启后，系统从控制面数据库恢复用户、Agent 与任务状态。对于个人和小团队，自托管产品最大的敌人往往不是功能不足，而是组件太多、维护成本太高，Octop 明显优先解决了这个问题。
代价也同样清楚。单进程把故障域和资源竞争集中在一起，适合一台机器上的轻量协作，但尚不是面向大规模并发的分布式调度架构。项目路线图里的 AgentTeams、共享资源池和专家共享，会进一步考验这套模型。
#记忆、知识库与插件形成可迁移能力层
Octop 的长期能力不只来自对话记录。它把记忆与工作区绑定，支持全文检索；知识库通过 RAG 检索私有文档；插件与 Connector 则负责连接外部资源。工作区可以落在本地磁盘、Docker、PostgreSQL 或兼容 S3 的对象存储上。
这种设计想解决的是 Agent 的「换入口不换脑子」：同一个 Agent 可以在网页里对话，也可以从飞书收到任务，记忆和工具仍跟着工作区走。项目把配置、聊天、工作区和凭据保存在本机目录中，并提供多用户 JWT 隔离、敏感信息脱敏、工具审批和 Shell 命令规则。
#ACP 让 Octop 既能被调用，也能向外委派
Octop 支持双向 ACP。向内，Zed、OpenCode 等外部工具可以把 Octop Agent 当作可调用的服务；向外，Octop 又能把编码任务委派给 CodeBuddy、Claude Code、Codex 等外部编码 Agent，并在执行前经过权限控制。
这使 Octop 不必自己包办所有能力。它更像一个常驻控制面：负责用户、身份、渠道、记忆与任务入口，再把专业执行交给合适的 Agent。相比把所有工具塞进单个超级助手，这种双向连接更容易扩展，也更符合多 Agent 系统逐步分工的方向。
#现在适合谁
Octop 当前最适合三类人：希望数据留在本机、但不想手工拼装整套 Agent 服务的个人；需要共享一台部署的家庭或小团队；以及想把网页、即时通信和定时任务统一到一个 Agent 控制面的开发者。
它已经覆盖安装、升级、备份、桌面端、Docker 和多平台消息入口，产品完整度高于许多只展示 Agent Loop 的开源项目。不过，路线图中的团队自动编排、自我进化和跨用户专家共享仍未完成。现在的 Octop 更像一台功能齐全的「Agent 工作站」，而不是已经解决大规模自治协作的 Agent 操作系统。