深度解析Agent实现，定制自己的Manus

前一阶段大火，被宣传为全球首款“真正意义上的通用AI Agent”，其核心能力就是基于LLM的自主任务分解与执行，根据官方测试数据，Manus 在 GAIA 基准测试中表现超越 OpenAI 同类产品，且完成任务的成本更低。虽然之后技术大咖们对齐技术深度表示不屑（嫉妒~）， 认为其缺乏底层创新，依赖现有工具链组合。 但其工程化整合能力仍具有较高的价值，另外还有两个明显的特点，值得学习。

随后MetaGPT团队推出了OpenManus，宣称是Manus的开源复刻版，且在3小时内完成基础开发（看代码提交记录确实卷）。 OpenManus是一个简洁的实现方案，还在快速迭代中， 趁着项目还没有熟透，克隆下来学习了下。对比LangChain，代码结构还算比较容易理解，是一个很好的学习项目，也比较容易做二次开发。 周末花了两天时间基于OpenManus做了二次开发，希望构建属于自己的“Manus”，在这过程中对Agent有了更明确的实践认知，在这里分享下这个过程。 

为了让读者对Agent能够有系统的认识，同时也可以对Agent的认识完成一次祛魅的过程。 本篇文章结构为： 

1）认识， 对AI Agent相关的一些组成进行原理性解释

2）设计，基于OpenManus构建自己的MyManus，落地和验证认识中的一些概念和原理

3）实验，基于MyManus进行验证，对当前的Agent存在的问题有个直观的感受。

4）改进，结合前面的实验以及Agent当下的问题，探讨未来的方向和改进方案。

结合Agent相关的几篇关键文章和论文，梳理下基于LLM的AI Agent的设计模式以及一些原理性的概念。ATA上关于LLM和Agent的原理性的优质文章太多，这里主要涉及Manus或OpenManus用到的部分。

你只需要告诉我你要什么，不要告诉我怎么做。

AI Agent将使软件架构的范式从面向过程迁移到面向目标，就像传统面向过程的工作流和K8S的声明式设计模式一样， 当然这两种解决的问题是不一样的， K8s通过定义期望状态而非具体步骤来管理集群，降低集群状态管理的复杂度，确保集群的稳定性和容错性。 Agent之前，传统的软件架构，只能解决有限范围的任务， 而基于Agent的架构，可以解决无限域的任务，真正意义上的个性化服务。

ProAgent: From Robotic Process Automation to Agentic Process Automation

我们可以从Manus的官方网站看到，Manus宣称可以做如下的事情，并提供了相当丰富的案例。

不同的机构或团队， 对Agent的架构模块的划分略有差异，但基本上包含了：感知，记忆，规划，行动四个核心的要素。 此外，部分团队还涉及定义（管理 Agent 角色特性）、学习（预训练、小样本学习）、认知与意识（思考、整体认知）等特色模块。

*内容来源：华泰证券研究所

Lilian Weng（翁荔）LLM Powered Autonomous Agents 这篇博客被广泛认为是 “AI Agent领域最权威的结构化综述之一” ，为开发者提供了技术框架参考， 大家应该对文中的图已经很熟悉了， 作者将 AI Agent 定义为 “规划 + 记忆 + 工具调用” 的组合，强调LLM作为系统的核心控制器。

接下来围绕Agent几个核心要素进行设计，会先简单介绍一些基本的原理，然后基于OpenManus做二次设计或者展示其原来的实现。 

在这之前概括下LLM的一些基本的原理，关于LLM的原理性文章已经很多了，这里只对LLM的推理原理做个简单回顾。

当下的LLM的核心依然是基于神经网络， 相比传统的神经网络CNN/RNN等，Transformer架构通过自注意力机制允许模型直接计算任意两个位置之间的关系，从而更高效捕捉长距离依赖，使得LLM有更强大的多层叠加能力。Transformer的并行计算能力（如自注意力的矩阵运算）同时加速了训练速度，支持更大的模型规模。另外通过多层非线性激活函数（如 ReLU、GeLU）可学习更加复杂模式， 随着参数规模和训练数据增加，LLM 会突现传统神经网络难以实现的能力（如逻辑推理、代码生成），LLM具备了涌现能力！（ 也许这就是量变产生了质变吧）

