1. OpenManus是干什么的用的

OpenManus 是一个开源的 通用 LLM 智能体框架，目标是做出类似 “Manus” 那种能用工具完成复杂任务的 Agent，但 无需邀请码，并持续迭代。
团队成员 @Xinbin Liang 和 @Jinyu Xiang（核心作者），以及 @Zhaoyang Yu、@Jiayi Zhang 和 @Sirui Hong，来自 @MetaGPT团队。我们在 3 小时内完成了开发并持续迭代中！

2. OpenManus的配置与运行方式

我用的是python 3.12及以上解释器，系统是autodl的ubuntu镜像环境，我按照官方配置中的要求，利用uv配置虚拟环境，发现下载requriements包的时候用pillow~=10.4.0才能顺利安装，同时需要用 pip install daytona 才能正常运行python main.py python sandboxmain.py这样的入口程序。如果你也遇到了这样的问题，握手！

配置需要在config里面建立一个config.yoml文件，我配置了qwen的语言和视觉模型

# Global LLM configuration
[llm] #QWEN:
api_type = 'qwen'
model = "qwen-plus"                                                       # The Qwen LLM model to use
base_url = "https://dashscope.aliyuncs.com/compatible-mode/v1"
api_key = "XXX"                                                  # Your API key
max_tokens = 8192                                                         # Maximum number of tokens in the response
temperature = 0.0                                                         # Controls randomness

# Optional configuration for specific LLM vision models for Qwen
[llm.vision]
api_type = 'qwen'
model = "qwen3-vl-plus"                                                     # The Qwen vision model to use
base_url = "https://dashscope.aliyuncs.com/compatible-mode/v1"  # Qwen vision API endpoint
api_key = "XXXX"                                                  # Your API key for vision model
max_tokens = 8192                                                         # Maximum number of tokens in the response
temperature = 0.0                                                         # Controls randomness for vision model

[daytona]
daytona_api_key = "dtn_c770aa2512ed387d6a354c07d3c52bd1e276893ba37299e4cb3c8d2805144b18"

3. OpenManus的结构解剖

3.1 智能体由抽象到具体，层层继承

抽象智能体

该项目对智能体最抽象，最基础的理解是：任何执行任务的智能体都应该有名称、描述、系统提示词、当前步骤提示词、模型、记忆、状态管理、最大执行步骤、允许重复步骤出现的次数这些属性或者状态。

• 一个虚拟机器人，要对自己的总任务有认知 👉 系统提示词
• 要知道自己接下来想干什么 👉 当前步骤提示词
• 要对对话记录有记录 👉 短期记忆（这个项目暂时没有更新长期记忆，就是一个对话里的）
• 状态管理 👉 无非就是 空闲、执行、错误 三种状态

ReAct智能体 （继承抽象智能体）

该项目用了2026年依旧很火的 推理 加 执行的 智能体设计理念。

项目当中，ReAct智能体是抽象智能体的子类，除了上述的属性，还加上了 思考、执行，以及原子步骤（把思考一次，执行一次作为一个原子步骤），

工具调用智能体

层层递进，工具调用智能体又继承了ReAct智能体，以LLM为中心点，那就是让它一步步有了状态、记忆、规划、工具，智能体的要素齐全了

工具调用智能体继承了上层的抽象方法，引入了最基础的两个工具（创建聊天工具、结束聊天工具），也就是说，该项目是把聊天和结束当作工具来看待的，
此外，工具调用智能体改写了 think 和 act的逻辑
模型会执行 产出 tool_calls + 程序执行工具 + 把结果写回记忆三步走策略

来看具体的智能体

继承来到了第四层，再实现的就是有具体功能的智能体

---

1. BrowserAgent：差异在于它把“当前网页状态（URL/标签/可交互元素/视口上下内容/必要时截图）”强注入到每轮的下一步提示词里，让模型决策紧贴页面变化。

用到的工具是：“自动操作网页”，比如定位元素、点击/输入、滚动、提取页面信息

---

2. Manus：差异在于它是“通用多工具”组合体（本地执行/编辑/人工确认等 + 可选 MCP 工具），并在需要时才补齐浏览器上下文提示，主打跨工具的通用任务能力。
   偏“通用办事”，
   工具组合包含“本地运行代码/脚本”、更改代码/文件内容、“网页自动操作”，必要时可以让人介入确认（问人类问题），另外还可以连接外部的远端工具来扩展能力

---

3. SandboxManus：也是一个通用的应用，但会把执行放到一个隔离的沙箱环境里（更适合跑不确定的代码或需要完整执行环境的任务）。

