今日凌晨，网友 @jianxliao 在 X 平台分享了他与 Manus AI 的一次“零距离接触”，随后迅速吸引近百万网友围观。事情起因并不复杂：该用户通过一个相对直接的操作请求（例如访问 /opt/.manus/ 文件夹），便成功获取了 Manus 的沙盒运行时代码。一时间，「Manus 被越狱」的消息在业内迅速传开。
但问题真的如此严重吗？就在刚刚，Manus 联合创始人 @peakji（季逸超）正式回应。他表示，这并非什么意外或漏洞，恰恰相反，这正是 Manus 设计的核心部分。简单来说，每位用户都能直接访问沙盒，这本身就是功能设计的一部分。
具体而言，这个沙盒实际上是一个受到严格限制的运行环境。它就像一个安全隔离区，开发者可以在其中测试新功能，即使代码写错，也完全不会影响整个系统的其他部分。
关于沙盒机制，有几个关键特点值得关注：
- 每个独立会话都拥有专属的沙盒环境，彼此完全隔离，互不干扰。
- 用户可以通过 Manus 的界面直接进入沙盒进行操作。
- 沙盒内的代码主要用于接收 agent 指令，因此仅做了轻度混淆处理，并未刻意严防死守。
换句话说，即使获取了沙盒代码，也完全无法威胁到系统的整体安全。Peak 强调，Manus 的设计思路并不神秘，其行动空间设计与学术界的常见方法同源。更重要的是，由于 Manus 采用了检索增强生成（RAG）机制，工具描述会随任务变化而变化。这意味着，即使用户试图通过“越狱”方式获取工具信息，最终也是徒劳——每次获得的结果都不相同。
Peak 进一步解释，Manus 采用的是多 agent 协作架构。用户与 Manus 交互时，实际上只与执行 agent 沟通，而该执行 agent 本身并不了解其他 agent 的具体情况。这种设计的高明之处在于，既能有效控制上下文长度，又避免了因信息过载导致的性能下降。Peak 直言：“这也是为什么通过『越狱』获得的信息，大多都是幻觉的原因。”
话说回来，Peak 坦诚团队使用了不少开源技术，并一直秉持开放的开源传统。“在不久的将来，我们会开源不少好东西。”他本人也长期在 Hugging Face 上分享训练好的模型。当被问及 Manus 的基础模型时，Peak 透露，当前使用的是基于 Claude 和 Qwen 的微调模型。早期团队只能使用 Claude 3.5 Sonnet v1（该版本不支持长链推理），因此当时需借助大量辅助模型来弥补不足。
Peak 还表示，团队正在内部测试 Claude 3.7，并会尽快推出相关更新。
技术细节与开源计划
有趣的是，Peak 也正面回应了一个热议话题：Manus 到底有没有使用 MCP（Model Context Protocol，模型上下文协议）。简单来说，可以把 MCP 想象成一个“万能接口”，就像电脑上的 USB-C 接口一样，能让 AI 模型轻松连接到各种外部资源，比如文件、数据库、在线服务。通过 MCP，AI 不仅能获取数据，还能直接对数据进行操作。
对此，Peak 的回答干脆利落：“实际上，Manus 并没有使用 MCP。”他坦言，团队更多是受到了朋友王星尧（@xingyaow_）研究工作的启发。那篇名为《Executable Code Actions Elicit Better LLM Agents》的论文，提出了一种名为可执行 Python 代码（CodeAct）的方法，能让 LLM agent 直接执行代码行为，从而将多种行为统一到一个更灵活、更强大的动作空间中。附上论文：该论文收录于 OpenReview 平台。
尽管 Manus 团队并未完全照搬 CodeAct，但这篇研究确实提供了三个非常关键的视角：
- 编写代码本身并非最终目的，而是一种通用的解决问题的方法。
- 由于 LLM 在编程方面表现出色，让智能体执行与其训练时最接近的任务，显然是最合理的选择。
- 这种做法能大幅减少上下文长度，并支持组合更复杂的操作。
最后，当被追问“为什么不用 MCP”时，Peak 的回答带着一种无奈又实在的幽默：“因为……Manus 早在 Model Context Protocol 推出之前就已经开始开发了？”