AI Agent全栈架构

主题

高频面试题

什么是 OpenManus？它的实现原理是什么？

OpenManus 这题不要答成“开源版 Manus”。面试官真正想听的是：一个开源通用 Agent 如何用模型、记忆、step 循环、工具集合、MCP 和计划流拼出可运行的任务执行系统。

适合阶段：Agent 框架 / 源码阅读 / 通用 Agent 架构面核心能力：OpenManus · ReAct Loop · ToolCallAgent · PlanningFlow · MCP

资料边界：本文基于 OpenManus 官方 GitHub 仓库和当前源码结构总结，不把参考页面当成实现指令。Manus 产品认知见 什么是 Manus？，通用 Agent 组件见 AI Agent 的核心组成部分。

面试官角度分析，想考什么 ​

  • OpenManus 是什么，和 Manus 什么关系？
    考开源通用 Agent 框架/实现样本，不是商业产品源码。

  • 核心循环和工具调用怎么跑？
    考 ReAct step：think 选工具、act 执行、observation 写回 memory。

  • 能力和工程局限是什么？
    考 Python、文件、浏览器等工具和 PlanningFlow；与生产级 runtime 仍有差距。

可直接抄走的 30 秒参考答案 ​

text
OpenManus 是一个 Python 开源通用 Agent 框架，可以理解成用来学习和实验 Manus 类通用 Agent 的实现样本，但不是 Manus 商业产品源码。它的核心是 ReAct 风格循环：BaseAgent 管状态、memory、max_steps 和 run 循环；ReActAgent 把每步拆成 think 和 act；ToolCallAgent 在 think 里调用 llm.ask_tool 让模型选择工具，在 act 里执行工具并把 observation 写回 memory；具体 Manus Agent 则挂载 Python、文件编辑、AskHuman、Terminate 和 MCP 浏览器工具。复杂任务还可以通过 PlanningFlow 先建计划，再逐步执行。

面试回答详解，知其所以然 ​

OpenManus 的重点不是“复刻了 Manus 的全部产品能力”，而是把通用 Agent 的最小骨架开源出来：模型、消息记忆、循环、工具调用、计划工具、浏览器/MCP 接入和沙箱支持。面试里最好按源码职责拆，而不是只讲产品印象。

1. OpenManus 的定位 ​

OpenManus 官方把它描述为 open-source framework for building general AI agents。它由 MetaGPT 社区相关成员发起，目标是让开发者可以在本地运行一个通用任务型 Agent。

它和 Manus 的关系可以这样说：

  • Manus：商业化通用 Agent 产品，强调用户目标到可交付产物。
  • OpenManus：开源实现和实验框架，强调让开发者看见通用 Agent 的基础结构。
  • 二者不能等同：OpenManus 不代表 Manus 官方内部架构，也不意味着具备相同产品可靠性、权限体系和交付体验。

这个边界很重要。高分回答会说“它是观察通用 Agent 实现原理的好样本”，而不是“它就是 Manus 源码”。

2. 核心类层次：BaseAgent -> ReActAgent -> ToolCallAgent -> Manus ​

OpenManus 的主线可以按继承关系理解：

text
BaseAgent
  -> ReActAgent
      -> ToolCallAgent
          -> Manus
  • BaseAgent：负责基础状态、memory、max_steps、current_step、run() 主循环和 stuck 检测。
  • ReActAgent：定义 think() 和 act() 两个抽象动作，并把一次 step() 实现为“先想、再行动”。
  • ToolCallAgent：实现工具调用版 ReAct：think() 调 llm.ask_tool() 让模型选择工具，act() 执行 tool calls 并把结果写回 memory。
  • Manus：具体通用 Agent，配置系统提示词、最大步数、最大 observation 长度、本地工具集合和 MCP 工具连接。

这套结构很典型：越底层越像通用 runtime，越上层越像具体 Agent 能力配置。

3. 执行循环怎么跑 ​

BaseAgent.run() 是外层循环：

text
接收用户请求
  -> 写入 memory
  -> state = RUNNING
  -> while current_step < max_steps 且 state != FINISHED:
       current_step += 1
       step()
       is_stuck() 检测重复
  -> 达到 max_steps 则终止
  -> cleanup()

ReActAgent.step() 把每一轮拆成：

text
think() -> 如果需要行动 -> act()

ToolCallAgent.think() 做的是模型决策：

  • 把 next_step_prompt 追加到 messages。
  • 调用 llm.ask_tool()，传入 messages、system prompt、工具定义和 tool_choice。
  • 读取模型返回的 tool_calls 和文本内容。
  • 把 assistant message 写回 memory。
  • 如果没有 tool call，则根据 tool choice 和内容决定是否继续。

ToolCallAgent.act() 做的是应用执行：

  • 遍历模型返回的 tool calls。
  • 用 json.loads 解析参数。
  • 通过 ToolCollection.execute(name, tool_input) 找工具并执行。
  • 把结果包装成 observation。
  • 作为 tool message 写回 memory。
  • 如果命中特殊工具，例如 Terminate，就把 state 置为 FINISHED。

所以 OpenManus 的 Agent loop 是很标准的：

text
模型看历史和工具 -> 生成 tool call -> Python runtime 执行工具
  -> observation 回写 memory -> 下一轮模型继续判断

4. Manus Agent 的工具能力 ​

