就在前天，Manus 在国内媒体间爆火， 其号称 “ 全球首个通用 AI 智能体 ”。

官方也晒出了几十个Demo，供大家玩赏。

网友们惊艳于其效果后当然跃跃欲试，却发现试用需要邀请码。我们问了一圈 AI 专家，都说没用过，也没听自己哪个同行用过， “ 目前都是媒体在用吧？”

到这里就需要谨慎了，没有较大规模公开测试、没有专家实名自发背书过的技术或产品 （ ChatGPT、NotebookLM、DeepSeek 等都是有的 ），实力终归是存疑的。

从产品体验来看， Manus 虽然效果惊艳，但是很多人其实不买账，因为写 PPT、写 HTML、Python 数据分析、生成 Excel、搜索等功能目前各个通用模型都能做。 即便 Manus 说自己比 OpenAI 的 DeepResearch 更厉害，但这和 Cursor 说自己比 Claude 更厉害有什么区别？两者的可比性是相对错位的。

功能上，Manus 是整合了 Computer use、虚拟机、Multi agent 协同的套壳产品。技术实现上是基于 Claude 模型生成能力、开源模型后训练增强的规划能力，再结合各种预制的 Agent， 按照设定好的工作流：构建 todo 清单、新建虚拟机环境、调用工具、结果整合、自我检查、输出结果，来解决任务。

所以， Manus 技术上有其复杂性，但没有太多创新，当然，其功能多样性导致工程量极大，业内专家认为很有可能是基于 MCP 协议的聚合模式。

过去 Agent 更多是在专业领域做深耕，而 Manus 通过工程上极致整合、酷炫低门槛的 UI 交互套壳产品想让 Agent 直接出圈了。

总有人说， 套壳到极致就是胜利，就是价值，确实，至少从 Manus 的演示视频来看，是这样。

既然有价值，那么很快就会有人跟上，这不，为了实现 Manus 的价值，MetaGPT 团队花费了 3 小时开发了 OpenManus 并开源，无需邀请码就能使用。

项目地址：https://github.com/mannaandpoem/OpenManus

在项目的演示视频中，输入提示词：“对 Karpathy 的网站 （ https://karpathy.ai/ ）进行全面的 SEO 审核，并提供详细的优化报告，包括可操作的改进建议。”

接下来，OpenManus 会展开思考，拆分执行步骤：

•检查网站，收集基本信息；

•分析关键SEO要素；

•检查 SEO 技术方面的问题；

•整理优化建议；

接下来就是一步一步地执行任务了。

可以看到 ，演示视频展示的结果远不如 Manus 那么细致和丰富，OpenManus 目前功能还很初级， 但团队还公开了后续的开发路线，照这个路线，基本上全面复刻 Manus 不是问题：

• 更优的规划系统

• 实时演示功能

• 运行回放

• 强化学习微调模型

• 全面的性能基准测试

：OpenManus 是怎么来的？

：两个月前的一次边吃饭边头脑风暴的过程中，我们想到，一个极简的 Agent 框架，应该是可插拔的 Tools 和 System Prompt 的组合，之后我们沿着这个思路，写了一个完整的 Agent 迷你框架。

前天晚上看到 Manus 时，凌晨就和同事商量，下班后的晚上就可以搞一个，应该 3 小时够了。

：为什么要采用可插拔的 Tools 和 System Prompt？

： 决定一个 ReAct Agent（ Reasoning and Action Agent，一种结合了反应和行动规划能力的智能体 ）的效果的关键是 Prompt（ 提示信息 ）和 Action（ 行动 ），Prompt 控制了 Agent 整体的行为逻辑，Tools 给定了 Agent 的行动空间，二者被定义就能完整诠释一个 ReAct Agent。

可插拔的优点是可组合，我可以把几个不同场景下的 Tools 组合到一起来创造一个新的 Agent，定义也很方便，不需要单独写内部逻辑，只需要修改动作空间 （ Tools ）。Tools 本身就该是可组合的，我们的工作是把抽象做得更干净，目前 HuggingFace 的 Smolagents 也是类似的思路了。