---

4. SWEAgent：更聚焦“工程/修代码”。主要工具是“在终端里运行命令/脚本”和“编辑文件”，通过循环推进直到完成，然后用“停止/终止”。

---

5. MCPAgent：它自己的能力不固定，核心是“把外部工具服务提供的工具接进来，然后让模型调用这些工具”；工具清单会随外部服务状态变化，最后同样用“停止/终止”。

---

6. DataAnalysis：面向“数据分析与图表”。主要工具是“运行数据处理代码”、准备可视化所需的数据和参数、生成图表/可视化结果；最后用“停止/终止”结束流程。

---

3.2 记忆与会话管理

3.2.1 总体思路：会话跟着 Agent 实例走OpenManus 没有单独的全局会话中心（例如数据库里的统一会话表），而是采用Agent 实例内存会话：

• 每个 Agent实例 内部都有一份消息记忆
  用户输入、助手输出、工具执行结果都会追加到这份列表。
• 只要复用同一个 Agent 实例，这份上下文就会持续累积，形成多轮会话。
• 如果进程退出或重建 Agent，旧会话不会自动恢复（默认不做持久化，只有短期记忆）。

3.2.2 记忆结构：一份消息队列 + 滑动窗口

记忆层本质是按时间顺序增长的消息列表，消息角色通常包括：

• user（用户输入）
• assistant（模型回复，可能带工具调用意图）
• tool（工具执行结果）
• system（系统指令/状态提示）

为了防止无限增长，消息列表有上限（默认 100 条）。超过后会截断最早消息，只保留最近窗口。

3. 单次请求内的编排：从输入到下一轮

一次 run(request) 的典型流程是：

• 先把用户请求写入记忆；
• 进入循环（思考 -> 执行）；
• 生成助手消息（可能包含“要调用哪些工具”）；
• 如果调用工具，逐个执行并把工具结果写回记忆；
• 判断是否结束；未结束则进入下一轮；
• 达到结束条件后收尾并清理资源。

所以消息列表会呈现类似节奏：

user -> assistant -> tool -> assistant -> tool …

在某些智能体中（例如浏览器相关），还会插入“页面状态/截图”这类辅助上下文消息，用于提升下一轮决策质量。

3.2 工具类的设计

3.2.1 怎么决定“调用哪种工具”

1. Agent 每一轮会把当前对话上下文和“可用工具列表（含参数 schema）”一起发给模型。

• 模型返回两类东西之一：
• • 纯文本（不调工具）
• • 或者结构化的工具调用（工具名 + 参数）

2. 另外有一个策略开关会影响是否允许调工具：

• none：不允许工具
• auto：模型自己决定
• required：必须给出工具调用

3.2.2 怎么决定“调用多少种/多少次工具”

分两层看：

单轮内：模型可以返回一个 tool_calls 列表；Agent 会把列表里的调用逐个执行（顺序执行）。
多轮内：只要任务没结束，就会继续下一轮思考，再产生下一批工具调用。

4. 多智能体之间是如何协调的

启动python run_flow.py可以启动多智能体工作流，
在这个项目里，Manus不是抽象概念，它就是一个具体的智能体类，可以把它理解为“默认的全能执行者”。

在生产过程中，可以在工作室内单独部署一个
在这个项目里，多智能体协作最核心是三件事：

• 分工：先把任务拆成步骤，每步尽量匹配更合适的 agent。
• 交接：当前步骤完成后，把“步骤结果 + 计划状态”传给下一步（下一位执行者）。
• 收敛：所有步骤完成后统一总结/结束。
  只要这三件事顺畅，哪怕不是并行协作，也已经是有效的多智能体协同了。

我的疑问：这么多智能体，有没有共同的记忆？
实际上，没有。现实生活中，同事之间交接工作是很正常的，他们很难完全知道对方的新路历程，所以其实各自有各自的记忆，然后有共同的任务记录就可以，就像git分支一样。

OpenManus就是这样的，Flow 层另外维护一份“共享的计划状态”（步骤、进度、备注）所以你看到的“共同记忆”更准确说是共同任务状态，不是共同聊天记录。

当一个任务需要另一个智能体上手，它只需要关心任务进行到哪里，下一步要干什么就可以了！

5. 关于封装使用的思考

把openmanus继续封装，权限，消息队列都安排一下，可以做很好的报表助手，企业内部查询助手等。
这个开源项目提供了MCP接口处，所以关键在于开发适合自己的MCP服务！