有些人看不上 Meta 正在收购的 Manus 智能体，认为远不如 OpenClaw。但这个判断，错。

更准确地说，它们不是在同一层竞争：Manus 更像托管式的 agent computer / cloud work engine，OpenClaw 更像用户自持的 agent gateway / runtime OS。前者优化的是“把活干完”，后者优化的是“把 agent 接到我的渠道、设备、模型和权限边界里”。把这两类东西直接做绝对高下，容易把产品完成度和基础设施控制权混成一件事。

一、技术原理

Manus 的核心生产函数是“云端执行环境 + 上下文工程 + 并行子代理”。官方写得很直白：每个Manus session 背后都有一台专属云端虚拟机，Wide Research 的本质是并行处理和agent-to-agent collaboration，而且每个 subagent 都是通用 Manus 实例，不是固定角色脚本；它还把Browser Operator 做进本地浏览器，把 Slack 变成可查询知识库，把 Project Skills 做成项目级受限技能库。这个架构的优点是：执行环境强、并行性强、产品感强，适合把“研究—整理—执行”连成一条托管流水线。

OpenClaw 的核心生产函数则是“本地控制面 + 多渠道入口 + 用户自有工具/记忆/设备”。官方文档把 Gateway 定义成 sessions、routing、channel connections 的单一事实源；它默认是local/loopback first，非 loopback 绑定没有认证会被拦住；内置的是 typed tools，而不是靠 shell 拼凑；memory 的 source of truth 是工作区里的 Markdown 文件；还能按 channel 精确切模型，并把浏览器、节点、摄像头、屏幕录制、cron 都纳入统一工具面。这个架构的优点是：可控、可审计、可替换、可私有化，特别适合“我的 agent 必须在我的边界内工作”。

所以从“技术含量”讲，Manus 并不低。很多人一看它用了现成组件，就说它只是套壳；但这恰恰低估了 agent 产品真正难的部分。TechCrunch明确提到 Manus 使用了 Browser Use 一类中间层，而 Manus 自己的技术博客又强调，agent的关键不是模型裸能力，而是 memory、environment、feedback 的组织方式。换句话说，agent 时代的壁垒往往不是“每个底层 primitive 都自己造”，而是“把上下文、执行环境、反馈回路和 UX 组织成稳定生产函数”。这一点，Manus 做得并不弱。

二、两种截然不同的“物种”

用一个比喻来说：

OpenClaw = Linux + Control Plane：像用户自持的 Agent OS，优化目标是“把 Agent 绝对安全受控地接入我的渠道、设备和边界里”

Manus = Salesforce + Cloud Operator：像托管式的云端工作台，优化目标是“非技术用户也能直接获得执行结果，把活干完”

三、智能体创新方向

从智能体创新的方向看，二者创新点完全不同：

• Manus 的创新更偏“把 agent 变成可消费的云劳动力”：会话即算力、技能即流程资产、Slack/Browser/Research即工作界面，目标是让非技术用户也能直接获得执行结果。
  

• OpenClaw 的创新更偏“把 agent 变成个人/组织的主权运行时”：一个 Gateway 打通 WhatsApp、Telegram、Discord、iMessage 等入口，按渠道或会话切模型，接入本机和移动节点，把记忆落到文件系统里。前者更像 SaaS 化的 agent 工作站，后者更像可编排的 agent OS。

如果你问“哪一个更适合做真正的个人智能体”，答案其实分场景。你要的是：

• “帮我在云端做研究、出 slides、跑流程、给团队复用”：Manus路线更顺，因为它已经把 VM、并行研究、项目技能、Slack 连接器这些抽象成产品功能了。

• “让我自己的 agent 长驻在WhatsApp/Telegram/iMessage/Slack，按不同群和渠道切模型，还能调用我自己的浏览器、手机、相机、cron、文件记忆”：OpenClaw更强，因为它本来就是围绕这个控制面设计的。

四、市场潜力

Meta 买 Manus，不是在买一个“演示级 agent”，而是在买一个能嵌进自己分发体系的 agent 层。公开口径里，Meta 计划把 Manus 整合进 consumer 和 business products，包括 Meta AI；Meta 自己在 2025 年已披露 Meta AI 月活超过 10 亿，而且在广告侧已经在测试会“记住广告主目标”的 business assistant；路透引述分析师更直接点名 WhatsApp SMB 是天然落点。也就是说，Manus 一旦吃到 Meta 的分发、广告和 SMB 生态，天花板会远高于大多数独立 agent 产品。

