随着推理模型能力提升，本周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上收获过万星，也受到行业及大众广泛关注。
3月8日上午，锦秋基金也邀约OpenManus团队的三位核心作者进行分享，还原OpenManus 的技术实现原理、Agent技术的发展趋势。
本次的分享嘉宾中，洪思睿是MetaGPT论文（ICLR 2024 Oral）与数据解释器（Data Interpreter）论文一作，以及AFLOW论文（ICLR 2025 Oral）作者之一，多篇研究成果已发表于TPAMI、ICLR等国际顶级学术会议与期刊。梁新兵，OpenManus的核心作者。向劲宇，OpenManus合作者，也是AFlow和SPO一作。
本次分享中，三位嘉宾也给出了他们对于行业的一些思考：
•随着大模型能力的增加，许多问题的解决成功率会提高，在QA、HumanEval和MBPP这类单函数代码生成的问题上，单模型已经能直接解决得非常好。
•人类社会有很多非常复杂和长尾的问题，如机器学习、代码修复，以及通过搜索组合结果提供给用户的问题，这些仍需要大量技术工作来提升大模型的效果，包括解决幻觉问题。
•在Agent规划方面的进步，一方面取决于模型本身能力的提升，另一方面也依靠外部结构的辅助。
•随着Agent可以工具的数量逐步增加，如果有众多相似工具，Agent 在解决同一任务时如何做出准确决策，选择最合适的工具，并避免决策错误。
•Agent 的memory 管理主要涉及成本和效率问题。如果直接使用完整的 memory，目前的大模型仍然可以处理，但这样带来的问题并非质量下降，而是会显著增加处理时间和成本，严重影响用户体验。
•当前解决 memory 问题的一个方法是采用多智能体或者工具辅助的方式，例如在 OpenManus 等框架中，通常会通过规划工具先生成规划，每个规划中包含多个任务，每个任务间的 memory 不完全共享，每个任务执行完毕后再进行总结或压缩处理。
•虽然当前能够明确判断一个任务是否正确完成，但在实际场景中，很难量化地评估一个任务完成的准确性或者好坏程度。
•Agent商业化的重要比拼在于将真实场景中的任务和效果，包括个性化的功能，做到极致，用户才会持续使用 Agent。
•大量的应用厂商，都会对 token 消耗进行优化，如在工程上通过缓存还是 memory 压缩技术，尽量减少每次调用的上下文长度。
•未来很可能通过集成多个小模型的能力，实现完整甚至超过大模型的效果，并在推理速度、token 消耗和费用上明显降低成本。
以下为对本次分享内容的更详细整理。
Github一天过万 star，OpenManus 开发揭秘3月6日下午5 点多组会后，劲宇提议，通过几个步骤可能能达到 Manus 的效果。在第一次看 Manus 的演示视频的时候，从视频中的交互过程去看，我下意识地就以为它是一个单智能体系统，非常地震惊，一个单智能体为什么达到这么好的效果，它是怎么规划的，怎么做到的。在晚饭的过程中，聊了一下 Manus 的技术方案，Manus 是一款通用的AI 智能体产品，从用户示例中展示了卓越的用户体验，整体交互给人感觉很不错。但从技术方案上来说，Manus使用了大量的业内共识的核心基础技术。最终我确定它是在外部有一个规划来协调多智能体。晚饭之后，接下来就是开发 OpenManus了。整体使用了三个小时左右的时间。当时没想过 OpenManus 会爆火。Manus 是一个多智能体系统，它首先先使用PlanningTool做规划，形成一个包含多个任务的线性结构的计划，然后顺序执行每一个任务并动态分配给相应的 Agent。Agent 在执行每个任务的过程中，以 ReAct 循环的形式调用工具以完成每一个任务。它具有规划能力和工具使用能力。Manus 将 PlanningTool 规划工具引入多智能体框架。这很重要性，比如 Claude-3.7 在 SWEBench 上达到了，70% 解决率的效果，此前是49% 的 解决率，一部分提升是来源于模型，另一部分就来源于规划。而从我们之前的工作，Data Interpreter 也可以证明规划在处理现实问题中的重要性和有效性。因此，我们不仅会在多智能体上加入规划能力，也会尝试在单智能体上加上规划能力。我们猜测，Manus应该是使用了Claude的模型，和一些其它自己post train的模型，在工程上做了很大程度上的优化，这增强了它在不同场景下的工具使用能力。当时设想的Open Manus 的设计思路主要是：一个极简的Agent框架，应该是可插拔的Tools和 Prompt的组合，之后我们沿着这个思路，写了一个完整的Agent迷你框架。决定一个ReAct Agent( Reason和Act)的效果的关键是提示词引导和工具使用。在 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在接收到用户需求后，会使用PlanningTool形成一个包含多个任务的线性结构的计划，写入至一个 plan 的 markdowns 文件中去，然后OpenManus查看这个 Plan，从中依次取出每个任务，在执行任务时，会将该任务分配给最适合处理该任务的 Agent，这些 Agents 装备了不同的工具集，在处理不同任务时，有不同的优势。需要说明的是：Agent 分配是在执行每个任务时临时被分配的。这种动态分配的方式让系统更灵活，能够根据任务的具体需求和上下文选择最合适的 Agent。目前使用正则匹配对 Agent 进行任务的分配，如果没匹配到，则使用默认配置的 Agent 去执行任务。未来，我们也会考虑让 LLM 去将任务分配给某个 Agent。但每次执行任务时都使用 LLM 识别意图并分配Agent，会增加计算成本和延迟。我们接下来会进行以下的工作，来提升 OpenManus 的效果。主要包括：•引入标准化评测 - 采用GAIA/TAU-Bench/SWE-Bench作为基准，持续评估和优化性能•拓展模型适配 - 从Claude-3-5扩展到DeepSeek V2.5，优化低成本应用场景•丰富示例库 - 增加更多实用案例，包含成功和失败示例的分析我觉得Manus产品交互做的挺好的，有很多技术也值得学习。目前OpenManus效果还很有限，我们还没有单独调效果。OpenManus 前期目标打算达到原始 Manus 的相同的效果，后续会依靠庞大的开源社区不断优化 Computer Use, Browser Use 和 Planning Use，以及工具调用的能力，从而给带来OpenManus更高的智能涌现。3小时复刻Manus，MetaGPT团队已做了不少多智能研发其实我们整个团队在AI场景的自动化和智能体框架上已经有多年的技术积累。在过去两年多，我们持续地将团队内的工作开源和形成学术论文/技术报告，贡献给社区，包括：•MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework•Data Interpreter: An LLM Agent For Data Science•AFlow: Automating Agentic Workflow Generation•FACT: Examining The Effectiveness Of Context Rewriting For Multi-fact Retrieval•SELA: Tree-Search Enhanced LLM Agents For Automated Machine Learning•Self-Supervised Prompt Optimization•SPO：https://www.modelscope.cn/studios/AI-ModelScope/SPO•Atom of Thoughts for Markov LLM Test-Time Scaling我们在2023年就开源了MetaGPT框架，这是一个多智能体的元编程框架，沉淀了多智能体协作的核心思想。我们认为，虽然当时大模型能力已经在通用任务上达到一定水平 ，但要有效解决人类社会复杂问题，需要将问题进行原子化拆解，并集成更符合人类社会解决问题的流程。这里大家可能比较熟悉的是标准操作流程（SOP）概念。通过将SOP分配给不同角色，利用各角色的背景知识和工具能力，我们能显著提升大模型在复杂问题上的表现效果。因此，我们提出了多智能体框架，嵌入SOP，希望实现智能体的元学习（Meta Learning）或元编程（Meta Programming）能力。这种方法在HumanEval和MBPP等基准测试上取得了显著效果，相比当时的GPT-4模型有很大提升。我们还在一些典型的软件开发应用上验证了这一思路，包括大家熟悉的如2048小游戏和贪吃蛇等。与同期的其他开源框架相比，我们的整体成功率明显更高。随后，在MetaGPT框架和智能体设计的基础上，我们意识到智能体还需要更强的规划能力和工具使用能力，尤其是在解决机器学习或数据建模问题时对工具使用能力的要求更高。一方面，机器学习/数据建模流程通常可以结合大模型能力规划出来完整流程，大模型可以更关注任务的执行和实现。另一方面，处理大型表格数据时，由于大模型上下文限制，无法直接输入全部数据。因此，我们需要智能体通过代码形式与数据交互。所以在2023年下半年，我们开始探索规划能力和工具使用能力，沉淀出"数据解释器"（Data Interpreter）这一工作。在Devin等项目出圈的那段时间，我们发现Data Interpreter在数据建模/机器学习等任务上已经达到了初级数据分析师的水平。只需将数据交给它，它就能完成从数据处理到NLP/CV模型训练复杂AI任务。在数据解释器工作的基础上，为进一步提高效果，我们认为需要增强智能体的调试能力和对实验结果的反馈机制。因此，我们开发了名为"SELA"的工作，在数据解释器基础上增加了蒙特卡洛搜索方法，使智能体通过自主的实验方式，进行机器学习任务的自动优化，在推理过程中进行多样性的探索，并根据执行结果反馈调整策略和求解步骤，从而进一步提高整体任务表现。通过这种方式，我们显著提升了数据解释器（Agent）在机器学习任务上的能力，达到了与自动机器学习（AutoML）工具相当的水平，相比当时优秀的开源项目（如AIDE）也实现了显著提升。同期，我们还基于蒙特卡洛树搜索（MCTS）在一大模型推理能力的提升上进行了探索，并研发了AFlow工作。不同于固定SOP的方案，AFLOW可以为不同任务自动搜索合适的解决流程。AFlow的创新点在于：如何在不同问题上提升解决效果？我们希望系统能自主根据问题反馈，自动探索出最优的智能体组合（拓扑结构），使最终解决问题的智能体组合更动态，规模也不需要预先规定。AFlow通过定义问题原子化的搜索空间，并利用蒙特卡洛方法探索和优化多智能体的组合拓扑结构。这项工作在六个数据集上均取得了SOTA结果，并获得了ICLR 2025的Oral认可。同时，我们注意到，随着智能体解决问题步骤的增加，其记忆（Memory）体量也会增大。因此，我们需要解决智能体在整个问题求解过程中的上下文管理问题，通过改进检索和上下文压缩来提升这方面的能力。因此，我们提出了名为"FACT"的工作，通过多针查找机制提升大模型在事实查找上的准确率，在问答（QA）问题上展现了显著效果。这项工作也获得了NAACL的录用。此外，去年9月份左右，我们还在SWE-Bench上进行了能力探索。我们发现，大模型代码修复等问题上，需要依赖文件定位&查找，以及computer use的能力，同时对工具使用能力和规划能力提出了较高的要求。许多工作采用多智能体方式来解决这类长链复杂推理过程。因此，我们也在这个benchmark的任务中加入和优化了文件定位、文件查找等能力，这也成为了OpenManus代码的基础。如果查看OpenManus的代码，会发现其中不少工具与代码修复和定位相关。SPO是一套提示词优化工具。与传统需要大量数据集的优化方法不同，SPO适用于没有准确评分或数据集有限的场景。例如，写小红书文案或SEO优化时，我们可能只有几个满意的样例。SPO能在这种有限样例条件下进行提示词优化。该工具已经开源，在国内魔搭平台和Hugging Face上均有良好反馈。AOT（原子思维）则用于问答类信息推理和整合任务，如从不同段落整合信息进行阅读理解。这项工作已有35万浏览量，后续会整合到MetaGPT框架中。随着大模型能力的增加，许多问题的解决成功率会提高，但问题本身并不会消失。例如，我们前面提到的QA、HumanEval和MBPP这类单函数代码生成的问题，现在单模型已经能直接解决得非常好。从去年到今年，大模型的能力在这类问题上的成功率已接近实用水平。但我们也发现，人类社会有很多非常复杂和长尾的问题，包括我们正在解决的机器学习、代码修复，以及通过搜索组合结果提供给用户的问题。这些仍需要大量技术工作来提升大模型的效果，包括解决幻觉问题。Q2：大模型能力提升与Agent提升的关系是什么？Agent与大模型可能是一种垂直或正交的关系。框架本身的提升会因为模型能力的提升而带来更多功能，它们并不冲突。框架本身扩展了更多工具，可以让大模型与物理世界或更多环境进行交互。同时，大模型自身的提升会增强其推理和规划能力。两者可以组合使用，也可以分离开来。Q3. Foundation Agent Model 目前能达到什么水平？最近我正好看过一些相关的工作，不过可能不完全是 Foundation Agent Model。我观察到Pan Jiayi团队做了一些尝试，他们在SWE-GYM这个项目来解决代码库修复的问题 。他们使用了基于 Claude 或者 GPT-4o 等模型运行后产生的数据，然后再借助 Openhands 等框架来采集 Agent 运行过程中的轨迹数据。这些轨迹中既包含成功案例，也包括失败案例。他们将收集的轨迹数据重新用于训练Qwen的开源模型，观察到Qwen模型在这种训练后取得了能力上的提升。他们在论文中详细描述了这一过程，研究内容较为扎实。目前这类工作的泛化难点在于，例如在 SWE-Bench 中，我们能够明确判断一个任务是否正确完成，但在实际场景中，很多场景下我们很难量化地评估一个任务完成的准确性或者好坏程度（例如写一篇小说或笑话）。就像在现实工作场景里，一个实习生和一个资深员工同时完成一项工作，要对他们各自的表现打分时，其实很难客观地判断，需要基于很多主观的业务逻辑和标准来确定。这种开放任务下的评估反馈自动设计也是我们未来探索的一个重要方向。Q4. Agent 在规划（Planning）上的进步是否主要依赖于大模型本身？目前在规划方面的进步，一方面取决于模型本身能力的提升，另一方面也依靠外部结构的辅助，即在 Agent 的层面上加入更加复杂的结构进行辅助规划。例如最早的工作之一是 "Tree of Thought"（TOT），它通过引入额外的结构，使模型在任务推理过程中取得了显著增强。同样地，在规划领域中，也有类似的外部结构辅助相关工作在进行。目前在 OpenManus 中，我们主要还是使用一些现有的开源工具，比如 Cloud Computer 和 Browser 等。有其他团队开展的 Browser 使用相关工作表明，仅凭这两个工具基本上就能完成许多任务，已经初步形成了 Manus 的雏形。另外，关于如果 Agent 想要使用某个工具，但目前并没有这样的工具时，我们也设想了未来可能增加一种赋予 agent 自己创建工具的能力。当 Agent 需要工具去完成一件任务时，若目前环境中没有合适的工具，它可以自行创建并使用。这将进一步增强 Agent 的能力。我认为大模型或者 Agent 使用工具本身并不新奇。但是随着工具的数量逐步增加，其中的技术难点也随之而来：如果有众多相似工具，Agent 在解决同一任务时如何做出准确决策，选择最合适的工具，并避免决策错误。此外，如果不是使用标准化的工具接口，而是使用自行定义的工具时，还可能面临另一个问题：工具的参数定义不合理或不够明确，这将导致大模型在生成调用工具决策时容易出错，工具执行效果因此受到影响。这些都是工具使用环节中需要解决的问题。另外一个难点是，即不仅仅是工具的选择和使用本身，而是上下文中可能包含很多细节信息，例如用户同时打开不同网页时，这些网页上的信息和数据（比如某个简历的时间、另外网页的提及的一个事件的起始时间），Agent 在整合生成最终结果时可能会造成混淆或错误。如何保证 agent 在使用工具时准确地处理这些细节信息，也是实际应用中需要重点解决的问题。Q6. MCP 等协议在工具使用方面会成为主流吗？工具使用的能力，这实际上取决于模型本身是否具备良好的工具使用能力。因为某些模型可能并不具备工具使用能力，或是这方面能力较弱，在使用工具时效果就会受到限制。因此，工具协议的普及与模型自身具备较强的工具使用能力密切关联。Q7. Agent 在处理海量上下文（Memory 管理）时有哪些进展和难点？目前大家可能了解一些已有工作，如 MemoryGPT 或开源项目 Mem0，它们都对较长的上下文和 Agent 的记忆管理做了一些优化和处理。例如 MemoryGPT 对一定的上下文进行总结，这是一种非常朴素但也有效的思想。Mem0则在 memory 更新过程中主动使用工具，涉及 memory删除、memory 更新和新增等操作。目前 Agent 在处理复杂、长程任务（例如浏览网页时，网页信息可能非常长）时，如何压缩上下文并存储到记忆中，是一个非常具有挑战性的问题，并且要确保压缩后关键的信息不会被修改或遗漏。早期一些研究工作指出，memory 会随着时间或任务步骤的增加而消退。另一方面，人的 memory 存在多种类型，不仅仅是语义信息的记忆，还包括工具使用时产生的程序性记忆以及事件关联关系的记忆。学术界也针对不同的记忆类型分别进行优化。以上提到的是单个 Agent 的 memory 管理情况。而在多智能体系统中，我们可以更加巧妙地利用 memory。除了一定程度的隔离外，人们还希望复用其他 Agent 在解决问题过程中产生的 memory，以增强自己处理特定任务的经验。此外 Agent 可以进化，复用群体的解决问题经验，最终形成一种群体智能。memory 管理主要涉及成本问题。如果我们不考虑 memory，不做压缩和任何处理，直接使用完整的 memory，目前的大模型仍然可以处理，但这样带来的问题并非质量下降，而是会显著增加处理时间和成本，严重影响用户体验。因此，这个问题涉及工程层面的优化，目前已有一些公司或组织在尝试优化 memory。当前解决 memory 问题的一个方法是采用多智能体或者工具辅助的方式，例如在 OpenManus 等框架中，通常会通过规划工具先生成规划，每个规划中包含多个任务，每个任务间的 memory 不完全共享，每个任务执行完毕后再进行总结或压缩处理。 我认为最重要的是将真实场景中的任务和效果，包括个性化的功能，做到极致。目前学术界的许多工作，无论是针对 SWEBench、GAIA 还是其他的 Agent 测试任务，任务成功率依然有限。如果这种相对微小的任务标准对应到真实的商业场景中，不同用户面对不同难度的问题，目前 Agent 的成功率还相当受限。 因此，无论是编程任务，还是数据收集和报告生成任务，如果能够针对各种各样的用户问题和场景做到极致，将成功率提升到令人满意的程度，真正实现 Agent 达到人们当前所期望的行动能力，我相信用户会持续使用 Agent，将其作为日常的助手和工具。Q9. 当前 Manus、OpenManus 等 Agent 成本较高，如何进一步降本增效？首先大量的应用厂商，包括我们自己在内，都会对 token 消耗进行优化，无论是在工程上通过缓存还是 memory 压缩技术，尽量减少每次调用的上下文长度，这是在应用层面持续优化的方向。此外，未来大家很可能会部署大量小模型，基于已有数据进行微调或强化，专注于优化某些节点或工具使用的能力。通过集成多个小模型的能力，实现完整甚至超过大模型的效果。这样就可以在推理速度、token 消耗和费用上明显降低成本。首先我们认为在代码生成领域，无论是单个 Agent 还是多智能体系统，都可以更早实现商业落地。我们发现大量用户虽然编程水平一般，但懂一些基本概念，想自行搭建个人网站或简单的应用程序时，非常需要智能体或大模型辅助解决问题。如果用户直接使用大模型，可能需要多轮交互和烦琐的调试过程。但如果使用产品化的智能体系统，这个过程就能变得更加轻松。用户可能只需要花费 15 分钟或半小时，甚至包括后续需求变更，也能快速获得令人满意的网站或应用。 因此我认为，在真正有效解决用户实际需求方面，多智能体的商业前景是明确且强烈的，也是 Agent 技术目前能较好解决的场景。目前用户在这方面的付费意愿也是较高的。04
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 能够判断页面或数据仪表盘的质量与审美表现是否符合预期。
（完）
目前，OpenManus团队也正邀请志同道合的开发者加入Contribute或参与运
立即咨询 JOTO
JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务，帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。 联系 JOTO 获取 AI 落地咨询
