2026 年 7 月 8 日，腾讯云在 GitHub 建了一个叫 Octop 的仓库。截至 10 月 9 日，它累积 8189 个 star、992 个 fork，MIT 协议，主语言 Python，最新版本号是 v1.0.2b6。它的自我定位只有一行：一个更聪明的、自托管的 AI 助手，多用户、多智能体。
与之并列的是 WorkBuddy。腾讯云产品页把它写成「全场景 AI 办公工作台」，用户用自然语言下达任务，它自主拆解、规划、执行，最后交付文档、表格、PPT。两者的差别不在能力清单，而在交付形态：WorkBuddy 走云端托管，Octop 走自托管。
把这两件事放在一起看，才看得清腾讯这套 agent 技术线被拆成了什么。Octop 官方文档的一句自述是入口：「基于腾讯自研 harness-agent 运行时构建，采用单进程设计，降低部署复杂度。」同一套运行时，被摆到了两个交付位置上——一个替你管，一个交给你自己管。
01
TWO ROUTES
同源分岔：一个卖，一个自己管
Octop 的定位从第一行就写得很克制：一个自托管的 AI 助手，多用户、多智能体。它不承诺比谁更聪明，只承诺一件事——所有对话、工作区与凭证都留在你自己的机器上。
WorkBuddy 的定位则完全不同。腾讯云产品页的原话是「全场景 AI 办公工作台」，覆盖日常办公、代码开发与设计创意；用户以自然语言下达任务，它自主思考、拆解、规划，最终交付可验收的结果。它把「云端 7×24 任务托管」放在前台——关掉客户端，任务仍在云上跑。
同源的证据
Octop 官网技术内核一节写明：基于腾讯自研 harness-agent 运行时构建，采用单进程设计，不依赖任何外部消息队列或中间件。第三方报道亦指出，Octop 的前身是腾讯内部项目 LightClaw ACE，与 WorkBuddy 出自腾讯云同一支 agent 技术线。
边界说明：两者共用的是同一份运行时二进制，还是同一套自研框架的不同封装，公开材料没有给出确切说法。能确证的是它们都出自腾讯云同一支 agent 技术线，且 Octop 文档自述基于 harness-agent。把它读成「同一技术血统的两种交付形态」是稳妥的表述。
02
WHY REBUILD
旧做法卡在哪：四个没人解决好的问题Octop 官网给了一份「为什么要重做一款 AI 助手」的清单。它值得逐条看，因为这四条决定了这套系统把工程复杂度放在了哪里。
记忆缺乏连续性：很多助手仍以会话为中心，聊完即结束；用户偏好、历史任务、长期上下文难以沉淀，换设备、换模型或换运行环境后，助手往往要重新理解你。
多用户场景支持不足：家庭、小团队和企业不是单一用户场景。不同成员需要独立身份、独立记忆、独立工作区，还需要在必要时共享工具与能力。
工具与外部系统连接成本高：要真正参与工作流，助手必须能访问文档、浏览器、IM、云服务和企业系统；但很多实现里，工具接入仍依赖定制开发，复用性与可维护性不足。
复杂任务执行稳定性有限：真实任务不是一问一答，而是包含规划、调用工具、观察结果、调整策略、恢复执行的连续过程；缺少工程化的 Agent Loop，复杂任务很容易中途停滞。
这四条不是宣传语，是四个可检验的工程命题。后文拆的每一层，基本都在回应其中一条——单进程回应部署复杂度，两层存储回应多用户隔离，分层记忆回应连续性，harness 回应 Agent Loop 的稳定性。
03
ONE PROCESS
新做法：一个进程，两层存储
Octop 最反常规的一个决定是单进程。README 的原话是：所有界面——Web UI、IM、cron——都经过一个进程内的 HarnessProcessor 路由，不依赖任何外部消息队列或中间件。
单进程的关键收益是「重启即可恢复」：整个进程的状态在启动时从控制面数据库重建。没有独立 worker，没有队列，除了你自己配的大模型提供商之外，没有必须的外部服务。
存储被拆成两层，这是它相对同类设计最该被单独看的取舍。控制面数据库存用户、agent、通道、cron 元数据，默认 SQLite WAL，可选 PostgreSQL；而 agent 真正读写的工作区文件，可以放在本地磁盘、Docker 沙箱、PostgreSQL 或 COS/S3。两者是分开的。
把控制面与工作区分开，换来的是「换存储不动 agent 逻辑」；代价是你同时要管两个存储边界，备份与迁移都得各算一份。
隔离落在行级：每个请求经 JWT 鉴权解析到一条 User 记录，agent 归属按 agents.user_id 校验，管理员可越权。README 特意说明，已经没有「按用户一份 AgentManager」那种设计——全局只有一个 agent 注册表。
04
THE HARNESS
运行时内核：harness 封装了什么
如果说 Octop 是壳，octop-harness 是核。它的 README 开头一句就把身世说清了：它是对 deepagents 的一层「薄封装与工程化」。HarnessAgent 最终委托给 LangChain 团队 deepagents 的 create_deep_agent。
README 原文
「octop-harness 站在 deepagents 的肩膀上。HarnessAgent 最终委托给 deepagents.create_deep_agent，其余一切——模型路由、后端、分层记忆、agent 注册表、CLI 与 ACP——都是我们加在上面的工程。」
这句话修正了一个常见读法。把它叫「自研运行时」时，准确表述是：它自研的是封装与工程化层，agent 的底层推理循环来自 deepagents。图运行时用 LangGraph，检查点落在 SQLite。
四个可替换的接缝
模型路由
ChatModelFactory 把模型名解析到对应客户端，内置 OpenAI、Anthropic、AWS Bedrock，另有 17 个可编辑的 provider 预设，含混元、Kimi、GLM、DeepSeek、MiniMax、Moonshot。
分层记忆
每一轮先记为 L0 原始事件，再异步蒸馏成 L2 原子（AtomCard）与 L3 实体页；记忆随工作区走，不绑在某个模型或某次会话上。
工作区后端
BackendWorkspace 支持本地磁盘、S3、COS、PostgreSQL；换后端不重写 agent。
安全策略
SecurityPolicy 带工具护栏、文件系统权限与 PII 脱敏；脱敏覆盖大陆手机号（13–19 前缀）与 18 位身份证。
还有一个工程细节值得单独提：渐进式工具加载。低频的大工具集默认隐藏，模型先看到一个轻量的 schema 引用，需要时通过 tool_search 才把完整 schema 载入。它用「按需加载」而不是「全量塞入」来压住上下文，这在大工具量场景下是省 token 的直接手段。
05
BY THE NUMBERS
现场算一遍：8189 星背后的时间差
把时间线摆平，能看出这套系统的开源节奏和它的成熟度位置。以下数字取自 GitHub 只读接口，取数时间 2026-10-09。
表格里最该被注意的不是主仓的 8189，而是后四行的建仓日期。四个核心子仓库——运行时、IM 桥接、记忆、浏览器——全部建在 2026 年 9 月 24 日，比主仓晚了两个半月。
这解释了 1.0 发布时的一段争议。第三方报道记录过一条质疑：主仓开源时，harness-agent、harness-memory、harness-browser 这些底层依赖是以外部包形式引入的，想改核心源码会受限，与「完全开源」的说法存在张力。按建仓日期看，这条质疑在 9 月 24 日之后才逐步失效。
再算一个比例。主仓 fork/star ≈ 12.1%（992 ÷ 8189）；四个子仓合计 189 star，约为主仓的 2.3%。star 高度集中在主仓、子仓很轻，这是平台类项目的典型形态：多数人想要一个能跑的东西，少数人才会去动运行时。
两个口径要留清楚：open issues 有 688 条，对一个三个月大的项目不算低；最新 tag 是 v1.0.2b6（2026-10-04），版本号仍带 beta 后缀。1.0.0 正式版发布于 2026-09-14，距今不到一个月。
06
THE TIMING
为什么会在这个时间点开源
Octop 不是凭空出现的。第三方报道指出它的前身是腾讯内部项目 LightClaw ACE；官网也留了这条线索，把 Octop 称作「游向开源海洋的那只章鱼」，LightClaw 是「投向湖面的第一颗石子」。
时间点由两件事叠加。一是agent 运行时本身已经收敛：deepagents 提供了稳定的 create_deep_agent 原语，LangGraph 提供了图运行时与检查点，封装层才有东西可封，不必从零造循环。二是自托管需求在数据不出域与合规压力下被推高。
从工程视角看，2026 年年中做这件事的窗口是合理的：上层原语刚稳定，下层需求刚起量。此时把封装层开源，既不用重造运行时，又能卡住「自托管 agent 平台」这个位置。这是一次典型的站在上游肩膀上抢生态位的选择。
07
DEAD ENDS
会坏什么：四类确定的代价
单进程和自托管这两个选择，各自都有确定的失效面。按接口与部署形态列出来，比写「可能有兼容问题」有用。
SQLite 的写锁：默认控制面库是 SQLite WAL。单用户或小团队够用，但多用户高并发写入会撞上写锁；官方给的出路是换 PostgreSQL，代价是多一个必须维护的外部服务。
单点：一个进程扛下 Web、IM、cron。进程挂了，四类入口一起停。好处是重启即恢复，坏处是没有「只挂一个通道」的隔离。
远程桌面与浏览器操控：这两项把攻击面从「对话框」扩到了「图形界面」。官方默认专家运行环境不信任、读写限定在工作区，但把宿主桌面接进控制台本身就是需要自己评估的风险。
上游依赖：harness 封装的是 deepagents，模型路由、记忆、后端都建在这条依赖链上。deepagents 或 LangGraph 的破坏性变更，会顺着这条链传上来。
前两条是部署形态的固有代价，后两条是「能力越大、边界越大」的直接结果。它们不是缺陷清单，是选型时要一起算进成本的东西。
08
DEPLOY & USE
怎么部署与接入：三条命令，三个场景
部署门槛被压得很低，这是主仓三个月涨到 8189 star 的直接原因之一。三条命令就能跑起来。
生产环境走 Docker：docker compose -f docker/docker-compose.yml up -d。另有 pip install octop、桌面客户端（Windows / macOS / Linux，含飞牛 NAS 的 FnOS 包）两条路。所有安装方式都把环境装进 ~/.octop/ 一个目录——数据库、密钥、工作区、日志都在这里，删目录即清空。
模型接入是「按 agent 配」：OpenAI 兼容 API、DashScope（Qwen）、Ollama 都可以，也可以给不同 agent 配不同模型。IM 通道覆盖飞书、钉钉、QQ、微信、企业微信、Telegram、Discord。
三个能落地的场景
家庭或小团队共用：一个管理员账号管多个成员，每人独立 agent 与独立记忆；家长用「营养师」规划三餐，孩子用「作业辅导」讲题，工具与知识库在需要时共享。
开发者工作流：通过 ACP 双向接入。入站用 octop acp --agent main，把 Octop 变成 Zed、OpenCode 等 IDE 可驱动的 agent；出站把编码任务委派给 OpenCode、CodeBuddy、Claude Code、Codex。
团队自动化：用远程桌面处理图形界面任务，用浏览器自动化做采集与表单，用自然语言配 cron，例如「每天早上 8 点，把微博科技榜前三条同步到团队群」。
反过来看 WorkBuddy 的场景：它把「云端 7×24 任务托管」和「100+ 预置领域专家」放在前台。两者的场景重叠，但一个把运维留给自己，一个把运维交给云。
09
THE SCALE
刻度在哪：早期采纳，未成默认
给这条路线定个刻度：它处在「早期采纳」，尚未到「已成默认」。依据有三条。
版本
最新 tag 是 v1.0.2b6（2026-10-04），仍带 beta 后缀；1.0.0 正式版发布于 2026-09-14，距今不到一个月。
生态厚度
四个运行时子仓库合计 189 star，主仓 8189 star，star 高度集中在「平台」而非「运行时」；愿意改核心的人还很少。
议题存量
688 条 open issues，对一个三个月大的项目偏高，说明边界情况还在被大量发现。
三个信号指向同一个判断：它可以用来跑通场景、验证架构，但把它当生产基础设施，还为时过早。官方 roadmap 里把「Managed Agents」「云边协同」列在 Planned，也说明托管化那一半还没做完。
10
CHECKLIST
判断工具：五个问题还原工程条件
下次评估「自托管 agent 平台」时，可以用这几个问题把宣传语还原成工程条件。
把这五个问题答完，云端托管与自托管之间的取舍基本就清楚了：云端买的是「不用管这些」，自托管买的是「这些都能自己改」。两者不是替代关系，是同一套能力的两种成本结构。