Octop

Octop 是什么

Octop 是腾讯云开源的一款自托管 AI 助手，前身为此前备受关注的 LightClaw ACE 项目，目前以 MIT 开源协议向所有人免费开放。与大多数把对话能力锁在云端的 AI 产品不同，Octop 的定位是”装在你自己机器上的 AI 助手”：它在单个进程里同时提供 Web 控制台、命令行界面（CLI）以及覆盖微信、QQ、企业微信、飞书、钉钉、Discord、Telegram 等九大主流平台的 IM 通道，你可以任选一种方式与自己部署的 AI 对话，而所有数据都留在本地。

这个定位决定了 Octop 的几个关键特性。首先是单进程架构：不需要 Kubernetes、不需要一堆微服务，一台普通个人电脑甚至一台家用 NAS 就能完整跑起来，部署和维护成本极低。其次是多用户隔离：Octop 面向家庭与小团队设计，通过 JWT 做身份与会话隔离，同一台机器上可以有多个彼此看不到对方数据的用户共用一套服务。第三是以”专家”为单位的多 Agent 架构：你不是在跟一个万能机器人说话，而是在调度一组各司其职的专家，每个专家都能配置底层模型、技能包、知识库乃至 MBTI 人格。

对于不希望把私人对话、公司内部资料交给第三方云服务的用户来说，Octop 提供了一条非常稀缺的路径：能力来自近 20 家主流大模型厂商，但控制权完全在自己手里。如果你正在系统性梳理这类可以自己部署的方案，可以参考 AI开源方案库 与 openloong开源社区 中收录的同类项目，Octop 是其中少见的”开箱即可日常使用”的那一类。

Octop 项目官网首页

Octop 的主要功能

从功能矩阵来看，Octop 已经不只是一个”能的本地模型壳子”，而是一套相对完整的个人与团队 AI 操作系统。它把模型接入、Agent 编排、知识库、自动化、终端控制与外部应用连接器打包在了一起，目标是让 AI 助手真正从”回答问题”走向”完成任务”。

这里的关键分野在于：一个只会的助手，价值上限取决于模型有多聪明；而一个能调技能、查知识库、操作终端、驱动浏览器、按计划自动执行的助手，价值上限取决于你愿意把多少流程交给它。Octop 把后面这些”动手能力”都做成了内置模块，并且统一收敛到”专家”这个概念之下，用户不需要理解复杂的编排语法，只需要决定”这个专家负责什么、能用什么工具、该是什么脾气”。

下面按模块梳理它的核心能力：

1. 多 Agent 的”专家”体系：系统以专家（Expert）为基本单位，每个专家是一个的 AI 助手，拥有自己的模型、技能、知识库和人格设定，支持并行工作，能力可以按需无限扩展。你可以让一个专家负责写代码、一个专家负责整理会议纪要、一个专家负责盯告警，互不干扰。
2. 16 种 MBTI 人格模板：内置 16 种 MBTI 人格模板，并支持通过心理测试进行推荐。给专家赋予人格不只是为了好玩，不同人格会明显改变它的表达风格、追问习惯和风险偏好，让交互更贴合具体岗位。
3. 九大 IM 平台原生接入：原生打通微信、QQ、企业微信、飞书、钉钉、Discord、Telegram 等主流即时通讯平台，不需要额外搭建桥接服务，装好就能在最常用的软件里与专家对话。
4. 自然语言 cron 定时任务：不需要手写 crontab 表达式，直接用自然语言描述”每周一早上九点把上周的项目进展整理成一份周报发给团队”，系统会自动转成定时计划并按期执行。
5. RAG 知识库与可点击引用：支持把本地文档灌入知识库做检索增强生成，回答中带可点击的引用来源，能直接跳回原文核查，避免”一本正经地胡说”。
6. ACP 协议委派编程智能体：通过 ACP 协议把编程任务委派给 Claude Code、OpenCode 等编程智能体执行，Octop 负责任务编排与结果回收。
7. 浏览器内交互式终端 AI：在 Web 控制台里直接开一个可与 AI 交互的终端，边敲命令边让 AI 解释、补全、纠错。
8. 无头浏览器自动化：内置无头浏览器能力，让专家可以自己打开网页、填表、抓取信息，完成需要”上网操作”的任务。
9. 远程桌面与手机操控：支持远程桌面控制，扩展了专家可触达的操作面，适合做服务器巡检、远程协助一类的工作。
10. 23+ 应用连接器：内置腾讯文档、Notion 等 23 个常用应用的连接器，把 AI 直接接进你已有的工作流和资料库。
11. Token 用量统计：提供细颗粒度的 Token 用量统计，多个模型、多个用户、多个专家的消耗一目了然，方便控制成本。
12. 八爪鱼萌宠悬浮窗：一个常驻桌面的八爪鱼萌宠悬浮窗，随时呼出、随时对话，是整个产品最具辨识度的交互入口。