而且，Meta 愿意为 Manus 付出约 20 亿到 30 亿美元估值，而 Manus 当年融资估值大约还在 5 亿美元量级，这个价差本身就在说明：大厂看重的不是“它是不是完全原创了每个底层组件”，而是它是否已经证明了 agent 编排、执行和产品化能成为平台资产。这也是为什么我不觉得“看不上 Manus”是个稳健判断。

当然，Manus 也不是无敌。它的上限高，但锁定、监管和平台博弈也更重。公开报道显示，这笔交易曾遭到中国方面审查；而 Meta 把 AI 入口嵌进 WhatsApp 的做法，也已在欧盟引发竞争监管压力，最终 Meta 今年 3 月还同意在欧洲让 rival AI chatbots 通过 WhatsApp Business API 接入一年。这意味着 Manus 的市场扩张虽然有 Meta 加持，但也会同时继承 Meta 的监管摩擦。

OpenClaw 则相反：它的分发天花板更低，但护城河更“硬”。它是 MIT 开源、自部署、用户自持边界、可多模型路由、可多渠道接入，天然适合开发者、高级用户、隐私敏感团队、以及希望把 agent 接入自家系统而不是接入 Meta生态的人。它未必会赢“十亿用户”这条线，但很可能在“高自由度 agent runtime / sovereign agent infrastructure”这条线上长期有价值。

我的最终判断是：

如果比的是托管式 agent 产品化、云端执行力、以及接入超级分发后的商业天花板，Manus 不但不弱，反而很强。

如果比的是可控性、可塑性、主权部署、多模型/多渠道/多设备编排，OpenClaw 更强。

所以真正准确的话不是“Manus远不如 OpenClaw”，而是：Manus 更像面向规模化市场的 agent product，OpenClaw 更像面向主权与可编排性的 agent infrastructure。前者更容易被 Meta 放大，后者更容易成为深度用户和开发者手里的“真底座”。

五、四层技术架构拆解

先把结论摆出来：Manus 不是“技术不如 OpenClaw”，而是优化目标不同。

OpenClaw 更像“主权型 agent runtime / control plane”，把渠道、会话、记忆、工具权限都握在用户自己手里；Manus 更像“托管型 agent work engine”，把研究、执行、交付、协作做成一条云端生产线。

01

模型层

很多人会误以为 agent 的核心壁垒在“底模谁更强”。但 Manus 官方博客反而强调，它们在产品上押注的是 context engineering，而不是把自己绑死在某个底模上；它甚至明确说希望“模型进步是涨潮，Manus 是船，不是礁石”，并披露 agent 场景里平均输入输出 token 比大约是 100:1，KV-cache 命中率直接影响延迟和成本。OpenClaw 这边也明显不是“单模型神教”，而是把模型选择放进控制面：它支持按 channel 甚至按具体群组/话题去 pin 不同模型。所以模型层上，Manus 强在把模型异质性产品化，OpenClaw 强在把模型选择权基础设施化。前者更像 SaaS 优化，后者更像 OS 优化。

02

上下文层

这里其实是两者差异最大的地方。Manus的思路是把“上下文工程”做成性能工程：围绕上下文增长、缓存命中、子代理协同，去维持大任务质量与成本。Wide Research 明说自己本质上是并行处理机制和 agent-to-agent collaboration protocol，而且每个 subagent 都是通用 Manus 实例，不是固定的经理/程序员/设计师角色脚本。OpenClaw 的上下文层则更偏“可持久化、可审计、可替换”：记忆是写入工作区的 Markdown 文件，MEMORY.md 和按日记忆文件是 source of truth；长会话则用 compaction 把旧历史压成摘要，并保存在会话 JSONL 里。抽象地说，Manus 在优化“上下文吞吐量”，OpenClaw 在优化“上下文主权”。这是两条完全不同的技术路线。

03

执行环境层

这层上，Manus 其实非常强，且经常被低估。官方说它长期依赖 cloud browser / sandboxed environment 来做研究、建站、分析、生成内容；Browser Operator 又把本地浏览器接进来，让它能利用用户已经登录、已经受信任、已经被目标网站认可 IP 的本地会话去执行任务。Slack Connector 则把团队聊天记录变成可查询知识库；Project Skills 则把项目里的能力、规则和最佳实践固化成一个受限技能库。也就是说，Manus 的创新不是“多做几个 tool”，而是把云端沙盒、本地浏览器、团队知识库、项目技能库整成一个可执行工作空间。OpenClaw 则强在另一种执行哲学：Gateway 是单一事实源，默认 loopback first、默认要求认证；工具是 typed、可 allow/deny、可按 profile 和 provider 缩减；节点、浏览器、Canvas、cron、消息发送都纳入统一工具面。如果说 Manus 的执行环境像托管数据中心，OpenClaw 的执行环境更像私有云控制台。

