自 Octop 开源以来，我们收到了不少开发者的关注和反馈。其中，一个问题被反复问起：这套自托管、多用户、多 Agent 的 AI 助手，底层究竟是怎么搭起来的？
如果把 Octop 看作一位能够真正上手干活的数字员工，那么真正让它把事情做起来的，并不只是一个足够聪明的模型。
它需要一个头脑，负责想清楚任务怎么做、工具怎么调度；需要记忆，把过去聊过的事和积累的经验留下来；需要能够上网看、动手做，真正进入网页完成操作；还需要一套沟通能力，在飞书、钉钉、QQ 等不同渠道里接收和回复消息。
今天，我们把支撑 Octop 的这四项核心本领正式开源：
Octop Harness —— 头脑：生产级 Agent 运行时，负责模型调用、任务执行、工具使用以及多 Agent 协作； Octop Memory —— 记忆：长期记忆系统，负责记忆的存储、提炼、检索与迁移； Octop Browser —— 眼睛和手：Agent 浏览器，负责网页访问、感知、交互与自动化操作； Octop Gateway —— 沟通能力：IM 通信网关，负责连接飞书、钉钉、QQ 等不同消息平台。
Harness 负责想清楚怎么做，Memory 负责记住发生过什么，Browser 负责去网页上看和操作，Gateway 负责在不同渠道里听和说。
四者组合起来，构成了 Octop 的核心能力底座；拆开之后，每一个组件也都可以独立运行、按需取用。这也是我们过去一段时间在 Harness Engineering 上持续实践的一件事：
一个真正面向生产环境的 Agent 系统，不应该把模型、记忆、工具、浏览器、消息渠道全部揉进一个庞大的单体，而应该把稳定、可复用的能力沉淀成边界清晰的组件。
Octop 是这些能力组合之后的完整形态；而 Harness、Memory、Browser、Gateway，则是从这个完整系统中拆出来、可以被独立复用的核心能力。
图1: Octop 数字员工的能力底座
Agent 正在快速变复杂。
模型供应商持续更新，IM 平台协议不断变化，浏览器自动化方案持续迭代，长期记忆的存储与检索策略也在不断演进。
当这些能力全部堆在同一个工程里，一个很现实的问题很快就会出现：本来只是想让它多学一项本领，最后却可能牵动整个系统。
接入一个新的 IM 平台，可能碰到 Agent 内部状态；增加一个模型供应商，可能需要修改原本与模型无关的业务逻辑；浏览器能力升级，又可能影响上层工具调用。功能越来越多之后，“顺手改一下”会逐渐变成技术债。
图2: 单体耦合与组件化对比
所以，我们选择把其中相对稳定、彼此正交的能力继续向下拆分，沉淀成：独立仓库 + 独立 PyPI 包 + 清晰接口契约。
这相当于不再要求一个“数字员工”把所有本领都长在一起，而是把头脑、记忆、浏览器、通信分别沉淀成独立能力。这样一来，边界不再只是代码里的约定，而成为真正的工程边界。
每个组件可以独立测试、独立发版、独立评审；一个组件的变化，也尽可能被限制在自己的职责范围内。
对 Octop 来说，这是把复杂系统拆清楚；对其他开发者来说，则意味着这些能力终于可以单独拿来用了。
你不需要为了其中一种能力，把整个 Octop 搬进自己的项目：
只需要长期记忆，就接 Octop Memory； 只需要浏览器能力，就用 Octop Browser； 想搭建自己的 Agent Runtime，可以直接从 Octop Harness 开始； 想让自己的 Agent 接入多个 IM，则可以单独使用 Octop Gateway。
把一个完整系统拆开，不是为了“拆而拆”。而是希望这些经过真实场景打磨的本领，可以离开 Octop，进入更多 Agent 工程。
一个 Agent 真正开始工作之后，首先需要解决的，是“怎么把事情组织起来”。
模型怎么切换？
记忆怎么持久化？
工具怎么接入？
多个 Agent 怎么隔离？
工作区放在哪里？
Agent 之间又怎么协作？
这些事情，最终都需要一个“头脑”来统筹。
Octop Harness，就是 Octop 的这个运行中枢。从工程角度看，它是一套构建于deepagents之上的生产级 Agent Runtime。
deepagents 提供智能体运行的核心能力，而 Harness 在此基础上进一步补齐了 Agent 从 Demo 走向真实应用时需要的模型路由、持久化、工具、多 Agent、工作区等能力。
换句话说，它关注的不是“让模型回答一次问题”，而是：怎么让一个 Agent 真正被组织起来，并持续运行。
技术看点
基于 deepagents 构建生产级封装 模型路由预设主流模型提供商 对话支持 L0 → L3 四级分层蒸馏 原生支持多 Agent 与团队协作 同一进程可托管多个隔离 Agent 工作区支持本地 / S3 / COS / PostgreSQL
具体来看：
模型路由：内置混元、Kimi、GLM、DeepSeek、MiniMax、Moonshot 等可编辑的供应商预设。切换模型时，不需要跟着修改业务代码。对于 Harness 来说，模型是可以被调度和替换的能力，而不是与业务逻辑绑死的一部分。
持久化记忆：原生接入 Octop Memory，对话可以按层级进行蒸馏，记忆也可以跟随工作区迁移。
工具开箱即用：浏览器自动化、网页搜索、文件操作、子 Agent 与 MCP 工具等能力已经集成在运行时中。“头脑”不只是负责思考，也需要知道什么时候该调用什么工具，把任务真正往下推进。
多 Agent 与团队模式：同一进程可以托管多个彼此隔离的 Agent，同时支持 Agent 之间的协同编排与团队协作。
后端可插拔：本地目录、S3、COS、PostgreSQL 都可以作为 Agent 工作区，根据部署环境选择即可。
ACP 与 Teams：通过标准协议，让 IDE、终端 AI 等入口能够直接驱动 Agent，同时支持 Agent 之间的消息协作。
所以，Octop Harness 想解决的并不是“怎么调用一次大模型”。而是：当一个 Agent 真正进入生产环境之后，怎么把模型、记忆、工具、工作区和多 Agent 协作组织起来，并且长期稳定地运行。
图3: Octop Harness 能力全景
有了头脑之后，还要解决另一件事：Agent 怎么记住过去？
如果每一次对话、每一次任务结束后都重新从零开始，那么它依然只是一个“用完即走”的工具。Octop Memory，就是 Octop 用来把经历留下来的长期记忆系统。
它围绕“记忆树（root → branch → leaf）”构建，将原始信息逐层整理、提炼，再在真正需要的时候检索出来。这里的“记住”，并不是简单地把所有聊天记录保存下来。
随着交互越来越多，原始信息会越来越庞杂。真正有用的长期记忆，需要从这些信息中逐层提炼出事实、实体和关系，再在需要的时候找到它们。
所以，Octop Memory 更像是一本会自己整理重点的长期笔记。而且，这本“笔记”并不属于某一个 Agent。
Octop Memory 本身不直接调用大模型，而是一个独立的存储 + 检索层，因此可以被不同 Agent 接入。其中，我们尤其关注一个能力：
记忆的可迁移性。存储后端通过统一协议抽象，记忆也可以打包成标准格式。这意味着，即使未来更换 Agent 框架，已经积累的记忆也不一定要推倒重来。
Agent 可以换，过去积累下来的记忆可以继续带着走。
技术看点
核心零依赖，仅使用标准库 + sqlite3 M4 检索管线 默认 SQLite + FTS5 可切换 PostgreSQL / Chroma / Qdrant 支持 .hmpkg打包，实现跨框架迁移
核心能力包括：
记忆树与分层蒸馏：将原始事件逐层提炼为原子事实与实体页，让长期信息越来越精炼。
完整检索管线：覆盖解析、路由、采集、重排、多样性、噪声抑制、token 预算与最终渲染。
可插拔存储：默认即可使用轻量本地方案，也可以根据需求切换 PostgreSQL 或向量数据库。
跨 Agent 迁移：记忆可以打包导出，再导入新的宿主环境。
图4: Octop Memory 记忆树
有了头脑和记忆，Agent 已经能想、能记。但要真正把任务完成，它还需要看见网页，并对网页进行操作。
这就是 Octop Browser 负责的部分。它相当于 Octop 接触 Web 世界的“眼睛和手”：读取页面是“看”，点击、输入、滚动、截图等动作则是“做”。
从工程角度看，Octop Browser 是一套面向 Agent 的轻量浏览器能力。与在 Playwright 上继续封装的常见方案不同，它直接通过 Chrome DevTools Protocol（CDP） 连接真实 Chromium。
减少中间层之后，Agent 可以基于实时 DOM 的稳定引用进行元素定位。
技术看点
直连 CDP 无 Playwright 中间层 基于稳定 ref 定位 多级轻量 DOM，减少 token 消耗 约 20 个无状态动作 Profile 持久化登录态 支持录制、回放与 MCP
核心能力包括：
直连 CDP：直接与 Chromium 通信，减少额外中间层。
轻量 DOM：通过多级 DOM 表示减少传入 Agent 的无效页面信息，控制上下文与 token 消耗。对于 Agent 来说，网页不是“看得越多越好”。真正需要的是把与当前任务有关的页面结构准确地交给它。
登录态持久化：登录状态可以基于 Profile 在不同会话之间保持。登录一次之后，后续任务可以继续复用。
约 20 个无状态动作：导航、点击、输入、截图、滚动等常用操作均可以独立调用，每个动作同时也是一条命令行。
录制与回放：可以记录真实操作，再让 Agent 按操作意图进行复现，而不是依赖容易失效的固定坐标。
MCP 服务：浏览器能力还可以通过 MCP 暴露给其他支持 MCP 的 Agent。
所以，Browser 让 Agent 完成了一步很重要的跨越：从“知道应该怎么做”，走向“真正进入网页，把事情做完”。
图5: Octop Browser 直连 CDP
Agent 会想、会记、也能动手之后，还差最后一件事：它怎么和用户说上话？
现实中的用户并不会都守在同一个 AI 页面里。有人在飞书，有人在钉钉，有人在 QQ、企业微信；不同平台又有不同的协议、消息格式和交互方式。
如果让 Agent 自己逐个适配，就相当于每换一个聊天软件，都要重新学一套“语言”。Octop Gateway 做的，就是把这些不同的“语言”统一起来。
从工程角度看，它是一套 IM 通信网关：把不同 IM 平台的协议差异，收敛成统一的事件模型。飞书、钉钉、QQ、企业微信、微信 iLink、元宝、小艺、MQTT 等渠道的入站消息，都可以进入同一条处理管线。
开发者只需要面向统一事件编写处理器。新增一个 IM 平台时，主要处理平台接入层，而不需要重新修改上层业务逻辑。可以把它理解成：外面说的是不同“语言”，进入 Gateway 之后，交给 Agent 的都是同一种标准表达。
技术看点
统一事件抽象 多 IM 平台接入 原生流式输出 可插拔媒体处理 主动消息推送 多租户、多实例隔离
核心能力包括：
一个处理器，多平台运行：同一套业务处理逻辑，可以服务多个消息平台。
统一事件抽象：平台差异被收敛在 Gateway 内部，上层只需要处理通用消息与事件模型。
流式事件：原生支持逐字流式输出。
媒体与主动推送：支持通道限流、超时、“正在输入”等状态，同时提供可插拔媒体存储与主动消息推送能力。
多租户：多个同类型通道可以同时运行，并保持相互隔离。
当 Gateway 与 Octop Harness 组合之后，一个负责“思考和执行”，一个负责“接收和传递”。
于是，同一个 Agent 可以拥有一个运行中枢，同时从多个消息入口与用户交互。
图6: Octop Gateway 统一多 IM 入口
图7: Octop 整体架构与四大组件
那么，现在，再回到开头的问题：Octop 到底是怎么搭起来的？
我想，答案已经比较清楚了。
Harness 是头脑，负责 Agent 的运行与调度 Memory 是记忆，负责长期信息的沉淀与检索 Browser 是眼睛和手，负责与网页世界交互 Gateway 是沟通能力，负责连接不同的消息入口
再加上 Web 控制台、命令行、专家库、知识库与插件体系，它们共同组成了今天的 Octop。Octop 不依赖外部消息队列或中间件。Web、IM、定时任务等入口，都会经过进程内的统一处理器进行路由。
因此，Octop 本身也可以看作这四个组件在真实场景中的一次完整集成：
四项本领组合在一起，让 Octop 成为一个完整的 Agent 系统；拆开之后，它们又可以各自进入其他 Agent 工程。你可以使用完整 Octop，也可以只选择其中一个组件。
这也是组件化真正有价值的地方：拆得开，才能按需取用；边界足够清楚，才能自由组合。
需要一个运行中枢，就拿 Harness 需要长期记忆，就接 Memory 需要网页操作，就加 Browser 需要连接 IM，就接 Gateway
从这个角度看，它们更像是四块已经打磨好的 Agent 基础积木。而 Octop 只是其中一种拼法。
目前，这四个组件均基于 MIT 协议开源，并已发布至 PyPI。
可以直接安装：
头脑 · Octop Harness： pip install octop-harness[cli]记忆 · Octop Memory： pip install octop-memory[cli]眼睛和手 · Octop Browser： pip install octop-browser沟通能力 · Octop Gateway： pip install octop-gateway
欢迎在 GitHub 上关注 TencentCloud 组织，或直接访问各仓库：
Octop Harness：https://github.com/TencentCloud/octop-harness Octop Memory：https://github.com/TencentCloud/octop-memory Octop Browser：https://github.com/TencentCloud/octop-browser Octop Gateway：https://github.com/TencentCloud/octop-gateway
图8: Octop 四大核心组件开源仓库
从 Octop，到今天进一步开放 Harness、Memory、Browser 与 Gateway，我们希望开源的不只是一套完整产品。
更希望把构建它过程中沉淀下来的核心能力，一项项拆出来。让这些经过真实场景打磨的“本领”，成为其他开发者构建 Agent 时可以直接取用的基础设施。
你可以完整使用 Octop，也可以只拿走其中一块，接进自己的 Agent。如果这些组件恰好解决了你正在重复解决的问题，欢迎在 GitHub 上 Star、提交 Issue 或 PR。
拆开，是为了更自由地组合。
也期待这四项本领在更多开发者手里，长出 Octop 之外的新东西。