Knowledge / Docs / Articles/Research
public

Manus 技术深度调研（2026）：它到底是怎么把 Agent 跑起来的？

一篇尽量讲人话的 Manus 技术拆解：从上下文工程、并行多 Agent、Sandbox、浏览器自动化，到 Skills、MCP 和 API。重点讲清"它为什么能做成事"，也讲清"哪些地方还不透明"。

Manus 技术深度调研（更新于 2026-02-24）

这篇文章想回答一个很实际的问题：

Manus 为什么看起来不像普通聊天机器人，而更像一个“能自己把任务做完”的 Agent 系统？

我只用公开资料做拆解，尽量不用黑话。你看完应该能搞清三件事：

  1. Manus 的技术骨架到底是什么。
  2. 它现在真正公开了哪些能力。
  3. 如果你想自建类似系统，应该先抄哪一层。

先说结论（讲人话版）

Manus 的核心不是“某个神秘超强模型”，而是三件事叠在一起：

  1. 上下文工程（Context Engineering）：让模型在长任务里不容易跑偏。
  2. 执行环境（Sandbox + Browser）：让 Agent 真的能动手操作，而不是只会回答。
  3. 编排层（Multi-Agent + API + MCP）：把复杂任务拆开并行做，再汇总结果。

换句话说，Manus 的价值更像一个 Agent 操作系统，不是单一大模型。

一、Manus 到底是什么

从官方定位看，Manus 是“通用 AI Agent 平台”。 它强调的是“交付任务结果”，不是“陪你多轮聊天”。

这点和传统 Chatbot 最大区别在于：

  1. Chatbot 主要输出文字。
  2. Manus 重点是“在云端环境里执行动作，再回传结果”。

二、先看时间线（避免把新旧能力混在一起）

  1. 2025-08-31：官方发布 Context Engineering 技术文章，开始系统公开其 Agent 稳定性方法。
  2. 2025-12-29：官方发布 Wide Research，并在同篇文章中写明“Manus is now part of Meta”。
  3. 截至 2026-02-24：官方已公开较完整的 Features / Integrations 文档与开发者 API。

三、技术总架构：四层就够理解

你可以把 Manus 想成下面这个结构：

用户任务
  -> Agent 决策层（规划、拆解、工具选择）
  -> 编排层（单 Agent / Wide Research 多 Agent）
  -> 执行层（Sandbox、Cloud Browser、Browser Operator、文件系统）
  -> 集成层（Skills、MCP Connectors、Custom MCP、Data Sources、API/Webhook）

每一层都不新鲜，但 Manus 把它们“产品化地连起来了”。

四、最关键：它怎么做上下文工程

官方在技术博客里讲得很直接：生产环境里，真正影响效果的不是“提示词写得多花”，而是上下文管理是否稳定。

他们公开的关键做法有 6 个：

  1. 把 KV-cache 命中率当核心指标 对话前缀尽量稳定，历史尽量 append-only，避免每轮都重排结构。

  2. 工具选择用状态机约束，不靠模型自由发挥 官方提到会用状态机和 logits masking 来约束工具调用，减少“乱选工具”。

  3. 外部记忆尽量落文件系统 不是把所有记忆硬塞进上下文，而是把可恢复信息写入文件，必要时再读回。

  4. 长任务里持续“复述目标” 他们会维护类似 todo.md 的任务锚点，降低“做到一半忘了初衷”的概率。

  5. 保留失败轨迹，帮助模型自修正 不是把错误记录清掉，而是把失败也作为下一步推理输入。

  6. 上下文压缩要可逆 压缩时保留 URL、文件路径、参数等可回溯线索，避免“压缩完找不回原始证据”。

这套方法听起来朴素，但很工程化，也更接近生产真实需求。

五、Wide Research：多 Agent 并行怎么做

Manus 的 Wide Research（广度研究）是它很有辨识度的能力。

公开口径是：

  1. 主控 Agent 先把大任务拆成子任务。
  2. 每个子任务交给一个“完整 Manus 实例”并行执行。
  3. 子 Agent 之间不直接沟通，通过主控汇总。

这个设计的好处：

  1. 减少互相污染上下文。
  2. 提高并行吞吐。
  3. 在复杂调研任务上更容易控制质量。

它的代价也明显：

  1. 资源成本更高（并行实例）。
  2. 汇总层的质量要求高（主控总结不好会“白并行”）。

六、执行层：为什么它“像在真正干活”

1) Sandbox（云端沙箱）

官方给的是“任务级隔离环境”。每个任务可并行运行，并支持 sleep/awake。

公开的生命周期信息：

  1. Free 计划：不活跃 7 天后回收。
  2. 付费计划：不活跃 21 天后回收。

这意味着它不是一次性脚本容器，更接近“短期驻留的工作空间”。

2) Cloud Browser（云浏览器）

Cloud Browser 允许 Agent 在云端网页操作。

关键点：

  1. 支持登录网站。
  2. 遇到验证码、2FA 可用 Take Over 人工接管。
  3. 使用数据中心 IP，部分站点可能额外触发风控。

3) Browser Operator（本地浏览器操作器）

这是很实用的一层：

  1. 用你的本地浏览器会话执行动作（不是云端会话）。
  2. 你可以逐次授权每一步操作。
  3. 全过程可中断、可审计。

简单说：Cloud Browser 偏“远程自动化”，Browser Operator 偏“本地受控执行”。

七、集成层：Skills、MCP、数据源

1) Skills

Skills 本质是“可复用任务包”（SKILL.md + scripts + resources）。

官方强调的机制是“按需加载（progressive disclosure）”：

  1. 先读元数据。
  2. 必要时再读详细指令。
  3. 只在需要时才加载脚本和资源。