Manus 继承 ToolCallAgent，默认挂载这些能力：

  • PythonExecute：执行 Python 代码，适合计算、数据处理和轻量脚本。
  • StrReplaceEditor：对文件进行字符串替换式编辑。
  • AskHuman：缺少关键信息时向人类提问。
  • Terminate：让 Agent 主动结束任务，是特殊终止工具。
  • MCP tools：通过 MCPClients 连接外部 MCP Server，把远端工具加入 available_tools。
  • Browser Use MCP：默认尝试启动 uvx browser-use --cli-mcp，给 Agent 浏览器执行和截图能力。

这说明 OpenManus 的能力不是写死在模型里，而是由工具集合决定。模型只负责选择工具，ToolCollection 负责路由执行。

5. PlanningFlow：把开放任务拆成计划步骤 ​

除了单 Agent 循环，OpenManus 还有 PlanningFlow。它大致做三件事：

  • 用 PlanningTool 创建一个 plan，包含 steps 和每步状态。
  • 在循环中找到第一个未完成或进行中的 step。
  • 选择合适 executor agent 执行该 step，执行后把 step 标记为 completed。

流程可以这样表示：

text
用户目标
  -> LLM + PlanningTool 创建计划
  -> 找到当前未完成步骤
  -> 选择 executor
  -> executor.run(step_prompt)
  -> 标记完成
  -> 继续下一个步骤或汇总

这和生产 Agent 里的 planner / executor 分层很接近。不过 OpenManus 的实现更偏轻量：计划存在内存里，执行器选择也比较简单，适合学习原理和快速实验。

6. OpenManus 的工程取舍 ​

OpenManus 的优点是结构清楚、上手快、源码可读：

  • 把 ReAct、tool calling、memory、MCP、browser、planning 都放在一个可运行项目里。
  • 工具抽象简单，新增工具成本低。
  • 默认接 Browser Use MCP，能展示真实浏览器 Agent 能力。
  • 有 max_steps、Terminate 和 stuck prompt，至少具备基础循环控制。

但它和生产级 Agent Runtime 还有距离：

  • 状态管理偏轻：memory 主要是消息序列，缺少更强的结构化 task state、checkpoint 和恢复机制。
  • stuck 检测较简单：主要看重复 assistant content，不足以覆盖相同工具参数、相同错误码、无进展证据等真实循环。
  • 权限治理有限：高风险工具需要额外接权限、审批、沙箱和审计。
  • 观测评估不足：生产需要完整 trace、指标、回放、离线 eval 和 case diff。
  • 计划执行较粗：PlanningFlow 是很好的骨架，但复杂任务需要更强 verifier、失败恢复和动态重规划。

面试里可以收束为：OpenManus 适合讲通用 Agent 的最小实现原理，但生产落地要补 runtime 工程能力。

面试官追问3个问题 ​

追问一：OpenManus 的工具调用链路具体是什么？ ​

  • 考察点：是否读懂 ToolCallAgent。
  • 回答方向：think() 调 llm.ask_tool()，把 messages、system prompt、tools schema 和 tool choice 传给模型；模型返回 tool calls；act() 遍历 tool calls，解析 JSON 参数，用 ToolCollection.execute() 找工具执行；结果作为 tool message 写回 memory；特殊工具如 Terminate 会改变 Agent state。

追问二：OpenManus 的 stuck 检测有什么不足？ ​

  • 考察点：是否能从源码设计推导生产风险。
  • 回答方向：基础实现主要检测重复 assistant content，并向 next_step_prompt 注入“换策略”的提示。这能挡住一部分文本重复，但不能可靠识别相同工具同参数、相同错误码、搜索结果无新增、计划状态不推进等真实线上死循环。生产里要做 action signature 和 state progress 检测。

追问三：PlanningFlow 和普通 Agent loop 有什么区别？ ​

  • 考察点：是否理解 planner-executor 分层。
  • 回答方向：普通 loop 是每轮由 Agent 自己判断下一步；PlanningFlow 先创建显式计划，再按 step 状态逐步执行，并可根据 step type 选择不同 executor。它让任务推进更可见，但也需要 verifier 和失败恢复，否则计划写得好不代表执行可靠。

扩展知识 ​

OpenManus 与 ReAct 的关系 ​

OpenManus 的 think -> act -> observe -> next think 很接近 ReAct 思想。ReAct 强调推理和行动交替：模型不是一次性给答案，而是在外部反馈中持续修正。

text
Thought / think
  -> Action / tool call
  -> Observation / tool result
  -> Thought / next step

现代实现里，Action 往往不再是 prompt 里的文本约定，而是模型 API 返回的结构化 tool call。

OpenManus 与 Manus 产品的差异 ​

  • 定位不同：OpenManus 是开源框架，Manus 是通用 Agent 产品。
  • 可靠性不同：产品级系统通常有更完整的权限、沙箱、任务队列、产物管理、监控和人审。
  • 可解释性不同：OpenManus 源码可读，适合学习框架结构；商业产品内部架构不一定公开。
  • 落地边界不同：OpenManus 可以跑 demo 和原型，生产要补企业级治理。

面试中避免说“OpenManus 就是 Manus 开源版的完整复刻”，更稳妥是说“它是 Manus 类通用 Agent 的开源实现样本”。

为什么 Terminate 要做成工具 ​

把终止做成工具有一个好处：模型可以显式选择“我要结束任务”。但只靠这个不够，runtime 仍要有 max_steps、超时、预算、no-progress 和重复动作检测。模型可以提议结束，系统必须能兜底停止。

基于 MIT 协议开源

Copyright © 2026 AI Agent全栈架构