LLM的推理简单理解为是一个 “模式匹配 + 概率计算” 的过程，通过 Transformer 架构和自回归生成，基于海量文本学习到的统计规律，逐步生成符合语言习惯的输出。其效果依赖于训练数据的质量、模型规模以及生成策略的选择。 每一步生成都依赖于已生成的上下文，即通过已知的前序词预测下一个词，当前LLM具备上下文学习（In-Context Learning）能力，LLM通过Prompt中提供的示例或指令，无需参数更新即可适应新任务，依然是在于利用模型的模式匹配能力和统计规律，Transformer 架构中，Prompt的token位置靠前，权重更高，对后续生成的影响更大。 

LLM的涌现能力使其具备复杂任务处理能力，但同时也因训练数据的噪声和统计生成特性，容易产生幻觉。RAG通过引入外部知识减少幻觉，SFT微调通过高质量数据优化输出，Agent通过工具调用增强交互能力。这些方法可在一定程度上缓解幻觉，增强可解释性， 但可解释性仍受限于LLM的黑箱特性。Agent设计中，Prompt是核心组件之一，所有的设计都是围绕构建和管理Prompt，需结合工具调用、记忆管理等模块设计。为适应不同任务，Prompt需精细化设计并管理多个版本。

前面了解到，LLM本质上就是一个具有数十亿到千亿级别参数的无状态函数， 比如可以这样：

LLM自身不具备主动记忆功能，但可通过外部技术（如提示工程、记忆模块）模拟记忆效果，以增强任务表现和交互连贯性。所以别想着LLM会有人类的情感啦，LLM的“连贯性”是概率驱动的，而非真正的意图或情感。

LLM就像一个失忆的绝世高手一样，虽然没有记忆，但可以武功还在， LLM回复完全基于输入的提示（prompt）和训练数据中的模式，通常我们所说的记忆是指的是用户输入提示， 分为短期记忆和长期记忆。

我们设计一个简单的短期记忆模块， 记录推理和外部感知的结果信息， 每次调用LLM时都会带上（受限于LLM的最大Token）, 这样LLM就会在每次推理时“记住”之前的推理过程，以及外部工具感知的结论。相当于：每次你问问题，都要讲一遍前面的交流内容。 定义Memory类，记录每次的Message内容。

以下是Memory内容例子

人类创造、修改和利用外部物体来做超出人类身体和认知极限的事情，为 LLM 配备外部工具可以显著扩展模型功能和应用场景。

Agent的工具调用，实际上是借助LLM的能力， LLM需要先理解工具的功能和参数格式。

Tool Learning with Large Language Models: A Survey

上图可以简单概括为： 

1. 你有一系列工具，同时有比较详细的说明书， 你拿着说明书找LLM问一个LLM自身推理无法（准确）完成的问题， 比如：今天几号，天气怎么样， 当前数据库内容是什么， 这些预训练的LLM是无法感知到的， 需要借助外部工具。

2. LLM会从你的工具说明书列表中选工具，准确地告诉你你应该用哪个工具，同时把输入参数也给你（基于说明书描述）

3. 你拿到后调用工具，获取感知信息， 然后再把结果信息给到LLM。

4. LLM判断输出结果，并继续回答你之前的问题。

举一个基于LangChain的简单例子， 加了些HTTP请求埋点， 方便跟踪LangChain与LLM的IO交互。

Lilian Weng博文里Planning包含四个子模块，Reflection（反思）、Self-critics（自我批评）、Chain of thoughts（思维链）、Subgoal decomposition（子目标分解）， Planning将任务分解为可执行的步骤，并根据反馈不断优化计划。例如，通过Subgoal decomposition将大任务拆解为小任务，通过Reflection评估结果并调整策略。

我们可以通过 Reason + Act（ReAct）和Plan-and-Solve（PS）来初步实现Agent的Planning能力。还有一些其他的模式。 比如ToT 模式（ 提示词：“生成3种不同预算方案，总预算不超过10万元，并列出每个方案的子任务”）， 基于角色的多Agent（MetaGPT）

Reason + Act 推理-行动-反馈

ReAct通过LLM交替执行推理和行动，增强了推理和外界感知（通过行动获得）之间的协同作用：推理帮助模型推断、跟踪和更新行动计划，以及处理异常，而行动则允许它与外部资源（如知识库或环境）交互，以获取额外信息。

ReAct: Synergizing Reasoning and Acting in Language Models

设计ReActAgent流程， 如下图，实现重复的Thought- Action-Observation 