这能减轻上下文负担，也方便组织内部复用最佳实践。

2) MCP Connectors

官方提供了 OAuth 连接器（如 Gmail、Notion、Google Calendar、Google Drive、GitHub、HubSpot、Stripe 等）。

企业协作场景里，管理员可以配置连接器可见范围（组织级策略）。

3) Custom MCP Server

如果官方连接器不够，可以接自建 MCP 服务。

文档重点强调了几件事：

  1. HTTPS 端点。
  2. 鉴权（API key / Bearer）。
  3. RBAC、最小权限、审计日志。
  4. 限流与异常处理。

4) Data Sources

Data Sources 是 Manus 内置的数据源能力。

优点：

  1. 不需要你自己管理一堆第三方 API Key。
  2. 可以直接从任务里调用。

边界：

  1. 结果会受第三方供应商限额和延迟影响。
  2. 实时性受缓存策略影响。

八、开发者 API：你可以怎么编排

Manus 开放了 REST API，核心能力是：

  1. 创建任务（可指定 agentProfile、taskMode、connectors、projectId、interactiveMode 等）。
  2. 查询任务状态（pending/running/completed/failed）。
  3. 文件上传（预签名 URL 两阶段）。
  4. Webhook 推送任务事件（如 task_created/task_progress/task_stopped）。

对工程团队来说，这意味着 Manus 不只是“网页产品”，也可以作为你系统里的一个“外部执行引擎”。

九、安全和治理：公开信息里能确认什么

从公开文档可确认的安全点：

  1. Webhook 支持签名校验（含签名与时间戳头）。
  2. Browser Operator 强调逐次授权和可控中断。
  3. Custom MCP 文档明确建议企业做最小权限、密钥管理、审计与限流。

但你在企业落地时仍要自己验证：

  1. 数据驻留与跨境路径。
  2. 连接器权限回收流程。
  3. 沙箱镜像与依赖安全基线。
  4. 审计日志是否满足内控要求。

十、哪些地方还不透明（很重要）

就公开资料看，下面几块仍有信息空白：

  1. manus-1.6 / 1.6-lite / 1.6-max 对应的底座模型细节不完整。
  2. 沙箱底层资源规格（CPU/RAM/GPU 配额）公开粒度有限。
  3. 官方 benchmark 的复现实验细节还不够完整。

所以一个稳妥判断是：

Manus 在“系统工程和产品整合”上透明度较高，在“底层模型映射和性能明细”上透明度一般。

十一、适合谁，不适合谁

适合

  1. 需要“任务交付”而不只是聊天的团队。
  2. 想快速接入浏览器操作、连接器和多 Agent 编排的团队。
  3. 需要 API 化接入业务系统的团队。

不太适合

  1. 强监管场景且要求完整底层可解释（含模型和算力细节）的团队。
  2. 必须完全自控所有执行节点的团队（可能更偏自建）。

十二、如果你想自建一个“Manus 风格”最小版本

建议按这个顺序做，成功率最高：

  1. 先做 单 Agent + 稳定上下文工程（别一开始就多 Agent）。
  2. 再加 可恢复外部记忆（文件系统或对象存储）。
  3. 接着做 浏览器执行层（云端或本地二选一先跑通）。
  4. 最后再做 并行子 Agent + 汇总治理层。

很多团队失败不是模型不够强，而是“执行层和治理层没搭好”。

总结

截至 2026年2月24日，Manus 的公开技术路线可以概括为：

  1. 用上下文工程保证长任务稳定。
  2. 用并行多 Agent 扩展复杂任务吞吐。
  3. 用沙箱、浏览器和连接器把“会说”变成“会做”。

如果只看模型参数，可能看不出它的价值； 如果从系统工程看，它已经是一个比较完整的 Agent 平台形态。

参考资料（官方优先）

  1. Context Engineering for AI Agents: Lessons from Building Manus
    https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus
  2. Introducing Wide Research
    https://manus.im/blog/introducing-wide-research
  3. How Manus Wide Research solves the long context problem
    https://manus.im/blog/manus-wide-research-solve-context-problem
  4. Manus Sandbox（官方博客）
    https://manus.im/blog/manus-sandbox
  5. Browser Operator（官方博客）
    https://manus.im/blog/manus-browser-operator
  6. Skills（官方博客）
    https://manus.im/blog/manus-skills
  7. Wide Research（官方文档）
    https://manus.im/docs/features/wide-research
  8. Cloud Browser（官方文档）
    https://manus.im/docs/features/cloud-browser
  9. Browser Operator（官方文档）
    https://manus.im/docs/features/browser-operator
  10. Skills（官方文档）
    https://manus.im/docs/features/skills
  11. Collaboration / Connectors（官方文档）
    https://manus.im/docs/features/collab
  12. MCP Connectors（官方文档）
    https://manus.im/docs/integrations/mcp-connectors
  13. Custom MCP（官方文档）
    https://manus.im/docs/integrations/custom-mcp
  14. Data Sources（官方文档）
    https://manus.im/docs/integrations/data-sources
  15. Manus API Docs（总览）
    https://open.manus.ai/docs
  16. Create Task API
    https://open.manus.ai/docs/api-reference/create-task
  17. Get Task API
    https://open.manus.ai/docs/api-reference/get-task
  18. Create File API
    https://open.manus.ai/docs/api-reference/create-file
  19. Webhooks API
    https://open.manus.ai/docs/webhooks
  20. Webhook Security
    https://open.manus.ai/docs/security
  21. MCP Official Specification
    https://modelcontextprotocol.io/specification