Memoh
给每个 AI Agent 一台 24/7 在线的云电脑：独立文件系统、桌面、浏览器、网络与长期记忆，自带密钥或托管 Claude Code、Codex。
- Star 数
- ★ 2.8k
- 最近更新
- 今天
- License
- AGPL-3.0
- 主语言
- Go
- FA 评分
- 48/100 · 缺口较多
30 秒速览
- 可在哪里用
- 通用 · 跨平台Codex · Claude Code
- 开始前需要
- 典型场景
- 个人开发者希望有一个 7×24 在线、能记住历史上下文的私人助手，通过 Telegram 或微信随时对话。
- 主要局限
- 自托管需要服务器、Docker 和 config.toml 配置，还需管理 MEMOH_INTERNAL_RPC_SHARED_SECRET 等内部密钥，有一定运维成本。
- 源码审查
- 48/100 · 缺口较多
这个 Agent 能做什么，适合哪些场景？
Memoh 是一个开源多 Agent 平台，为每个 Agent 提供独立的云上工作区，包含文件系统、桌面、浏览器、网络和长期记忆，即使你的笔记本合上，Agent 依然在线运行。你可以使用自己的 API 密钥运行内置 Agent，也可以在 Memoh 工作区内托管已有的 Claude Code、Codex 等编码 Agent。用户通过 Telegram、Discord、飞书、微信、Web UI 等渠道与 Agent 对话，Agent 跨会话和跨平台记住上下文，能驱动浏览器、调用 MCP 工具并执行定时任务。部署上既可以使用 Memoh Cloud（app.memoh.net），也可以用一条安装脚本或 Docker Compose 自托管完整技术栈。仓库还包含子项目：Go 语言 AI SDK「Twilight AI」、连接器网关「Connect It」以及基于 Vue 3 的 UI 设计系统。整体采用 AGPL-3.0 许可证，由 MemohAI 团队维护。
Memoh 的服务端（Server）和渠道服务（Channel）可作为两个独立进程通过 Docker Compose 运行，也可在 internal_rpc.shared_secret 留空时合并为单一 all-in-one 进程。每个 Agent 获得一个隔离工作区，具备文件系统、桌面、浏览器和网络访问能力，并持有跨会话的长期记忆。它通过 Telegram、Discord、Lark、WeChat、Web UI 等渠道接收消息；Agent 可驱动浏览器、调用 MCP 工具、运行定时任务。内置 Agent 使用用户自备的 API 密钥（BYOK），也可在 Memoh 工作区内托管 Claude Code、Codex 等已有编码 Agent。部署入口是一键安装脚本或手动 git clone + config.toml 配置 + docker compose up -d；Channel 通过内部 Storage RPC 进行经过认证的媒体流传输。
- 个人开发者希望有一个 7×24 在线、能记住历史上下文的私人助手，通过 Telegram 或微信随时对话。
- 团队为每位成员分配一个独立 Agent，各自拥有隔离的工作区、浏览器和工具调用能力。
- 已在使用 Claude Code 或 Codex 的开发者，希望把现有编码 Agent 托管到云端工作区中持续运行。
- 需要定时任务和浏览器自动化的用户，让 Agent 在云端按计划执行并保持在线。
- 自托管爱好者想在自己的服务器上运行完整多 Agent 平台，掌控数据和工作区存储。
如何安装或部署这个 Agent？
快速自托管安装（一键脚本）：
curl -fsSL https://memoh.sh | sh中国大陆镜像加速：
curl -fsSL https://memoh.sh | USE_CN_MIRROR=true sh注意不要用 sudo 运行整个安装脚本；如 Docker 需要，安装器内部会自行使用 sudo docker。
手动部署（Docker Compose 拆分模式）：
git clone --depth 1 --recurse-submodules --shallow-submodules https://github.com/felinics/Memoh.git
cd Memoh
cp conf/app.docker.toml config.toml
# 编辑 config.toml
export MEMOH_INTERNAL_RPC_SHARED_SECRET="$(openssl rand -hex 32)"
docker compose up -d拆分部署中，Server 和 Channel 是独立服务；需保管好内部 RPC 密钥并在重建堆栈时使用相同值。升级时先升级 Server 再升级 Channel。不想用 Docker 时，可在 config.toml 中将 internal_rpc.shared_secret 留空，服务端会内嵌 channel 运行时，以单一 all-in-one 进程运行。若不用 GitHub 自动生成的源码归档（不含子模块内容），请使用 Release 附件中的 Memoh-<version>-source.zip 或 .tar.gz。更多生产配置见仓库中的 DEPLOYMENT.md。也可直接注册使用云端版：https://app.memoh.net。
如何使用这个 Agent？
云端方式：在 app.memoh.net 注册或登录后即可使用。
自托管方式：完成安装后打开 Web UI 与 Agent 对话，或通过 Telegram、Discord、飞书、微信等渠道连接。在 config.toml 中配置自己的 API 密钥以驱动内置 Agent，或在 Memoh 工作区内托管 Claude Code、Codex 等编码 Agent。Agent 会跨会话和平台记住上下文，可驱动浏览器、调用 MCP 工具（凭证可通过子项目 Connect It 安全存储并通过单一 MCP 端点提供集成）、执行定时任务。可以为个人运行一个实例，也可以为团队每位成员各部署一个。社区支持包括 Telegram 群（t.me/memohai）和文档站 docs.memoh.ai。
这个 Agent 有哪些优点和局限？
- 每个 Agent 拥有真正隔离的云工作区（文件系统、桌面、浏览器、网络），而不是共享沙箱，且可 24/7 在线运行。
- BYOK 模式：使用自己的 API 密钥，并可托管 Claude Code、Codex 等已有编码 Agent，不绑定单一模型供应商。
- 多渠道接入：Telegram、Discord、Lark、WeChat、Web UI，跨平台共享长期记忆。
- 完整的自托管路径：一键脚本、Docker Compose 拆分部署或单进程 all-in-one 模式可选。
- 自托管需要服务器、Docker 和 config.toml 配置，还需管理 MEMOH_INTERNAL_RPC_SHARED_SECRET 等内部密钥，有一定运维成本。
- 运行 LLM 需自备付费 API 密钥；使用 Memoh Cloud 则依赖其托管服务。
- GitHub 自动源码归档缺少子模块内容，从 Release 归档或 git pull（配合 submodule 初始化）构建才有额外注意事项。
- AGPL-3.0 许可证对商业集成和二次分发有传染性约束，商业化前需评估。
这个 Agent 与同类方案有什么区别？
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | 形态 / 费用 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|---|
| Memoh 当前 | 48 · 缺口较多 | — | ★ 2.8k | 今天 | Go | Codex · Claude Code |
| OtoDock | 77 · 表现良好 | 自托管服务免费版 + 付费版 | ★ 195 | 3 天前 | Python | Codex · Claude Code |
| Synapse AI 多智能体编排平台 | 70 · 存在缺口 | 命令行工具免费 + 模型费 | ★ 335 | 1 天前 | Python | OpenAI API · Claude API |
| 智坤代码 (ZhikunCode) | 56 · 缺口较多 | 自托管服务免费 + 模型费 | ★ 532 | 1 天前 | Java | OpenAI API · Claude API |
FollowAgents 如何评估这个 Agent？
查看各维度的扣分理由
证据显示各代理运行于隔离容器（docker/containerd/apple 后端），RPC 共享密钥、JWT、OAuth 回调、凭证校验测试等表明安全设计有意识；但 README 以 curl|sh 一键安装，多数权限边界、用户确认机制、外部副作用（浏览器驱动、定时任务、消息渠道）仅口头宣称，代码不可见，故多为 1；敏感数据处理（密钥不写入服务定义、URL 凭证拒绝测试）得 2；依赖覆盖修复列表显示依赖安全有维护，得 2。
测试文件显示错误信息被显式断言（如 '--replace'、'not valid JSON'、'not found'），失败消息处理得 2；声明与配置文档大体自洽（internal_rpc 空密钥即单进程模式在两处一致），得 2；但依赖多个外部服务（postgres、qdrant、云目录）可用性保障无证据，得 1。
多平台模板（Docker/macOS/Windows/开发环境）与多渠道（Telegram/Discord/Lark/WeChat）显示环境适配良好，得 2；目标用户（个人到团队 fleet）有描述，得 2；但能力边界与触发精度（代理何时做什么）几乎没有文档化，得 1。
README 结构清晰，含多语言、部署细节、子项目链接，信息架构得 2；安装说明详细（含 CN 镜像、sudo 警告、子模块陷阱），得 2；AGPL-3.0 全文存在但 Cargo.toml 标 Apache-2.0、package.json 标 ISC，许可证声明不一致，扣分后得 2；版本号 1.0.0-beta.1 存在但无 changelog 证据，命名基本稳定；示例/FAQ 与已知局限仅薄，维护责任仅靠 badge，均得 1。
输出可用性无法从静态证据判断实际代理输出质量，得 1；与同类平台相比（BYOK、自托管、隔离工作区、记忆）边际价值主张明确，得 2；但成本收益（资源开销、运行成本）无数据，得 1。
声明多可溯源到具体文件（配置段、测试），但多数核心宣传（24/7 在线、隔离、记忆）无法在提供的文件中核实，得 1；测试与文档、配置互相印证程度中等，得 1；事实与推断的区分在文档中做得尚可（如明确说明未测试行为），得 2。
- 安装脚本使用 curl|sh 模式，建议用户先审查脚本内容再执行。
- 仓库内许可证声明不一致（LICENSE 为 AGPL-3.0，Cargo.toml 为 Apache-2.0，package.json 为 ISC），使用者需自行确认合规边界。
- 代理的容器隔离、网络权限与外部副作用（浏览器、定时任务、消息渠道）仅有 README 描述，静态审查未见实现代码，部署前应自行审计。
- 项目版本为 1.0.0-beta.1，发布方未经验证，生产使用需谨慎。
- 无变更日志与已知局限说明，升级风险由使用者自担。