Manus 效果上让大家觉得很新奇，实际上主要是由于 Browser Use 和 Computer Use 的使用，所以只要给了 Agent 这两个工具，那它就都能做到。

：OpenManus 在实现中，有哪些关键技术挑战？

：在 OpenManus 的实现中，前端界面的实现很关键。Manus 很出彩的地方是产品展示很漂亮，我当时打算用 Streamlit 写前端，方便做类似的展示，但 Streamlit 的底层和 Browser Use 冲突，后来就换了 Gradio，但信息展示有一些问题，当时没办法做到实时更新，最后还是改成了 log，直接在命令行里做展示。

如何有效复现和优化 PlanningTool 的使用也是非常重要的一环，这样才能充分发挥 Agent 的规划和工具调用能力，探索其能力上限。Manus 的用例展示了 Agent 在线性任务规划中的强大表现，而 OpenManus 需要解决如何设计更复杂的规划结构 （ 如使用 DAG 有向无环图表示任务依赖关系 ），以及如何让 Agent 动态更新规划以适应变化的需求，这不仅考验技术实现，还涉及算法设计和智能体的自适应能力。

目前 OpenManus 的规划设计与 Manus 保持一致，都是线性的，而DAG规划对于处理现实世界中更复杂的任务，在一定程度上会更准确，Data Interpreter 就是一个很好的例子。

：听起来 OpenManus 的规划已经有要超越 Manus 的苗头了，你们对这个产品有什么期望吗？

：OpenManus 前期目标打算达到原始 Manus 的相同的效果，后续会不断优化 Computer Use、Browser Use 和 Planning Use，以及工具调用的能力， 从而超越 Manus。

Manus 产品交互做的挺好的，有很多技术也值得学习，比如对后训练技术的结合，流程设计上比如规划、Multi Agent 系统也是很优秀的，具体细节我们还在研究。至于 OpenManus 我们没有单独调效果，目前达到的效果其实很一般。后续主要靠开源社区小伙伴来贡献，我们希望开源协作能带来更高的智能涌现～

好了，到这里知危编辑部与 MetaGPT 团队的沟通就到这里了，我们也可以期待一波 OpenManus 未来的效果。

最后，或许我们可以探讨一下到底什么应该是好的 Agent ？

Manus 有优点、有亮点，但有夸大之嫌。人们在试用的时候，还是能发现 Manus 有不少毛病，用错了假数据、来源引用错误、表格读取错误等等毛病一个不落，幻觉问题还是不小。

Agent 应用的一大通病是，自动化执行过程越复杂，错误发现和查找原因就越困难，而且 Agent 的执行需要经过多个 LLM，每个 LLM 的幻觉一路累积下来的误差将是巨大的，比如 95% 的准确率，连续经过 10 个 LLM，最后准确率能直接降到约 60% 。

在全面拥抱 Agent 之前，我们首先还是得多关注一下，目前市面上的通用大模型，它们的幻觉率仍然不是一般的高。

所以，想实现真正好用的 Agent，我们仍然要攻克大模型底层能力的提升。里子不够好，套太多的壳也没用。

与此同时，我们还需要强调的一点是，追求 Agent 的过程中，我们一定是要回归实用主义的： 不是所有问题都需要用 Agent 来做。

Devin 前不久还被爆出出错率极高并且出错方式没有规律可循，还不如用 Cursor 一步一步来，加上之前的演示造假事件，过于激进的 Agent 产品越来越受到质疑。

与此同时，Agent 的一大通病是，步骤拆解越多，token 消耗量越大，对所有任务一律无脑使用 Agent，对于企业的成本控制而言具有极大的风险。

Agent 的最关键的作用就是工作流编排， 简单的任务其实并不需要 Agent 的参与，反而会导致客户等待时间过长。

Anthropic 就曾经分享过构建智能体的基本原则，就是 “ 简单为王，实用至上 ”， 能用 API 就不要用工作流，能用工作流就不要用智能体。

这些都是手段，哪个不能交付结果呢？

Agent 终究是一个产品概念，不像 LLM 有无法预测的潜在价值（ 比如推理能力的发现和增强 ）值得冒极大风险押注。