退出机制有2种方式，一种是当超过最大步数， 另一是当LLM提示要调用一个终止工具时，退出循环。

manus 教程终止工具描述为：When you have finished all the tasks, call this tool to end the work。

设计ReAct抽象类，由主体的Agent继承， 包含llm和memory，同时有think和act两个阶段的操作，think通过调用LLM进行推理， act主要是调用工具获取额外的信息。 通过step串联， step由Agent重复调用，每次都会通过LLM的推理判断是否需要调用工具。

Plan-and-Solve

Chain-of-Thought（CoT）使LLMs能够明确地生成推理步骤并提高它们在推理任务中的准确性。比如Zero-short-CoT将目标问题陈述结合”让我们逐步思考”这样的提示词， 作为LLM的输入。这是一种隐式生成推理链，具有一定的模糊性，存在语义理解错误， 无法生成合理的计划等问题

Plan-and-Solve是一种改进的CoT提示方法 ，通过显式分解任务为子目标并分步执行，提升复杂任务的推理能力。Plan-and-Solve将传统的“黑箱”推理操作，进一步转化为结构化流程，使得Agent的可解释性增强， 而且还可以动态调整和反思。 是Agent实现Planning能力的很好的技术支撑。

Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models

参考Plan-and-Solve论文，设计一个Planner

我们完成了Agent的Memory，Tools，Planning的核心模块，这里还差一个LLM模型调用， 目前各个云厂商或者模型部署工具Ollama，vLLM之类的都兼容OpenAI的API接口， 某种程度上算是统一了~。

现在需要把这几个组装起来。文章开头提到了， OpenManus是个好的学习项目， 所以整体实现也是基于（抄）OpenManus实现的，暂且命名为MyManus！为了便于加深理解，实验以及后续的扩展， 做了如下改动。

以下为整体的设计

到这里， 你会发现前面的Memory，Tools，Planning每一部分，其实都是在解决最核心的问题：如何在正确阶段构建最佳的Prompt，印证了LLM部分描述提示词的重要性。 所以Prompt非常重要， 如果你发现Agent效果不好， 可以先从优化提示词开始。 

系统的提示词，某种程度上决定了LLM对Agent的特质和能力判断， 比如借助LLM生成计划，如果没有设计系统的提示词，LLM根据用户的输入，会生成完全无关的计划，思考的域越大，效果会越差。 Openmanus里面的计划系统提示词，就很明确地告知LLM的如何执行计划，如何使用工具等。 

每一步的提示词，决定LLM如何使用工具， 比如我希望LLM优先使用RemoteJupyterClient，可以重点强调其作用，尤其是加了You Can also use pip install packages when package not found 这一句，LLM可以生成pip命令，自动安装包。 

Planning

好了， 终于到实验环节了， 为了验证前面的实现，做了以下几个场景的实验。 

经过我精心雕花，我们可以借助WebUI来观察效果，Planning和ReAct Agent用的LLM都是：qwen-max-latest

总结，我们可以从以上几个实验看到：

Executable Code Actions Elicit Better LLM Agents

Lost in the Middle: How Language Models Use Long Contexts

Mem0 Memory Operations

StreamBench: Towards Benchmarking Continuous Improvement of Language Agents

ChatDev: Communicative Agents for Software Developmen

吴恩达提到的Agent设计模式有四个（Reflection，Tool Use， Planning，Multi-Agent Collaboration），我们验证了前三个。

Multi-Agent Collaboration可以提高任务执行效率，多个智能体分工协作，同时具备复杂问题分解能力。 

每个Agent各司其职，其上下文记忆对LLM也友好， 不容易偏差，可以更好的利用LLM。 凡事都有两面性，多个Agent也会带来新的问题，就如同微服务相对于单体应用一样，增加了系统的复杂度。 这就引入了Agent之间协作，信息共享，隐私安全，多智能体学习问题。下图是《Why Do Multi-Agent LLM Systems Fail?》 这篇Paper描述的三种常见的失败类别。 

Why Do Multi-Agent LLM Systems Fail?

前文提到的Planning的问题，对于复杂问题的规划，往往会遇到困难或者因为LLM的幻觉，生成不合理的步骤。 虽然ReActAgent有时可以通过推理，行动，观察来为Planning的不合理计划兜底， 但是会降低Agent的效率。

