Manus的选择：MCP vs. CodeAct

Manus在2025年初引起了广泛关注。乍一看，它像是一个典型的多代理系统——但它的背后还有更多值得关注的地方。

1、初试Manus

我决定亲自测试一下Manus。首先，我让Manus比较Java开发人员、数据工程师、机器学习工程师和数据科学家的薪资和工作机会。它没有简单地返回一些通用的答案，而是精心创建了一个待办事项清单，确定了信息收集的位置，并使用浏览器收集了所有必要的信息，从网页中提取数据，并生成了一份结构良好的报告。虽然有一些小问题，但它完成得相当不错。

然后，我给它抛出了一个难题。我要求它比较不同郊区的房价，故意包含了一个拼写错误和一个完全虚构的地点。令人印象深刻的是，Manus发现了这两个错误，询问我是否要修正拼写错误并忽略虚构的郊区。最终，它甚至生成了一份带有精彩对话的报告。结果虽然仍不完美，但确实令人印象深刻。

最让我印象深刻的一点是：在做任何事情之前，Manus首先创建了一个沙盒并设置了环境。与其他更倾向于隐藏细节的AI供应商不同，Manus将一切都摆在了桌面上：

不久前，有人自豪地宣布他们成功越狱了Manus。开发者的反应？轻描淡写地耸了耸肩——“这就是它的设计方式。”：

在另一篇帖子中，Manus甚至揭示了自己的内部结构：

这是一个不同寻常的设计。大多数公开的AI系统都会隐藏其内部运作，仅向用户展示最基本的界面。但Manus呢？这种架构与那些倾向于接受MCP协议的代理型系统截然不同。

那么，让我们退一步思考：为什么Manus采取了这种独特的做法？MCP的优点和缺点是什么？什么时候应该使用或避免使用它？

2、MCP简介

如果你一直在关注AI领域，你可能已经注意到了围绕MCP的突然热潮。最近，我的整个通讯录都被人们讨论MCP的文章淹没，他们询问MCP是什么，或者只是好奇为什么它会成为趋势。有些人说Cursor + MCP统治一切。尽管这个概念只出现几个月，已经有了几个MCP服务器，甚至MCP服务目录。

但认真地说——MCP到底是什么呢？让我们仔细看看。

代理式开发被广泛认为是未来的方向，它能让生成式AI超越仅仅作为一个聊天机器人。通过这种方式，AI应用程序可以主动收集信息并采取有意义的行动。

然而，生成式AI应用程序之间还没有标准化的交互方式。每个代理传统上都是手工制作的，为了让应用程序识别它们，开发者必须手动定义每一个代理。

MCP是一个开放协议，它标准化了应用程序如何为LLMs提供上下文。你可以把MCP想象成AI应用的USB-C接口。就像USB-C提供了连接设备到各种外围设备的标准方式一样，MCP提供了连接AI模型到不同数据源和工具的标准方式。
— Anthropic

令人惊讶的是，许多入门文章并没有正确解释MCP。根据官方文档，MCP架构有以下主要组成部分：

2.1 MCP客户端

客户端是一个基于LLM的界面或工具（如Claude for Desktop或代码编辑器如Cursor），它可以发现并调用MCP服务器。这是将用户的文本提示转化为实际函数调用的方式，而无需频繁切换系统。

2.2 MCP服务器

在MCP术语中，服务器是指暴露资源或工具给模型的东西。例如，你可以构建一个提供“get_forecast”功能（工具）或“/policies/leave-policy.md”资源（类似文件的内容）的服务器。服务器管理以下组件：

• 工具：模型可以在用户批准后调用的功能（如createNewTicket、updateDatabaseEntry）。
• 资源：模型可以读取的文件类数据，如“company_wiki.md”或代表财务记录的数据集。
• 提示：帮助模型执行特定任务的模板化文本。

2.3 MCP协议

MCP的核心在于客户端和服务器之间的通信协议，该协议允许客户端访问服务器的资源、工具和提示。

2.4 为什么命名为MCP？