04

分发层

这一层，Manus 的上限远高于 OpenClaw，而这恰恰是 Meta 看中的地方。Reuters 报道，Meta 公开表示会把 Manus 技术整合进自己的产品；与此同时，Reuters还报道过 Meta AI 在 2025 年 4 月已接近 10 亿月活，且 2026 年 3 月 WhatsApp 在欧洲被要求对 rival AI chatbots 临时开放 Business API，这反过来说明：WhatsApp 本身就是 AI 分发的关键入口，关键到会触发反垄断争议。所以 Meta 买 Manus，不只是买“一个 agent 产品”，而是在买一套能嵌进 Meta AI、WhatsApp、商家工具和企业协作面的执行引擎。OpenClaw 在分发上则更像开发者网络效应：靠开源、MIT 许可、自部署、多渠道接入，去吃“高自由度、高隐私、高控制权”这块市场。它会很深，但通常不会像 Meta 那样天然拥有十亿级分发。

这就能解释为什么有些技术用户“看不上”Manus。因为他们在比较的是可控性、可 hack 性、可替换性，在这个坐标系里，OpenClaw确实更像“真 agent OS”；而 Manus 更像“封装度更高的托管 agent 产品”。但如果换一个坐标系，比较的是完成任务的稳定性、团队协作、非技术用户 adoption、以及被超级平台放大的商业乘数，那 Manus 不但不弱，反而很强。换句话说：OpenClaw更像高手手里的底盘，Manus 更像大厂手里的量产整车。

所以最终不是“谁绝对更先进”，而是“谁占住了更稀缺的层”。

如果你问技术底座的稀缺性，OpenClaw更稀缺，因为它占的是主权 runtime、渠道控制、权限边界、可审计记忆这些更底层的位置。

如果你问商业放大的稀缺性，Manus更稀缺，因为它已经证明了云端 agent workflow 可以产品化，又恰好接上了Meta 的分发、企业入口和资本火力。

六、三种“时间结构”

再和以 Claude Code 为代表的 vibe coding 相比，OpenClaw 和它相比最大的不同点在哪里？现在 Claude Code 也有 memory、cron 任务等机制，业界有种声音认为他们没啥区别。

我的判断很明确：Claude Code / vibe coding、OpenClaw、Manus/各类 hosted claw，看起来都在长 memory、skills、subagents、automation，但它们的“系统本体”不是一回事。

真正该比较的，不是“有没有 memory / cron”，而是这三个问题：

• 它默认把“世界”建模成什么？

• 它把长期状态、权限和执行面安放在哪里？

• 它最终想垄断的是哪一层入口：repo、channel/device，还是 cloud workbench？

把这三问想清楚，很多“它们没啥区别”的说法就站不住了。

三者的本体定位

Claude Code 的本体是 repo-centric coding agent。它默认世界是“一个代码库 + 一组命令 + 一些外部工具”。它的记忆是 CLAUDE.md、auto memory、subagents、skills、hooks、MCP；它的主战场是 IDE/CLI，核心目标是把“理解代码—改代码—跑命令—提 PR”做成高密度闭环。

OpenClaw 的本体是 identity/channel/device-centric agent runtime。它默认世界不是 repo，而是“一个 always-on Gateway + 多个 channel + 多个 agent workspace + 多个 node/device + 一个持续运行的控制面”。官方文档把 Gateway 定义成一条常驻进程，统一承载 routing、control plane 和 channel connections；memory 的 source of truth 是 workspace 里的 Markdown；cron 是 Gateway 内建调度器；browser、nodes、canvas 都是一等 typed tools；group chats、WhatsApp、Telegram、Discord、Slack、iMessage、Teams 等是原生通道，不是后接插件的小附庸。

Manus 的本体则是 task-centric cloud computer。它默认世界是“给每个任务配一台云端电脑”，让 agent 在这个 sandbox 里长期执行。Manus 官方把 Sandbox 定义为“每个任务一个完全隔离的 cloud VM”，文件、浏览器、网络、软件工具都在里面；Wide Research 又把 per-session VM + subagents 并行化做成核心能力；Slack Connector、Project Skills、Browser Operator 这些产品都围绕“把云端执行力变成标准化工作界面”展开。

为什么“都有 memory / cron”并不意味着“没区别”

因为 memory 和 cron 只是器官，不是物种。