归因为没有对Planning生成的计划进行验证。 针对这个问题，Google提出了新的框架PLanGEN, 包含三个关键的组件： 约束，验证和选择智能体。在PlanGEN框架中，智能体根据实例复杂性优化算法选择，确保更好地适应复杂的规划问题， 约束引导的迭代验证可以提升推理时算法的性能，而适应性的选择则进一步提高了在复杂规划和推理问题上的表现。

PlanGEN: A Multi-Agent Framework for Generating Planning and Reasoning Trajectories for Complex Problem Solving

另外《Scaling Large-Language-Model-based Multi-Agent Collaboration》https://arxiv.org/abs/2406.07155这篇Paper提到了协作涌现。 受到神经网络规模法则的启发，增加神经元会导致新能力的涌现，在多智能体协作中，增加智能体是否遵循类似的原理，挺有趣的。 

MCP（Model Context Protocol）是由Anthropic公司提出的一种协议，其核心动机在于显著提升AI模型（如Claude）与外部系统之间的交互能力。通过开源的方式，MCP不仅鼓励社区共同参与和完善这一协议，还旨在推动AI Agent生态的发展。从技术角度来看，MCP的设计并不复杂，但其真正的力量来自于共识——这种共识使得不同系统间的协作成为可能，并为开发者提供了一种标准化的解决方案。

借助MCP，Agent只需一次接入即可无缝适配多种工具和服务，从而大幅减少碎片化开发的重复劳动。MCP让一个Agent能够连接整个世界，实现跨系统的无缝集成能力。如果想追踪MCP当前的发展动态及其生态状况，可以关注awesome-mcp-servers：https://github.com/punkpeye/awesome-mcp-servers项目，这里汇聚了全球开发者对这一领域的最新探索与贡献。

在架构设计上，MCP将Host（Client）与Server分离，工具由Server端调用，而Server端则负责统一管控这些工具的使用，并对外提供服务。这种设计模式提高了系统的灵活性和可扩展性， 对于云服务提供商来说或者Dify这种LLMOps中间价产品，是利好的， 个人觉得可能有如下几个方面：

1. 服务复用 

MCP通过标准化工具集成流程，云厂商无需再为每个客户或场景单独开发接口，客户也不需要定制开发，而是可以直接复用现有的成熟服务模块。在保证功能完整性的同时，也降低了维护成本。

2. 一站式平台构建 

依托MCP的标准化协议，云厂商能够快速搭建起“一站式”AI服务平台。例如，通过可视化管理界面和低代码工作流配置工具，用户无需深入理解底层技术细节，便可轻松完成复杂的任务部署。

3. 工具生态整合 

在MCP的支持下，客户不仅可以享受云厂商提供的专属工具，还能自由利用开源生态中的丰富资源，如数据库、浏览器自动化工具等。这些工具通过Agent进行统一调用，形成了一套协同的工作体系。云厂商因此得以借助开源社区的力量，避免从零开始开发，从而帮助用户加速AI应用的落地进程，这是一种共生关系。

4. 合规与安全性保障 

通过在MCP Server端实施权限管理、审计机制以及沙箱环境的构建，能有效减少敏感数据暴露的风险。例如，在MyManus中引入JupyterClient时，就是希望为代码执行其设计了一个受控的沙箱环境，允许单租户拥有专属的环境变量设置。

也有反对使用MCP的， 比如LangChain发起了讨论，并对MCP是否是昙花一现发起了投票，有40%的人认为是个未来的标准， 20%的认为是昙花一现。 具体讨论可以看 MCP: Flash in the Pan or Future Standard? . 

https://blog.langchain.dev/mcp-fad-or-fixture/

当下不能过于神化任何AI相关东西，MCP解决不了LLM很多时候无法正确地使用工具问题，但还是值得投入研究的，“人们总是高估一项科技所带来的短期效益，却又低估它的长期影响”。AI最大的机会可能在于改变现有的业务流程和产品，专注特定的小规模的业务场景，深入解决具体问题，而不是追求建立大型平台。

看了许多关于人工智能的学术文章与技术论文之后， 深切体会到，唯有将这些理论付诸实践，将其转化为文字和具体的代码，才能真正感受到当下大型语言模型（LLM）所蕴含的非凡魅力，这种从认识到实践的过程，不仅加深了技术理解，更是一场思想深度对话，Agent相关的研究还有很多，希望这篇文章对大家有帮助，也算是为知识传播尽了一份绵薄之力，如果没有，书写本身便已是一种自我沉淀与逻辑自洽的过程，也足以让自己满足~

参考附录：