推理模型能力提升后，Agent领域迎来了一个刷屏周。这话怎么说？3月2日，锦秋基金被投企业Pokee AI发布了最新通用Agent的演示Demo，引发外网讨论；3月5日晚，Manus展示Demo，全网刷屏；3月7日，国内DeepWisdom MetaGPT团队和CAMEL AI团队分别推出开源项目OpenManus和OWL，复刻Manus，继续在网络及Github社区引发广泛讨论。

这其中，基于MetaGPT的长期技术积累，OpenManus团队仅用1小时就完成了核心系统，整体3小时火速上线，在Github上轻松收获过万星，引发广泛关注。

随后，锦秋基金邀请到了OpenManus核心作者团队——洪思睿、梁新兵、向劲宇三位专家，来一场闭门分享，深入拆解OpenManus的技术实现，并前瞻Agent技术的未来趋势。

先快速了解一下分享嘉宾的背景。洪思睿是MetaGPT论文（ICLR 2024 Oral）与数据解释器（Data Interpreter）论文一作，也是AFLOW论文（ICLR 2025 Oral）作者之一，多篇研究成果已发表在国际顶级会议。梁新兵和向劲宇则是OpenManus的核心作者与合作者，向劲宇还是AFlow和SPO的一作。

在本次分享中，几位嘉宾给出了一些非常关键的趋势判断，值得反复琢磨：

• 随着大模型能力提升，许多问题的解决成功率显著提高，特别是在QA、HumanEval这类单函数代码生成问题上，单模型已经能直接解决得很好。

• 但人类社会的问题远不止于此。机器学习、代码修复，以及需要多信息搜索整合的复杂任务，仍需要大量技术工作，尤其是如何有效应对幻觉问题。

• Agent在规划能力上的进步，既依赖模型本身能力的提升，也离不开外部结构化框架的辅助。

• 当Agent可调用的工具越来越多，其中不乏功能相似的工具时，如何做出最准确的决策、选择最合适的工具，并避免决策错误，是一个核心挑战。

• Agent的Memory管理，本质上是在解决成本和效率的博弈问题。直接使用完整memory虽然可行，但会显著增加处理时间和成本，严重影响用户体验。

• 目前解决Memory问题的一个有效方法是采用多智能体或工具辅助。在OpenManus这类框架中，通常先通过规划工具生成规划，每个任务间的memory不完全共享，任务执行完毕后进行总结或压缩处理。

• 尽管在标准测试中能判断任务是否正确完成，但在真实场景中，很难量化评估一个任务完成的好坏程度——这有点像考核一个实习生和资深员工，很难给出一个绝对客观的分数。

• Agent商业化的核心比拼点，在于能否将真实场景中的任务和效果（包括个性化功能）做到极致，用户才会愿意持续使用。

• 大量应用厂商都在优化Token消耗，无论是通过工程缓存还是memory压缩技术，核心目标是尽量减少每次调用的上下文长度。

• 未来一个很可能的趋势是：集成多个小模型的能力，实现完整甚至超越大模型的效果，在推理速度、token消耗和成本上形成明显的优势。

以下是对本次分享内容的更详细整理。

Github一天过万星，OpenManus开发揭秘

梁新兵：3月6日下午5点多，组会后劲宇提议，按照几个技术步骤，或许能达到Manus的效果。我第一次看Manus演示视频时，从交互过程判断，下意识以为它是一个单智能体系统。当时非常震惊——一个单智能体怎么能达到这么好的效果？它是怎么规划、怎么做到的？晚饭时聊起Manus的技术方案，从用户示例看，它展示了卓越的体验，但技术方案上，它大量使用了业内共识的核心基础技术。最终我判断，它是借助一个外部规划来协调多智能体。晚饭后，OpenManus的开发就开始了。整体花了大约三个小时。当时完全没想过它会爆火。

拆解Manus的多智能体实现：Manus是一个多智能体系统，核心流程是：先使用PlanningTool做规划，形成一个包含多个任务的线性结构计划，然后顺序执行每一个任务，并动态分配给相应的Agent。Agent在执行每个任务的过程中，以ReAct循环的形式调用工具完成目标。它具备规划能力和工具使用能力。一个关键点在于，Manus将PlanningTool规划工具引入多智能体框架。举个例子，Claude-3.7在SWEBench上的解决率从49%提升到了70%，一部分提升源于模型本身，另一部分就来自于规划。我们之前的工作Data Interpreter也充分证明了规划在处理现实问题中的重要性。因此，我们不仅会在多智能体系统上加入规划能力，也会在单智能体上尝试加入。我们猜测Manus使用了Claude的模型和一些自训练的模型，并在工程上做了大量优化，这显著增强了它在不同场景下的工具使用能力。