Claude Code 里的 memory，本质上是在为代码工作树补充持久上下文。官方写得很明确：每个 session 都是 fresh context window，跨 session 依靠 CLAUDE.md 和 auto memory；而且 auto memory 的 scope 是 per working tree，目标是记住 build commands、debugging insights、project conventions。也就是说，它的记忆是围绕“这个项目怎么写、怎么测、怎么跑”组织的。

OpenClaw 的 memory，本质上是在为一个常驻agent runtime 提供可审计、可编辑、离线优先的长期人格/经历层。它不是“项目说明书优先”，而是“workspace 事实优先”；文档明确说 memory 是 plain Markdown，文件才是 source of truth。这个设计会天然偏向长期代理、跨会话人格连续性、跨渠道一致性，而不是单 repo 协作。

同样，Claude Code 当然也有 background processes、hooks、长期运行命令、甚至 SDK 可编程代理能力，但官方公开文档里没有一个与 OpenClaw Gateway “内建 cron scheduler” 对应的一等官方能力页。相反，OpenClaw 的 Cron Jobs 页面明确写着：Cron 是 Gateway built-in scheduler，负责持久化任务、按时唤醒agent、并可把输出投递回 chat。也就是说，OpenClaw 的调度不是“让模型顺手跑个定时脚本”，而是系统内核的一部分。

所以，表面看都在长“记忆、自动化、技能”，本质上却是三种不同的时间结构：

• Claude Code：session-based coding continuity

• OpenClaw：always-on agent continuity

• Manus：task-lifecycle continuity

七、最大差异：“谁是第一公民”

Claude Code 和 OpenClaw 最大的不同点，不在“能不能写代码”，而在“谁是第一公民”。

Claude Code 把代码库当第一公民；OpenClaw 把 agent runtime 当第一公民。

Claude Code 的一切强项，几乎都围绕这个前提展开：它把 repo 视作主世界，把文件、Bash、测试、PR、IDE、MCP 服务器都组织成“代码生产链”的延伸。它连 memory 都是 project/user/org 分层，subagent 也主要是为了更好地分拆 coding/research/planning 任务，hooks 也是围绕 tool-use 安全与格式化后处理。换言之，Claude Code 的终点是 better software throughput。

OpenClaw 则不是这样。它当然也能编码，甚至能把 coding agent 作为一个 agent workspace 跑起来；但它的系统设计核心不是“一个 IDE 里的超强 copilot”，而是“一个总控网关，把模型、渠道、设备、记忆、浏览器、移动节点、定时任务和多 agent 路由统一起来”。官方文档写得很清楚：Gateway 是 always-on process；agents 可以有独立 workspace、session store、SOUL/AGENTS/USER 文件；group chats 在 WhatsApp/Telegram/Discord/Slack/iMessage/Teams/Zalo 间统一抽象；browser 可以走 node proxy；remote access、trusted proxy auth、pairing 都是第一层概念。这个系统的终点不是更好的 PR throughput，而是 more surfaces under one agent control plane。

八、三者终极目标

三者看似都在“调模型 + 调工具”，但：

• Claude Code 在经营 developer cockpit

• OpenClaw 在经营 personal/organizational agent OS

• Manus 在经营 managed AI work computer

OpenClaw SaaS化之后，会变成 Manus 吗？

这里我会分成三类，而不是一锅煮。

第一类：IaaS/云厂商代部署型

腾讯云和阿里云这类，更接近managed OpenClaw infrastructure，不是 Manus。腾讯云公开写的是：几秒在云上部署 OpenClaw，7x24 在线，接入WhatsApp/Telegram/Discord/Slack/企微/QQ/钉钉/Lark；而且 Lighthouse 被描述为 OpenClaw 的官方推荐部署平台。阿里云 Compute Nest 的说法也类似：提供 OpenClaw 的 one-click deployment solution，自动化端到端设置。这里卖的核心不是“一个全新 agent 产品范式”，而是把原本需要用户自己抗的运维、镜像、网络、实例配置、持续在线，打包成云基础设施服务。这类产品离 Manus 还有本体差异：它们通常仍然以“帮你托管你的 OpenClaw runtime”为主，而不是把“每个任务一台云电脑 + 连接器 + task board + 项目技能库”做成主抽象。

第二类：模型厂商托管型 hosted claw

MaxClaw 这种，已经更接近 Manus 一步了。MiniMax 官方 FAQ 直接写：MaxClaw 是 built on the open-source OpenClaw framework，用户不需要部署服务器、配置 Docker、管理 API key，一键 10 秒创建 agent；它同时把 OpenClaw 和 MaxClaw 的差异定义为：前者面向想本地部署、深度自定义的开发者，后者面向零代码云托管。这个定义很关键：它说明 MaxClaw 不是单纯卖云主机，而是在卖被模型厂商收口后的托管 agent 产品。这种 hosted claw 和 Manus 的相似度就明显提高了，因为它们都在做三件事：