上下文的概念非常模糊。如果没有对这个概念的清晰理解，可能会在开发符合MCP标准的解决方案时遇到麻烦。当我第一次听说MCP时，我以为它可能与交互历史优化有关，因为上下文在LLM开发中的含义最接近于此。不出所料，很多人都对这个词感到困惑。看看你听到多少人谈论MCP和“最优长短期记忆”？有些人甚至认为MCP代表“记忆、上下文和个人化”。

嗯，幻觉可不是开玩笑的。

官方MCP文档写得很糟糕。它并没有清楚地解释主要概念。我在GitHub上找到的关于上下文的最直观解释如下：

合理猜测MCP是关于连接客户端、服务器和模型的设施。它与对话历史无关。上下文是保持组件通信的信息，而不是提示的上下文。另一个支持这种理解的是Anthropic提到的路线图目标之一是使远程操作无状态，这意味着MCP服务器不会维护对话历史：

MCP的快速采用解释了它作为一个互操作协议的成功。话虽如此，让我们反过来看看一个相反的解决方案。

3、CodeAct

通用LLM代理应用程序要么使用模板提示，要么简单地允许LLM“一步一步地思考”来计划，然后使用工具采取行动。CodeAct是由XingYao Wang在他的论文中发现的有趣发现：

他注意到LLM在推理代码时的表现优于文本或JSON：

这一发现启发了Manus团队开发了一种类似于CodeAct的解决方案，而不是接近MCP。MCP比Manus晚出现，但开发类似的解决方案并不困难。

4、MCP与CodeAct对比

在代理式开发中有两个主要挑战：

1. 如何使解决方案可靠，
2. 如何使解决方案可扩展。

显然，Manus和Anthropic选择了不同的方向。MCP使得代理服务更容易被发现和重用。而Manus则更感兴趣于提高服务的可靠性。根本的区别在于Manus选择了集中式规划，而MCP将规划任务分散到各个独立的服务器。使用CodeAct作为推理引擎，Manus有可能实现更好的性能。

从这个角度来看，一个符合MCP的应用程序可能更容易嵌入令人印象深刻的智能功能。然而，仍然可能因工作流中断和奇怪的结果而受到严重影响。MCP只提供了一个通信协议。客户端不知道服务器如何处理请求。MCP服务器可能拥有强大的AI能力，但客户端并不关心。MCP服务器更像是简单的功能提供者。MCP没有提供客户端-服务器和服务器-服务器协作的机制。正如Manus的首席执行官所说，MCP导致了一个冗长且低效的系统。

MCP的成功是一个合理的里程碑，但仍然太年轻。

例如，尽管MCP旨在提供通用生成式AI连接性，但目前，MCP只支持本地连接，因为团队尚未决定最佳的身份验证和授权方式。如果你花5分钟浏览一下MCP服务器目录就会明白，它的大多数功能其实只是对现有功能的薄层封装。作为本地服务封装的MCP所带来的附加价值相当有限。

而且恐怕愿望清单会比这个长得多。

5、离别之言

各大人工智能厂商已经提供了相当多的Agent开发框架。每个框架都反映了它们对Agent新世界理解的不同哲学。MCP的成功证明了它回答了一个许多其他厂商忽略的问题：服务发布。

尽管如此，我们应该记住，人工智能行业正在以前所未有的速度发展。一切都变化得如此之快，以至于今天的前沿技术可能在两个月后就完全过时。你还记得RAG吗？它不久前还是一个非常棒的新概念，而现在你可以使用至少18种技术来提升它的性能。

Agent开发也是如此。每天都有新的想法涌现。现在就宣布某个解决方案为赢家还为时过早。希望一个框架能创造奇迹更是有害的。不，MCP不会创造奇迹。它让低级服务集成变得更容易，但可靠性问题和幻觉问题仍然是你需要解决的难题。

最后但并非最不重要的一点，让我们参观一下失败框架博物馆：

• CORBA
• Enterprise Java Bean
• Jini
• DCOM
• Web Service Discovery Protocol

原文链接：MCP or not, Manus Made a Choice

汇智网翻译整理，转载请标明出处