OpenManus的设计思路：当时的设计思路很清晰：一个极简的Agent框架，应该是可插拔的Tools和Prompt的组合。沿着这个思路，我们写了一个完整的Agent迷你框架。决定一个ReAct Agent效果的关键，就是提示词引导和工具使用。在OpenManus中，Prompt控制Agent的整体行为逻辑，Tools定义Agent的行动空间，二者定义了，就能完整诠释一个ReAct Agent。在React Agent的基础上，我们基于Function Call实现了一个轻量的ToolCall Agent，它能以更格式化的方式选择和执行工具。OpenManus正是基于ToolCall Agent构建的。可插拔的好处在于可组合。我们可以把几个不同场景下的Tools组合起来创造一个新的Agent，定义也很方便，只需修改动作空间（Tools），无需单独写内部逻辑。Tools本身就该是可组合的，我们的工作是把抽象做得更干净。它提供了丰富的工具集合，支持多种Agent通过装备不同工具集，灵活扩展在不同场景下的能力。规划能力的重要性不言而喻。OpenManus继承了Manus的规划优势，通过PlanningTool实现任务分解，从而处理现实世界中的复杂问题。

OpenManus工作流程：首先，OpenManus收到用户需求后，会使用PlanningTool形成一个包含多个任务的线性结构计划，并写入一个plan的markdown文件中。接着，它查看这个Plan，从中依次取出每个任务。执行任务时，会将任务分配给最适合的Agent——这些Agents装备了不同的工具集，在处理不同任务时各有优势。需要说明的是，Agent的分配是临时进行的，这使得系统更加灵活，能够根据任务的具体需求和上下文选择最合适的Agent。目前我们使用正则匹配进行任务分配，如果匹配不上，则使用默认配置的Agent执行任务。未来，我们也会考虑让LLM直接将任务分配给某个Agent。但每次执行任务都使用LLM识别意图并分配Agent，会增加计算成本和延迟。

OpenManus后续工作：接下来我们会从以下几个方向提升OpenManus的效果：增强Planning能力；引入标准化评测，采用GAIA/TAU-Bench/SWE-Bench作为基准持续评估；拓展模型适配，从Claude-3-5扩展到DeepSeek V2.5，优化低成本场景；实现容器化部署，简化安装流程；丰富示例库，增加更多实用案例，包含成功和失败的分析；前后端开发，提供UI界面提高用户体验；集成RAG模块，提供外部知识库以增强效果。Manus的产品交互做得很好，有很多技术值得学习。目前OpenManus效果还很有限，我们还没单独调效果。前期目标是与原始Manus达到相同效果，后续依靠庞大的开源社区不断优化Computer Use、Browser Use和Planning Use，以及工具调用的能力，从而带来更高的智能涌现。

3小时复刻Manus，MetaGPT的多年技术积累

洪思睿：事实上，我们整个团队在AI场景的自动化和智能体框架上已经有多年的技术积累。过去两年多，我们持续将团队工作开源并形成学术论文和技术报告，贡献给社区。主要工作包括：MetaGPT、Data Interpreter、AFlow、FACT、SELA、SPO、AOT等。

MetaGPT框架：2023年我们就开源了MetaGPT框架，这是一个多智能体的元编程框架，沉淀了多智能体协作的核心思想。我们始终认为，虽然当时大模型能力已在通用任务上达到一定水平，但要有效解决人类社会复杂问题，需要将问题原子化拆解，并集成更符合人类社会解决问题的流程。大家可能熟悉SOP（标准操作流程）这个概念。通过将SOP分配给不同角色，利用各角色的背景知识和工具能力，能显著提升大模型在复杂问题上的表现效果。因此，我们提出了嵌入SOP的多智能体框架，希望实现智能体的元编程能力。这种方法在HumanEval和MBPP等基准测试上取得了显著效果，相比当时的GPT-4模型有很大提升。我们在许多典型的软件开发应用（如2048小游戏和贪吃蛇）上验证了这一思路，与同期的其他开源框架相比，整体成功率明显更高。