单独看，这些功能在别处也能找到；把它们放在同一个自托管进程里，才是 Octop 的独特之处。举个典型的串联用法：你用自然语言设置一条每周一早九点的定时任务，任务触发后，负责”周报”的专家先通过连接器读取腾讯文档里的项目表格，再从知识库检索本周的会议记录（回答中带可点击引用），草稿生成后交由另一个负责”润色”的专家改写，最后通过企业微信推送给团队，并把本次调用的 Token 消耗记进用量统计。整个过程不需要你在任何一个环节守着电脑。

这也解释了为什么 Octop 要把 IM 通道放到与 Web 控制台同等重要的位置：真正高频的协作发生在软件里，而不是在一个需要专门打开的网页里。把 AI 塞进用户本就每天打开几十次的 IM，才谈得上”随时可用”。

Octop 的「专家」架构、数据存储与隐私设计

Octop 的架构可以拆成三层来理解。最上层是交互层，也就是 Web 控制台、CLI 和九大 IM 通道，它们共享同一套后端能力，你在手机微信里发起的任务，可以回到 Web 控制台里查看完整执行过程。中间层是专家编排层，负责把用户请求路由给合适的专家、调度技能与知识库、管理定时计划，并通过 JWT 做多用户隔离。最底层是模型与数据层，模型侧支持近 20 家主流 LLM 提供商，可以切换；数据侧全部落在本地的 ~/.octop/ 目录，默认使用 SQLite 存储，也可以按需切换到 PostgreSQL。

这种设计带来的直接好处是数据的回归：对话历史、知识库文档、任务记录、Token 账单都在你自己的磁盘上，不依赖任何第三方云服务，也就从根本上消除了数据外泄的风险。对家庭用户来说，这意味着家庭成员各自的 AI 会话彼此隔离；对小团队来说，意味着内部资料不必出内网就能获得大模型能力。

在模型侧，Octop 保持中立：它不绑定任何一家厂商，支持近 20 家主流 LLM 提供商的模型切换。这个设计在实践中有两个直接收益。其一，你可以按任务类型分配模型——简单的格式整理用便宜的小模型，复杂的推理与写作用强模型，成本与效果可以分别优化。其二，当某家厂商调价、限流或服务不稳定时，切换模型只是改一次配置的事，不会被单一供应商锁死。对自托管产品来说，这种”不被绑定”本身就是一种长期安全感。

在可扩展性上，Octop 走的是”可插拔”路线：技能包、连接器、知识库、人格模板都是可以增删的插件式单元，你可以只启用自己需要的部分，也可以按照自己的业务习惯重新组合。对有二次开发需求的团队来说，MIT 协议意味着你可以直接改源码、做内部定制、甚至把它嵌入到自有产品里，而不必担心授权问题——这一点是闭源助手产品无论如何也提供不了的。

值得补充的是，Octop 并不是要取代那些成熟的云端智能体平台，而是给了一个”把同样的能力搬回本地”的选项。如果你更习惯直接在云上搭建，可以看 ArkClaw智能体、Coze智能体 这类方案；而如果你关心的是代码侧的 Agent 体验，Trae智能体 也是常见的搭配。Octop 的独特之处在于它把这些能力以开源、自托管的方式打包到了一起。

Octop 在 GitHub 上的开源仓库

如何使用 Octop

Octop 的安装流程对非专业用户是友好的：官方把环境准备、依赖安装、初始化向导都做了封装，你只需要按顺序执行几条命令。下面以类 Unix 系统为主说明，Windows 用户把对应命令放到 PowerShell 中执行即可，步骤完全一致。

Octop 的安装被压缩成了三步，全程不需要手动装依赖。类 Unix 系统（Linux、macOS）使用一键安装脚本，Windows 用户则通过 PowerShell 完成同样的流程。

