摘要：尽管其效果令人赞叹，但许多网友在尝试使用时却发现需要邀请码。我们咨询了几位AI专家，他们纷纷表示未曾使用过此工具，也没有听说过同行使用。“现在看来，只有媒体在使用吧？” 这一情况让人不得不谨慎对待。

近日，一款名为Manus的AI智能体在国内媒体中迅速走红，声称是“全球首个通用AI智能体”。官方展示了数十个演示案例，供公众欣赏。

尽管其效果令人赞叹，但许多网友在尝试使用时却发现需要邀请码。我们咨询了几位AI专家，他们纷纷表示未曾使用过此工具，也没有听说过同行使用。“现在看来，只有媒体在使用吧？” 这一情况让人不得不谨慎对待。

没有大规模公开测试和权威专家的实名推荐，新技术或产品的实力总是存在疑问。从用户体验的角度来看，尽管Manus效果出色，但仍有许多人对其持保留态度。因为目前许多通用模型已经具备撰写PPT、编写HTML、进行Python数据分析、生成Excel和搜索等功能。即使Manus宣称自己比OpenAI的DeepResearch更为先进，这种比较显得有些不合时宜。两者之间的对比更像是苹果与橙子的比较。

Manus整合了计算机使用、虚拟机和多代理协同工作的功能。其技术实现基于Claude模型的生成能力和开源模型的增强规划能力，再结合预设的代理，按照预定的工作流程完成任务：创建待办事项列表、搭建虚拟机环境、调用工具、整合结果、自我检查并最终输出结果。因此，Manus在技术上确实复杂，但缺乏创新。不过，其功能多样性使得工程量巨大，业内专家认为这可能是基于MCP协议的聚合模式。

以往，代理通常专注于特定领域的深入研究。而Manus则通过极致的工程整合和简洁易用的用户界面，试图让代理走出专业领域，进入大众视野。有一种说法认为，如果将产品做到极致，就是胜利，就是价值。至少从Manus的演示视频来看，这一观点似乎得到了验证。

既然有潜力，很快就会有人跟进。为了实现Manus的价值，MetaGPT团队仅用了3小时便开发出了OpenManus，并将其开源，用户无需邀请码即可使用。

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

在项目的演示视频中，输入指令：“对Karpathy的网站（https://karpathy.ai/）进行全面的SEO审核，并提供详细的优化报告，包括可操作的改进建议。” OpenManus会逐步执行任务：检查网站、收集基本信息、分析关键SEO要素、检查技术问题、整理优化建议。

从目前展示的结果来看，OpenManus的功能相对较为基础，但团队已经公布了详细的开发路线图。按照这一路线，全面复刻Manus并非不可能：

MetaGPT团队如何实现OpenManus

两个月前，MetaGPT团队在一次边吃饭边讨论的过程中萌生了开发极简Agent框架的想法。他们认为，一个理想的Agent框架应由可插拔的工具和系统提示组成。于是，他们沿着这一思路，编写了一个完整的Agent迷你框架。前天晚上看到Manus时，团队决定立即动手，预计3小时内可以完成。

为何选择可插拔的工具和系统提示？

MetaGPT团队认为，决定一个ReAct Agent（一种结合了反应和行动规划能力的智能体）效果的关键在于提示信息（Prompt）和行动（Action）。提示信息决定了Agent的整体行为逻辑，工具定义了Agent的行动范围。这两者被定义清楚后，就能完整诠释一个ReAct Agent。可插拔的优势在于其组合性，可以通过组合不同场景下的工具来创造新的Agent，而无需编写复杂的内部逻辑。目前，HuggingFace的Smolagents也采用了类似的思路。

Manus之所以给人新鲜感，主要是因为它充分利用了浏览器和计算机的使用。只要给Agent这两个工具，它几乎可以完成所有任务。

OpenManus在实现过程中面临哪些挑战？

在OpenManus的实现过程中，前端界面的设计至关重要。Manus最出彩之处在于其产品展示非常精美，团队最初计划使用Streamlit编写前端，但由于与浏览器使用的冲突，最终选择了Gradio。然而，信息展示仍存在问题，无法做到实时更新，最后改为在命令行中展示日志。

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

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

MetaGPT团队对OpenManus有何期望？

OpenManus的初期目标是达到与原始Manus相同的水平。随后，团队将继续优化计算机使用、浏览器使用和规划使用，以及工具调用的能力，以期超越Manus。Manus的产品交互做得相当不错，很多技术细节值得学习，例如对后训练技术的结合和流程设计上的规划和多代理系统的优秀表现。至于OpenManus，目前的效果尚属一般。团队希望通过开源社区的力量来推动其发展，期待更高的智能涌现。

至此，知危编辑部与MetaGPT团队的交流告一段落。我们也可以期待OpenManus未来的进步。

什么样的Agent才算好？

Manus有其优点和亮点，但也存在夸大之嫌。在实际使用中，Manus存在不少问题，如使用错误数据、引用错误、表格读取错误等。幻觉问题依然严重。随着自动化执行过程变得复杂，错误发现和原因查找变得愈发困难。Agent的执行需要经过多个大型语言模型（LLM），每个LLM的累积误差可能大幅降低最终结果的准确性。因此，在全面拥抱Agent之前，我们需要更加关注当前市场上通用大模型的幻觉率。

实现真正好用的Agent，还需提升大模型的基础能力。如果没有坚实的基础，再多的外壳也无法弥补缺陷。同时，我们也需要坚持实用主义：并不是所有问题都适合用Agent解决。Devin近期被曝光的高错误率和无规律的错误方式，使其在某些情况下还不如手动操作。此外，Agent的一大通病是，步骤拆解越多，消耗的token越多，对企业成本控制构成威胁。Agent的关键作用是工作流编排，简单的任务并不需要Agent的参与，否则可能导致客户等待时间过长。

Anthropic曾分享过构建智能体的基本原则，即“简单为王，实用至上”。能用API解决的问题就不要用工作流，能用工作流解决的问题就不要用智能体。这些都是手段，哪个不能交付结果呢？

Agent终究是一个产品概念，不像大型语言模型那样具有无法预测的潜在价值，如推理能力的发现和增强。因此，我们应该更多关注开源社区的新技术，如阿里在Manus发布同一天开源的QWQ-32B模型。在追求Agent的过程中，我们应该更关注模型的突破。

来源：兔兔科技