Data Interpreter：在MetaGPT框架和智能体设计基础上，我们意识到智能体还需要更强的规划能力和工具使用能力，尤其是在解决机器学习或数据建模问题时。一方面，机器学习/数据建模流程通常可以结合大模型能力规划出完整流程，大模型可以更关注任务的执行和实现。另一方面，处理大型表格数据时，由于大模型上下文限制，无法直接输入全部数据，我们需要智能体通过代码形式与数据交互。所以从2023年下半年开始，我们探索规划能力和工具使用能力，沉淀出“数据解释器”（Data Interpreter）这一工作。在Devin等项目出圈的那段时间，我们发现Data Interpreter在数据建模/机器学习等任务上已经达到了初级数据分析师的水平。只需将数据交给它，它就能完成从数据处理到NLP/CV模型训练等复杂AI任务。

SELA：在Data Interpreter的基础上，为了进一步提高效果，我们认为需要增强智能体的调试能力和对实验结果的反馈机制。我们开发了SELA工作：在Data Interpreter基础上增加了蒙特卡洛搜索方法，使智能体通过自主实验的方式进行机器学习任务的自动优化，在推理过程中进行多样性探索，并根据执行结果反馈调整策略和求解步骤，从而进一步提升整体任务表现。通过这种方式，我们显著提升了Agent在机器学习任务上的能力，达到了与AutoML工具相当的水平。

AFlow：同期，我们还基于蒙特卡洛树搜索（MCTS）在大模型推理能力提升上进行了探索，研发了AFlow工作。不同于固定SOP的方案，AFlow可以为不同任务自动搜索合适的解决流程。AFlow的创新点在于：如何在不同问题上提升解决效果？我们希望系统能根据问题反馈，自主探索出最优的智能体组合（拓扑结构），使解决问题的组合更动态，规模也无需预先规定。AFlow通过定义问题原子化的搜索空间，并利用蒙特卡洛方法探索和优化多智能体的组合拓扑结构。这项工作在六个数据集上均取得了SOTA结果，并获得了ICLR 2025的Oral认可。

FACT：我们也注意到，随着智能体解决问题步骤的增加，其Memory体量也会增大。因此我们需要解决智能体在问题求解过程中的上下文管理问题，通过改进检索和上下文压缩来提升能力。我们提出了FACT工作，通过多针查找机制提升大模型在事实查找上的准确率，在QA问题上展现了显著效果，并被NAACL录用。

此外，去年9月份左右，我们在SWE-Bench上进行了能力探索。我们发现大模型在代码修复等问题上，需要依赖文件定位、查找以及Computer Use能力，同时对工具使用和规划能力提出较高要求。许多工作采用多智能体方式来解决这类长链复杂推理过程。因此我们在这个Benchmark任务中加入了文件定位、文件查找等能力，这后来也成为了OpenManus代码的基础。如果查看OpenManus的代码，会发现其中不少工具与代码修复和定位相关。

SPO：SPO是一套提示词优化工具。与传统需要大量数据集的优化方法不同，SPO适用于没有准确评分或数据集有限的场景。例如写小红书文案或SEO优化时，可能只有几个满意样例。SPO能在这种有限样例条件下进行提示词优化。该工具已经开源，在国内魔搭平台和Hugging Face上均有良好反馈。

AOT：AOT（原子思维）则用于问答类信息推理和整合任务，如从不同段落整合信息进行阅读理解。这项工作已有35万浏览量，后续会整合到MetaGPT框架中。

十个基础问题，还原Agent的现实难题

Q1：大模型能力提升后，能否完全解决复杂问题？
洪思睿：随着大模型能力提升，许多问题的解决成功率会提高，但问题本身并不会消失。例如前面提到的QA、HumanEval和MBPP这类单函数代码生成问题，现在单模型已经能解决得很好。从去年到今年，大模型在这类问题上的成功率已接近实用水平。但人类社会有很多非常复杂和长尾的问题，包括我们正在解决的机器学习、代码修复，以及通过搜索组合结果提供给用户的问题，这些仍需要大量技术工作，特别是解决幻觉问题。

Q2：大模型能力提升与Agent提升的关系是什么？
向劲宇：Agent与大模型可能是垂直或正交的关系。框架本身的提升会因为模型能力的提升而带来更多功能，两者并不冲突。框架扩展了更多工具，让大模型可以与物理世界或更多环境交互。同时，大模型自身的提升会增强其推理和规划能力。两者可以组合使用，也可以分离开来，这是一种互补而非冲突的关系。