1. 执行一键安装脚本：在终端中运行 curl -fsSL https://finnie-1258344699.cos.ap-guangzhou.myqcloud.com/octop/install.sh | bash；Windows 平台在 PowerShell 中执行对应的安装命令即可。脚本会自动完成运行环境与依赖的准备。
2. 初始化与创建管理员：安装完成后执行 octop init 进入初始化向导，按提示设置管理员账号。系统默认账号为 admin、默认密码为 octop，首次登录后务必立即修改密码，这是自托管服务最基本的安全动作。
3. 启动并访问控制台：执行 octop run 启动服务，随后在浏览器打开 http://127.0.0.1:8088 即可进入 Web 控制台。

执行完这三步，你就已经拥有了一个能对话、能建专家、能接 IM 的本地 AI 助手。不过要想让它真正干活，还需要做一轮初始配置。建议按下面的顺序走一遍，大约十几分钟就能把 Octop 调成顺手的样子：

1. 在模型配置中填入你已有的 LLM 服务商密钥，从近 20 家主流模型提供商中挑选并绑定需要的模型，可以为不同任务指定不同模型。
2. 创建第一批专家，为每个专家设置职责描述、挂载技能包、绑定专属知识库，并从 16 种 MBTI 人格模板中挑一个顺眼的。
3. 绑定 IM 通道，把专家接到微信、企业微信、飞书或钉钉上，这样你不用打开浏览器也能随时使唤它。
4. 建立知识库，把常用的产品文档、项目资料、操作手册灌进去，开启可点击引用后回答的可核查性会明显提升。
5. 配置定时任务与连接器，用自然语言写几条周期性的自动化流程，并把腾讯文档、Notion 等应用接进来。

日常使用时，你可以在网页、命令行或者任意已接入的软件里发起任务，实时查看执行进度，并在需要时随时人工介入接管——这一点对自动化任务尤其重要，因为”能随时踩刹车”是敢不敢把事情交给 AI 的前提。建议在运行一段时间后，定期查看内置的 Token 用量统计，按专家和用户维度核对消耗，避免某个失控的定时循环悄悄烧掉预算。

运维方面有几个小建议：一是把 ~/.octop/ 目录纳入常规备份计划，这里存放着全部对话、知识与配置；二是如果团队规模增长、并发变多，可以把默认存储从 SQLite 切换到 PostgreSQL 以获得更稳定的并发表现；三是升级前先备份配置与数据，再按官方仓库的发布说明执行更新。由于是本地服务，若想在访问，请务必配合反向代理与强密码，不要直接把 8088 端露在公网。

Octop 的使用场景

由于同时具备本地部署、多用户隔离、IM 接入与自动化执行能力，Octop 的适用面比单纯的”本地框”要宽得多。下面按使用者类型梳理几类最典型的落地方式：

1. 个人效率助手：处理表格、写周报、整理读书笔记、做资料摘要，是它最轻量也最高频的用法。配合 豆包输入法 这类输入侧工具一起使用，从文字输入到内容生成可以形成一条完整的个人工作流。
2. 家庭共享管家：一台常开的机器即可支撑全家使用，多用户隔离保证每位成员的对话与数据互不可见，可以分别扮演日程提醒、作业辅导、菜谱推荐、家庭账目整理等不同角色。
3. 小团队协作中枢：通过企业微信、飞书或钉钉接入，自动分发任务、汇总会议纪要、跟踪项目进度，把团队沟通群里散落的信息沉淀成结构化记录。
4. 开发者编程搭子：借助 ACP 协议把编程任务委派给 Claude Code、OpenCode 等编程智能体，用 Octop 做任务编排与结果验收，同时用它排查线上报错、阅读陌生代码库。
5. 运维自动化值守：配合定时任务、终端 AI 与远程桌面能力，做集群巡检、日志异常主动告警、故障初步定位，充当一位全天候在线的”集群医生”。
6. 资料与文档处理流水线：把 RAG 知识库与文档解析能力串起来，批量处理扫描件、PDF 与网页资料。若你的资料以 PDF 为主，可以与 MinerU 开源高质量数据提取工具、olmOCR 从 PDF 中提取文字的开源 AI 工具 配合，先把文档结构化再灌入知识库。
7. 跨应用流程自动化：用 23+ 连接器把腾讯文档、Notion 等应用串起来，配合自然语言定时计划搭建轻量自动化。若你需要更重的工作流编排，可以对照 n8n 开源工作流自动化平台 的思路扩展。
8. 桌面与设备控制：借助浏览器内终端、无头浏览器与远程桌面能力，处理需要”动手操作”的任务。这一方向上，AI控制电脑 GLM-PC 多模态 Agent 智能体 提供了另一种技术路线，可以与 Octop 互为参照。
9. 隐私敏感行业的内部助手：法务、医疗、金融等场景中，资料往往不允许外发。Octop 的自托管特性让这类团队可以在不出内网的前提下使用大模型能力，同时用 JWT 多用户隔离保证不同岗位之间的数据边界。
10. 教育与自学陪练：用不同 MBTI 人格的专家扮演不同的教学角色——一个负责严格纠错、一个负责鼓励式讲解、一个负责出题测验，把单一对话拆成多角色互动，学习体验会明显不同。

