AI Manus 实测观察：一个把 Agent 循环和沙箱绑在一起的 Docker 方案
AI Manus是一个通用的AI Agent系统，支持在沙箱环境中运行各种工具和操作。
秒懂
- 它是什么？
- AI Manus 是一个通用 AI Agent 系统，用 Docker 沙箱隔离每个任务，通过原生工具调用驱动 plan-and-execute 循环。本文基于仓库文档和配置，拆解它的架构、部署方式和适用边界。
- 适合谁用？
- AI Manus 适合已经熟悉 Docker Compose、并且愿意接受沙箱隔离开销的团队或个人开发者，尤其是那些需要浏览器操作、代码执行和外部 MCP 工具组合的场景。它不适合没有 Docker 环境、或者只想快速调用一个 API 完成简单任务的人，因为最小部署也要求 Docker 20.10+ 和 Compose。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是 Agent 运行环境的隔离问题
AI Manus 的核心主张是每个任务都跑在独立的 Docker 沙箱里。文档描述得很清楚：用户发起对话后，Web 端请求 Server 创建 Agent，Server 通过 /var/run/docker.sock 创建一个 Ubuntu 容器，容器内启动 Chrome 和 File/Shell 的 API 服务。这个设计解决了一个实际问题：Agent 要执行代码、浏览网页、读写文件，这些操作如果不隔离，可能污染宿主机或者相互干扰。它面向的是需要让 Agent 做真实操作的开发者，而不是只做文本问答的人。沙箱不是可选项，而是架构的一部分，这决定了它的部署方式和资源消耗。
plan-and-execute 循环如何避免 JSON-in-prompt 的脆弱性
AI Manus 的 Agent 循环采用 plan-and-execute 模式。Server 收到用户消息后，转发给 PlanAct Agent，这个 Agent 内部有 planner 和 executor 两个角色。关键点在于，计划和步骤结果是通过原生工具调用提交的，比如 create_plan 和 complete_step，而不是把 JSON 塞进提示词里。文档明确说这是 native structured output tools，没有脆弱的 JSON-in-prompt 协议。这意味着它依赖 LLM 的原生函数调用能力，而不是让模型从文本里解析 JSON。对于熟悉 LangChain 的人来说，这减少了格式错误导致的失败，但也把模型的可用范围限制在支持工具调用的提供商上。Deepseek 和 GPT 被推荐，说明不是所有模型都能跑。
从浏览器查新闻到代码生成，工具集是它的卖点
仓库里给出了三个演示任务：代码使用、浏览器使用、多会话切换。浏览器场景是查最新新闻，代码场景是写一个复杂的 Python 示例。这些演示展示了工具的实际形态：Terminal、Browser、File、Web Search、消息工具，还支持外部 MCP 工具集成。浏览器工具的实现细节值得注意：沙箱内的 headless 浏览器通过 xvfb 和 x11vnc 启动 VNC 服务，再用 websockify 把 VNC 转成 WebSocket，前端用 NoVNC 组件连接。这意味着用户能实时看到浏览器操作，还能接管。这不是一个黑盒 Agent，而是可观察、可干预的系统。代码工具类似，通过沙箱内的 API 服务执行。
部署是 Docker Compose 的一站式流程，但配置项藏在 .env 里
部署方式很直接。文档给出一个 docker-compose.yml 示例，包含 frontend 和 backend 两个服务，backend 挂载了 /var/run/docker.sock 并依赖 sandbox 服务。所有配置都从 .env 文件加载，最小设置是三个键：API_KEY、API_BASE、MODEL_NAME。示例值是 gpt-4o 和 OpenAI 的 API 地址。运行 docker compose up -d 后，访问 localhost:5173。文档特别提醒，如果看到 sandbox-1 exited with code 0 是正常的，因为沙箱容器只是用来确保镜像拉取成功。这个细节说明沙箱的生命周期和 backend 不同，它不是常驻服务。开发模式有单独的 dev.sh 脚本，会启动多个端口，包括 5678 的 debugpy 和 5902 的 VNC。
会话状态依赖 MongoDB 和 Redis，这不是一个轻量工具
任务会话的历史记录通过 MongoDB 和 Redis 管理，支持后台任务。这意味着 AI Manus 不是一个单进程工具，而是一个由前端、后端、沙箱、数据库组成的系统。文档里没有给出这些服务的详细配置，但 docker-compose 示例里没有显式写出 MongoDB 服务，可能是内置在 backend 镜像里，或者需要用户自己添加。无论如何，运行它需要管理多个容器的资源。开发模式下只启动一个全局沙箱，但生产环境每个任务都会创建一个新容器，这会导致容器数量随任务增长。对于长期运行的服务，需要考虑 Docker 的清理策略，否则磁盘会被镜像和容器占满。文档的 roadmap 里提到要支持 K8s 和 Docker Swarm，说明当前的多集群部署还不成熟。
限制：沙箱创建依赖 Docker socket，这既是功能也是风险
backend 挂载 /var/run/docker.sock 是必须的，因为每次任务都要创建沙箱。这带来两个问题。第一，安全上，挂载 Docker socket 意味着 backend 进程拥有宿主机的 Docker 控制权，如果 backend 被攻破，攻击者可以控制宿主机上的所有容器。这是常见的 Docker-in-Docker 风险，文档没有提到任何缓解措施。第二，功能上，如果宿主机没有 Docker 或者 socket 权限不对，整个系统无法工作。文档要求 Docker 20.10+，这排除了旧版本环境。另外，文档说沙箱是 Ubuntu 环境，但 roadmap 提到要支持移动端和 Windows 访问，说明当前沙箱不覆盖这些平台。对于只需要简单文本生成的任务，这个系统明显过重。
替代方案：Docker 沙箱 vs 托管执行环境
如果想避免自己管理 Docker socket，可以考虑使用托管式的 Agent 执行环境，比如 OpenAI 的 Code Interpreter 或 E2B。这些服务提供远程沙箱，你不需要挂载 Docker socket，只需要调用 API。区别在于，AI Manus 让你完全控制沙箱镜像和网络，而托管服务把沙箱生命周期交给第三方。另一个替代方向是直接用 LangChain 的 Agent 框架，不引入沙箱，让 Agent 在本地执行工具。这样更轻量，但失去了隔离性，代码执行可能影响宿主机。AI Manus 的取舍是：用 Docker 的隔离能力换取安全性，代价是部署复杂度和资源开销。如果你已经有 Docker 基础设施，这个取舍可能划算。
编辑结论
AI Manus 适合已经熟悉 Docker Compose、并且愿意接受沙箱隔离开销的团队或个人开发者，尤其是那些需要浏览器操作、代码执行和外部 MCP 工具组合的场景。它不适合没有 Docker 环境、或者只想快速调用一个 API 完成简单任务的人，因为最小部署也要求 Docker 20.10+ 和 Compose。在采用前，先验证你的 LLM 提供商是否支持原生工具调用，因为文档明确说依赖 create_plan 和 complete_step 这类结构化输出，而不是 JSON-in-prompt。还要确认 /var/run/docker.sock 的挂载权限，这是沙箱创建的关键路径，权限配置错误会直接导致任务无法启动。如果这些条件都满足，AI Manus 提供了一个可审计、可中断的 Agent 运行框架，但它的维护成本取决于你对 Docker 镜像更新和 MongoDB/Redis 状态的接受程度。
社区笔记