Q3：Foundation Agent Model目前能达到什么水平？
向劲宇：最近看过一些相关的工作，不过可能不完全是Foundation Agent Model。我观察到Pan Jiayi团队做了一个尝试，他们在SWE-GYM项目上解决代码库修复问题。他们使用基于Claude或GPT-4o等模型运行后产生的数据，再借助Openhands等框架采集Agent运行过程中的轨迹数据，既包括成功案例，也包括失败案例。然后将轨迹数据重新用于训练Qwen的开源模型，观察到模型在这种训练后能力有所提升。他们在论文中详细描述了这一过程，研究内容比较扎实。这类工作的泛化难点在于，在SWE-Bench中我们能明确判断任务是否正确完成，但在实际场景中，很多情况下很难量化评估任务完成的好坏程度。就像现实工作里考核一个实习生和一个资深员工，很难给出一个客观分数，需要基于很多主观的业务逻辑和标准来判定。这种开放任务下的评估反馈自动设计，也是我们未来探索的一个重要方向。

Q4：Agent在规划上的进步是否主要依赖于大模型本身？
向劲宇：目前规划方面的进步，一方面取决于模型本身能力的提升，另一方面也依靠外部结构的辅助，即在Agent层面加入更复杂的结构进行辅助规划。最早的工作之一是"Tree of Thought"（TOT），它通过引入额外结构，使模型在任务推理过程中取得了显著增强。规划领域也有类似的外部结构辅助相关工作在进行。

Q5：Agent使用外部工具的难点是什么？
梁新兵：目前OpenManus主要使用一些现有开源工具，比如Cloud Computer和Browser。有其他团队开展的Browser使用相关工作表明，仅凭这两个工具就能完成许多任务，已经初步形成Manus的雏形。另外，如果Agent想使用某个工具但目前没有，我们也设想未来可以赋予Agent创建工具的能力。当Agent需要工具去完成任务但环境中没有合适的工具时，它可以自行创建并使用，这将进一步增强Agent的能力。

洪思睿：说到底，大模型和Agent使用工具本身并不新奇。但随着工具数量逐步增加，技术难点也随之而来：如果有众多相似工具，Agent在解决同一任务时如何做出准确决策，选择最合适的工具，并避免决策错误。此外，如果不是使用标准化的工具接口，而是自行定义工具，还可能面临工具参数定义不合理或不明确的问题，导致大模型在生成调用工具决策时容易出错，工具执行效果因此受影响。另一个难点不仅仅是工具的选择和使用本身，而是上下文中可能包含很多细节信息。例如用户同时打开不同网页时，这些网页上的信息（比如某个简历的时间、另一个网页提及的某个事件的起始时间），Agent在整合生成最终结果时可能会造成混淆或错误。如何保证Agent在使用工具时准确处理这些细节信息，是实际应用中需要重点解决的问题。

Q6：MCP等协议在工具使用方面会成为主流吗？
梁新兵：MCP协议目前正在逐渐成为主流。工具使用的能力，这实际上取决于模型本身是否具备良好的工具使用能力。有些模型可能并不具备工具使用能力，或者这方面能力较弱，使用工具时效果就会受限制。因此，工具协议的普及与模型自身具备较强的工具使用能力密切关联。

Q7：Agent在处理海量上下文（Memory管理）时有哪些进展和难点？
洪思睿：大家可能了解一些已有工作，如MemoryGPT或开源项目Mem0，它们对较长上下文和Agent的记忆管理做了一些优化。例如MemoryGPT对上下文进行总结，这是一种朴素但有效的思想。Mem0则在memory更新过程中主动使用工具，涉及memory删除、更新和新增等操作。目前Agent在处理复杂、长程任务（例如浏览网页时，信息可能非常长）时，如何压缩上下文并存储到记忆中，是一个非常具有挑战性的问题，并且要确保压缩后关键信息不被修改或遗漏。早期一些研究工作指出，memory会随着时间或任务步骤的增加而消退。另一方面，人的memory存在多种类型，不仅仅是语义信息的记忆，还包括工具使用时产生的程序性记忆以及事件关联关系的记忆。学术界也针对不同的记忆类型分别进行优化。以上是单个Agent的memory管理情况。在多智能体系统中，我们可以更巧妙地利用memory。除了一定程度的隔离，人们还希望复用其他Agent在解决问题过程中产生的memory，以增强自己处理特定任务的经验。此外，Agent可以进化，复用群体的解决问题经验，最终形成群体智能。

梁新兵：memory管理主要涉及成本问题。如果我们不考虑memory，不做压缩和处理，直接使用完整的memory，目前的大模型仍然可以处理，但这样带来的问题并非质量下降，而是会显著增加处理时间和成本，严重影响用户体验。因此这涉及工程层面的优化，目前已有一些公司或组织在尝试优化memory。当前解决memory问题的一个方法是采用多智能体或工具辅助的方式，例如在OpenManus等框架中，通常通过规划工具先生成规划，每个规划包含多个任务，每个任务间的memory不完全共享，每个任务执行完毕后进行总结或压缩处理。