可以看出，这些场景的共同点是：任务本身需要长期记忆、需要访问私有资料、需要周期性执行，而使用者又不希望把这些东西交给一个陌生的云端服务。这正是 Octop 这类自托管 AI 助手最能发挥价值的地方。

Octop 与开源工具生态的搭配思路

把 Octop 用顺手之后，很多人会自然地把它和手头已有的开源工具拼起来，形成一条更完整的流水线。这里提供几种经过验证的搭配方向，供你按自己的实际需要取舍。

1. 文档解析 + 知识库：Octop 的 RAG 知识库解决的是”检索与引用”，但它并不负责把难啃的原始文件变成干净文本。如果你的资料以 PDF、扫描件、表格为主，可以先用 MinerU 开源高质量数据提取工具 或 olmOCR 开源 PDF 文字提取 AI 工具 做结构化提取，再把结果灌进知识库，检索质量和引用准确度都会明显提升。
2. 定时任务 + 工作流编排：Octop 的自然语言定时任务适合轻量、单点的周期事务；如果你需要的是多分支、带条件判断、跨系统串联的复杂流程，可以参考 n8n 开源工作流自动化平台 的编排思路，让 Octop 负责”理解与生成”，由工作流引擎负责”调度与可靠执行”。
3. 本地助手 + 云端智能体：涉及私密资料的任务交给本地 Octop，涉及公开信息检索、高并发对外服务的任务交给 ArkClaw智能体、Coze智能体 一类的云端平台，两者按数据敏感度分工，是实践中比较务实的组合方式。
4. 编程任务分流：日常代码问答直接在 Octop 内完成，遇到需要长时间自主改写的大工程，则通过 ACP 协议委派给编程智能体执行，Octop 保留任务记录与结果验收，避免上下文丢失。

总的来说，Octop 最适合扮演”私有数据与私有流程的中枢”，而不是包打天下的唯一工具。把它放在需要隐私与可控性的那一环，其余环节交给更专业的开源组件，整体效果往往比强求一体化更好。

Octop 的常见问题解答

Octop 是免费的吗？需要付费订阅吗？

Octop 本身以 MIT 开源协议发布，源码完全开放、可使用、修改与二次开发，不存在订阅费用，也没有功能的”社区版/企业版”之分。需要注意的是，Octop 是模型的中立容器，调用第三方大模型服务时仍需要你自备 API 密钥，并自行承担对应厂商的 Token 费用；系统内置的 Token 用量统计正是为了帮助你把这块成本看清楚。因此准确的说法是：软件免费，模型调用按你所选用厂商的标准计费。

我的对话和文件会不会上传到云端？

不会。Octop 是自托管架构，所有对话历史、知识库文档、任务记录和用量数据都存储在你本地的 ~/.octop/ 目录中，默认使用 SQLite，也可切换为 PostgreSQL。模型请求会发往你所配置的 LLM 服务商，这是唯一的外发数据，选择哪家模型、外发什么内容完全由你决定。换句话说，Octop 的开发者和运营方并不保存你的任何数据，”数据在哪里”这个问题由你自己回答。如果连模型请求都不希望外发，理论上也可以接入本地运行的开源模型，只是需要你自行准备推理环境。

我不会写代码，能装上 Octop 吗？对机器配置要求高吗？

可以。Octop 采用单进程架构，安装流程被压缩成”一键脚本 → octop init → octop run”三步，Windows 用户使用 PowerShell 同样可以完成，全程不需要手动配置依赖，普通个人电脑即可运行。初始化的默认账号为 admin、密码为 octop，首次登录后请立即修改。日常使用也不需要写代码，Web 控制台和 IM 通道已经覆盖了绝大多数操作；只有在接入新模型、编写自定义技能时才需要一点编程基础。

Octop 与同类工具对比