1. 把部署摩擦抽掉；
   

2. 把模型选择和运行时收口；
   

3. 把“agent 成果”而不是“agent 架构”卖给普通用户。

但它和 Manus 仍有差异：MaxClaw 的骨架仍然是 OpenClaw-derived runtime。它更多是在“把 OpenClaw 产品化、收口化、云托管化”，而 Manus 从一开始就把“任务云电脑 + 执行型工作台”当本体。这个起点不同，会导致后续产品气质不同。

第三类：产品化到近 Manus 的 claw

Kimi Claw 这类方向已经出现。基于能核实到的材料，它正在向 hosted-claw / productized-claw 演化的方向发展。

所以：OpenClaw SaaS化之后，会不会和 Manus 越来越像？

会像，但只会在“用户感知层”像，不会在“架构本体层”自动等同。这是我最想强调的一点。

一旦 OpenClaw 被 SaaS 化，用户看到的界面可能越来越像 Manus：不用自己配服务器、不用自己配模型、直接一个网页/控制台、开箱即用、持久在线、也有skills / memory / automation / browser / integrations。于是大家就会说：这不就是另一个 Manus？

但从我的角度看，像不像，要看它SaaS 化之后，保留的是哪一个“根抽象”：

如果保留的是 OpenClaw 根抽象，也就是：Gateway 还是系统心脏、channels / nodes / agent workspaces / routing 还是第一层、用户依然能理解和控制 runtime、agent identity、channel surface、记忆仍是用户可持有、可迁移、可审计的 workspace state。那它即使做成 SaaS，仍然是 managed agent OS，不是 Manus。这条路的本质是“把 agent runtime 云服务化”。

如果根抽象变成 Manus 式，也就是：用户主要面对的是 task board / project space / connector hub、背后是 per-task 或 per-session cloud sandbox、用户不再真正感知 gateway/channel/runtime 结构、技能更偏 workflow asset而不是 agent runtime extension、价值叙事从“拥有一个 agent”变成“交付一个完成的任务”。那它就已经不是单纯的 OpenClaw SaaS 了，而是在往 Manus 类产品跃迁。

所以问题不在于“是否云端”，而在于云端化之后，谁还拥有系统语义解释权。是用户拥有自己的 agent runtime，还是平台拥有任务执行操作系统？

九、未来分水岭

我觉得接下来业内真正分水岭，不是“谁的模型更强”，也不是“谁先长出 memory / cron / skill”。而是三件更底层的事：

1. 谁掌握“长期状态”的主权

Claude Code 的长期状态更依附于 repo/worktree；OpenClaw 的长期状态更依附于 agent workspace；Manus 的长期状态更依附于平台task/project/sandbox。状态放在哪里，商业权力就长在哪里。repo 主权偏开发者；workspace主权偏用户/组织；task/project 主权偏平台。

2. 谁掌握“执行面”的默认入口

Claude Code 的入口是 IDE/CLI。OpenClaw 的入口是 messaging/channel/device。Manus 的入口是 cloud workbench / browser-based task UI。入口不同，决定了谁更像“工作流插件”，谁更像“下一代操作系统”。

3. 谁敢承担“常驻代理”的安全与运维复杂度

OpenClaw 这条路的伟大，也在于它最脏最难：always-on、多渠道、多节点、高权限、prompt injection、trust boundary、配网、认证、远程访问，全是系统工程难题。官方安全文档就反复强调 loopback-first、non-loopback 认证、shared-agent 权限边界等问题。Claude Code 因为更靠近开发环境，复杂度更集中在工具权限、repo 上下文、MCP 风险；Manus 则把复杂度平台化、托管化，用 sandbox 和平台策略吃掉。

十、写在最后

Claude Code 不是 OpenClaw 的替代品，OpenClaw 也不是 Claude Code 的劣化版。它们只是都在使用“agentic primitives”，但服务的是不同的主权结构。

• 你想让 AI 更像一个顶级工程搭档，深入repo、命令、测试、PR，Claude Code 路线最强。

• 你想让 AI 成为常驻、跨渠道、跨设备、可自持的数字代理，OpenClaw 路线更有想象力。

• 你想把“交付工作结果”直接产品化、SaaS 化、云工作站化，Manus/hosted-claw 路线更有商业规模感。

所以我不会说“它们没区别”。我会说：它们正在共享越来越多的 agent 器官，但仍然拥有不同的系统灵魂。