Q8：Agent在商业化落地上最终会拼什么？
洪思睿：最重要的是将真实场景中的任务和效果，包括个性化功能，做到极致。目前学术界的许多工作，无论是针对SWEBench、GAIA还是其他Agent测试任务，任务成功率依然有限。如果这种相对微小的任务标准对应到真实商业场景，不同用户面对不同难度的问题，目前Agent的成功率还相当受限。无论是编程任务，还是数据收集和报告生成任务，如果能够针对各种各样的用户问题和场景做到极致，将成功率提升到令人满意的程度，真正实现Agent当前人们所期望的行动能力，我相信用户会持续使用Agent，将其作为日常助手和工具。

Q9：当前Manus、OpenManus等Agent成本较高，如何进一步降本增效？
洪思睿：首先，大量应用厂商（包括我们自己在内）都会对token消耗进行优化，无论是在工程上通过缓存还是memory压缩技术，尽量减少每次调用的上下文长度，这是在应用层面持续优化的方向。此外，未来大家很可能会部署大量小模型，基于已有数据进行微调或强化，专注于优化某些节点或工具使用的能力。通过集成多个小模型的能力，实现完整甚至超过大模型的效果。这样可以在推理速度、token消耗和费用上明显降低成本。

Q10：如何评估多智能体的商业前景？
洪思睿：首先我们认为在代码生成领域，无论是单个Agent还是多智能体系统，都可以更早实现商业落地。我们发现大量用户虽然编程水平一般，但懂一些基本概念，想自行搭建个人网站或简单应用程序时，非常需要智能体或大模型辅助解决问题。如果用户直接使用大模型，可能需要多轮交互和烦琐的调试过程。但使用产品化的智能体系统，这个过程就能变得轻松。用户可能只需花费15分钟或半小时，包括后续需求变更，也能快速获得满意的网站或应用。因此我认为，在真正有效解决用户实际需求方面，多智能体的商业前景是明确且强烈的，也是Agent技术目前能较好解决的场景，用户在这方面的付费意愿也较高。

Agent商业化：代码生成加速落地

Q1. 能否简单介绍一下MGX这款多智能体产品？
洪思睿：如果大家熟悉MetaGPT，就会了解MGX是一款多智能体同时在线协作、帮助用户解决问题的产品。用户只需像使用ChatGPT一样输入需求，便会有一个较强的智能体对任务进行拆解，再将任务分发到不同的智能体执行。整个产品目前主要专注于代码生成领域。例如用户想做个人网站、游戏或者数据分析的应用程序等，智能体都能很好地完成任务。在开发过程中用户可以随时修改需求，比如调整前端项目的风格、排版或布局，智能体也能很自然地完成，使整个开发成本明显降低。与Manus和OpenManus等产品不同，我们具备自动部署的能力，即开发过程中软件会自动部署，用户可实时预览和调整效果。此外，产品中每个智能体也具有之前提到的计算机工具调用、浏览器工具调用，以及规划和代码执行的能力。我们内部也对设计或数据可视化效果进行美学评估，可能会形成相应的Benchmark，帮助大模型或Agent学习评估生成的页面或数据仪表盘是否符合用户预期和审美标准。以下是样例：
个人网站：
https://alex-portfolio-yhx5c3-v1.mgx.world/
https://photographer-portfolio-myuf2t-v1.mgx.world
个人博客：
https://personal-blog-v7amdv-v2.mgx.world
https://cute-cartoon-blog-p58801-v1.mgx.world
个人名片：
https://portfolio-dveerm-v1.mgx.world
https://emma-anderson-homepage-8rnqm6-v1.mgx.world

Q2. MGX DEV后续会不会增加新的Agent？
洪思睿：MGX后续会继续增加新的Agent。我们内部目前正在尝试一种叫做User Agent的新型智能体。当用户项目部署后，有可能无法直接运行或出现缺陷，导致页面空白等情况。User Agent会主动检测项目部署效果，例如截取页面截图，主动与网页交互，测试生成软件的可行性和可执行性，随后再通知其他负责开发的智能体进行修复，以便更完善地完成项目。此外，我们内部也可能沉淀针对设计或数据可视化效果进行美学评估的Benchmark，使得Agent能够判断页面或数据仪表盘的质量与审美表现是否符合预期。

（完）