把 Octop 放到当前 AI 助手市场里看，它与科大讯飞 Loomy、字节跳动豆包工作台走的是三条截然不同的技术路线。Loomy 侧重零配置的桌面端开箱即用，豆包工作台深度绑定字节的云端生态与豆包大模型，而 Octop 把选择权完整交还给用户。

换个说法就是：Loomy 卖的是”省心”，豆包工作台卖的是”协同”，而 Octop 卖的是”可控”。省心意味着你不需要做任何决定，代价是能力边界由厂商划定；协同意味着你能无缝接入一整套办公生态，代价是被这套生态绑定；可控意味着所有决定——用哪家模型、数据存在哪、能调用哪些工具、能触达哪些应用——都由你自己做，代价是你要承担部署与维护的工作量。三条路线没有优劣，只有是否匹配你的真实约束。

对于已经在用讯飞或字节生态的团队，贸然换成 Octop 并不划算；但对于那些”想用大模型又不敢把资料传出去”的团队，Octop 几乎是唯一既能满足合规、又不牺牲能力丰富度的选择。

如果需要更直观地了解两条对照路线，可以进一步查看 科大讯飞Loomy、讯飞loomy 以及 豆包工作 字节跳动企业级AI智能体平台 的详细介绍。三者并非简单的替代关系，更像是”本地可控 / 桌面轻量 / 云端协同”三种取向。

Octop 官网网址

Octop 项目官网：https://octop.cloud/

Octop 开源仓库（GitHub）：https://github.com/TencentCloud/Octop

你可以通过官网了解产品概览、功能介绍与最新动态，也可以直接前往 GitHub 仓库阅读源码、查看安装文档、提交 issue 或参与贡献。由于项目以 MIT 协议开源，仓库里同时提供了完整的部署说明，遇到问题时建议优先查阅仓库的 issue 区与发布记录，那里通常能找到同类环境的解决方案。

如果你只是想先看看它长什么样，也可以跳过安装，直接浏览官网的产品介绍与界面演示；若决定自用，按上文”三步安装”执行后访问 http://127.0.0.1:8088 即可开始配置。

OpenI AI时代点评

具体地看”专家”这个抽象：它把模型、技能、知识库、人格四件事打包成一个可命名的角色，本质上是在用人类熟悉的组织方式来组织 AI 能力。你不需要理解函数调用、上下文窗口、向量检索这些概念，只要能说出”这个专家负责盯线上告警，性格要谨慎保守”，就能得到大致想要的效果。这种把技术复杂度藏在人类直觉之下的做法，是自托管工具能否走出极客圈子的关键。

Octop 有意思的地方不在于它又做了一个界面，而在于它把”AI 助手”这件事的部署形态重新拉回了用户自己手里。当大多数产品都在比拼云端能力时，它用 MIT 协议、单进程架构和本地存储给出了另一种答案：能力可以来自任意一家模型厂商，但数据、流程和控制权都留在本地。这种取向天然会牺牲一部分开箱即用的顺滑感，却换来了极客、开发者和注重隐私的小团队最在意的可控性与上限。

从工程角度看，Octop 的几个设计判断相当务实：用单进程降低部署门槛，用”专家”把多 Agent 拆解成普通人也能理解的概念，用 MBTI 人格把抽象的模型差异转化成可感知的交互体验，再用九大 IM 通道把 AI 塞进用户本来就高频使用的软件里。尤其是自然语言定时任务与可点击引用的 RAG 知识库，这两项直击了 AI 助手从”能聊”走向”能干活”的关键——前者让周期性事务真正自动化，后者让生成结果可核查。

当然也必须看到它的适用边界。Octop 不是一个”装上就完事”的消费级产品：你需要自己准备模型密钥、自己维护服务进程、自己承担升级与备份，遇到问题时也更多依赖 GitHub 社区而非厂商工单。对于只想快速获得一个能的助手、且数据并不敏感的普通用户，轻量桌面产品或云端平台反而更合适。换句话说，Octop 的价值与你愿意投入的运维精力成正比。

当然，自托管从来不是没有代价的：你需要自己准备模型密钥、自己维护服务、自己承担升级与备份。但对于那些既想要大模型能力、又不愿意把内部资料交出去的团队来说，Octop 提供了一个几乎无需纠结的选择。随着连接器生态与技能包的持续丰富，这类开源自托管 AI 助手很可能成为企业级 AI 落地中一条越来越重要的支线——如果你正在评估类似方案，不妨把它与 AI开源方案库 中收录的其他开源项目放在一起比较。