链载Ai

标题: 拆解多基于LangGraph的多Agent项目设计和技术细节 [打印本页]

---

作者: 链载Ai    时间: 2025-12-2 09:50
标题: 拆解多基于LangGraph的多Agent项目设计和技术细节

吴恩达最近在他的公开课上说：我认为AI Agent工作流将在今年推动人工智能的巨大进步，甚至可能超过下一代基础模型。这是一个重要的趋势，我敦促所有从事人工智能工作的人关注它。加上上个月在他红杉AI峰会上分享的，实现Agent工作流的4种范式，可以看出吴恩达一直比较关注Agent的发展。

解释一下这4种范式

1. Reflection：反思，LLM审视自己的工作，找出改进的方法。

2. Tool Use：使用工具，LLM被赋予了一些工具，如网络搜索、代码执行或任何其他功能，以帮助它收集信息、采取行动或处理数据。

3. Planning：计划，LLM提出并执行一个多步骤计划来实现一个目标（例如，写一篇文章的提纲，然后进行在线研究，然后写一份草稿，等等）。

4. Multi-agent collaboration：多Agent协作，多个AI Agent协同工作，分解任务，讨论和辩论想法，提出比单个智能体更好的解决方案。

目的

本文我们拆解一下Github上的一个项目GPT-researcher（https://github.com/assafelovic/gpt-researcher），项目通过多个Agent的协作，基于用户输入的主题，上网搜索资料、分析和写作，最终输出几页PDF或者Markdown格式的研究报告。这个项目也是受到斯坦福大学的STORM研究论文的启发，感兴趣的可以参考https://arxiv.org/abs/2402.14207。

整体的执行流程涉及到了上面吴恩达说的4种范式，多Agent协作、Plan-and-Execute、使用工具（上网搜索资料）、反思。

多个Agent的协作是基于LangGraph实现的，LangGraph是LangChain的扩展包，这个后面再说，我也想吐吐槽LangGraph。

多Agent协作架构

项目有一个核心的模块gpt-researcher，实现的功能，根据用户给出的主题，让LLM选择一个合适的Agent。按主题生成计划，再根据计划生成多个Query的子查询。根据每个子查询，上网搜索资料并整理汇总，给出资料来源。最后根据所有子查询的输出，汇总并格式化成报告。这个是作者早期实现的功能，后面有机会再详细讲解，本文主要是介绍基于LangGraph的多Agent协作。

主要包括7个Agent，模拟一个研究团队协作：

1. Chief Editor：主编，监督研究过程并管理团队。这是使用LangGraph协调其他Agent的“主”Agent。

2. Researcher：研究人员，使用核心的模块gpt-researcher，对给定的主题进行深入研究。

3. Editor：编辑，负责规划研究大纲和结构。

4. Reviewer：评审员，根据一系列标准验证研究结果的正确性。

5. Revisor：校订员，根据评审员的反馈对研究结果进行校订。

6. Writer：撰稿人，负责最终报告的编写。

7. Publisher：出版人，负责以PDF、WORD、MD各种格式发布最终报告。

流程图

主要流程：

1. 用户给定任务Task，包括主题Query，最大分段数Max-sections，其他要求Guidelines等。

2. Chief Editor这个主Agent会接收Task，初始化流程执行器（Executor，LangGraph的流程），把任务给到Browser。

3. 上图的Browser也是Researcher这个Agent，Researcher根据给定的研究任务浏览互联网进行初步研究。

4. Editor编辑，这个是个复杂Agent，根据初步研究规划报告大纲和结构，执行Plan-and-Execute。Editor编辑包含了一个LangGraph子流程。

5. 对于每个大纲主题（并行），这是体现LangGraph优势的地方，能执行循环迭代的流程，Reviewer评审员和Revisor校订员：
   

1. Researcher研究人员负责调用gpt-researcher，对子主题进行深入研究并撰写草稿。
2. Reviewer评审员根据一系列标准验，就是上面用户给定的Task里的其他要求Guidelines，证草案的正确性并提供反馈。
3. Revisor校订员根据审查员的反馈，对草案进行校订，然后再给回Reviewer评审员，直到其满意为止，就是Reviewer评审员不再给出修改意见。

• Writer撰稿人编译并撰写最终报告，包括引言、结论和参考文献部分。
• Publisher出版人将最终报告发布为多种格式，如PDF、Docx、Markdown等。
上面这张流程图作者画的不是很好，Chief Editor没有体现，Task直接就到了Browser，一般人看了都会懵。上面不是说定义了7个Agent的吗？Browser哪来的，实际上就是Researcher这个Agent。Researcher定义了实现了两个功能，一个是生成大纲，一个是根据大纲中的一条主题详细分析生成草稿。另一个是Researcher和Revisor的循环，实际上Researcher并没有参与循环，完成草稿后，Researcher就结束了，后续是Reviewer和Revisor的循环。第三个右侧空白的子流程，我理解作者的意思应该是想表达，大纲分成了多个主题，每个主题都会有一条像左侧一样的子流程。但你画几个空白的框框。。。不去看源码估计很难理解吧。


一些技术细节
工具使用作为Agent很重要的一个特性，现在几乎所有的LLM都支持tool calling。LangChain也提供了几种Tool实现方式，以及大量封装好的社区工具，开发者可以很方便给LLM引入额外的能力，可以让LLM在接收到输入的时候，自行判断是否要调用工具，以及从输入中提取所需的参数。但这个项目的Agent的没有用到，作者自己实现了python的方法（大部分的run方法），并直接设置成了LangGraph的节点。也不是不行。。。只是这样Agent就只有对象封装的作用了。
这个Agent的核心除了执行逻辑外，就是Prompt，定义了每个Agent人设定位，以及跟LLM交互时要做的事。以Revisor为例，主要的Prompt如下

#pythonprompt=[{"role":"system","content":"Youareanexpertwriter.Yourgoalistorevisedraftsbasedonreviewernotes."},{"role":"user","content":f"""Draft:\n{draft_report}"+"Reviewer'snotes:\n{review}\n\nYouhavebeentaskedbyyourreviewerwithrevisingthefollowingdraft,whichwaswrittenbyanon-expert.Ifyoudecidetofollowthereviewer'snotes,pleasewriteanewdraftandmakesuretoaddressallofthepointstheyraised.Pleasekeepallotheraspectsofthedraftthesame.YouMUSTreturnnothingbutaJSONinthefollowingformat:{sample_revision_notes}"""}]

翻译一下主要内容

"role": "system",
"content": "你是个专业作家。你的目标是根据审阅者笔记修改草稿。"

"role": "user",
"content": "你的审稿人委托你修改以下由非专家撰写的草案。
如果你决定遵循审稿人的笔记，请写一份新的草稿，并确保解决他们提出的所有问题。
请保持草案的所有其他方面不变。
你只能返回以下格式的JSON："



搜索工具
作为一个输出研究报告的项目，通过网络获取信息是理所当然的。信息来源可以有三种方式，一是LLM内化的知识，这个取决于训练数据，而且已经做了压缩。二是维护好的数据库，业务数据或者个人收录的文档等。三是网络信息，通过搜索引擎实时获取数据。
现阶段比较流行的搜索引擎有以下几种：
• Tavily：一家AI时代崛起的初创公司，提供Search和News相关的API接口，能实时返回对LLM比较友好的格式。我自己开发的时候用的也是它，整体效果还是非常不错，免费的调用次数只有1000次，跑这个项目一次就消耗6次了。
• SerpApi：老牌的搜索API集成服务，连百度的API接口都有，就是收费有点贵。
• DuckDuckGo：一个强调隐私的搜索引擎，不跟踪用户的搜索历史或浏览习惯。
• BingSearch：微软公司推出的搜索引擎，可以在Azure云服务上开通使用，但返回结果还是比较传统的格式。
• SearxNG：开源，可以自己部署，我试过后觉得效果比较一般，放弃了。但开源免费的诱惑力还是相当大的。
还有其他很多的，Yahoo金融新闻、股票数据、WIKI百科、Youtube视频、ArXiv论文等等


思考
这个多Agent的架构最终输出文档的格式还是像模像样的，但内容就比较一般了，跟人比起来是不及格的，这也是目前大多数AI应用的问题。初看感觉很惊艳，但真要解决问题，总是差那么点意思。业务想要的效果是90分，现在大多数输出只能70分。作为研究助手Copilot还是有用的，免去了自己去网上各种搜索资料，这一点跟秘塔差不多。看看输出的效果



AI Agent备受推崇，吴恩达、山姆奥特曼这些领域名人也一直在关注，前段时间百度李彦宏也是呼吁大家去卷应用。Agent虽然不是什么新的概念，但到现在也很难有个明确的定义，什么样叫Agent，这个项目的实现算不算。不过可以不用纠结，邓爷爷说的，不管黑猫白猫，抓住老鼠的就是好猫。核心还是能解决用户现实的问题，用户只关心结果，关心需求是否被满足，大部分人是不会在意背后的实现原理的。这个项目还是很有参考价值的，我希望AI能帮我阅读研究一个领域的论文和博文，然后总结整理出我需要的信息结构，后续我会尝试去实现。


吐槽一下LangGraph
LangGraph是基于LangChain LCEL的封装，实现了很多开销即用的功能，但这些封装对于一些个性化实现来说就很麻烦了。比如我想要多轮对话的场景下，在运行时根据用户输入改变逻辑，原来是LLM判断是否使用工具，在用户当前这次对话就想要强制使用某个工具。这个实现起来就比较麻烦，如果要做到，需要修改非常多内容，去定义实现。
LangGraph设计了尽可能满足主要的通用需求，对于开发者来说，上手比较快，开发也很简洁，但同时就会损失灵活性。设计通用性和灵活性本来就是两个方向，跟复杂度一起构成一个不可能三角。
打个比方，轿车的设计都是基于铺装路面这个场景的，一般来说，这也是正确的，毕竟使用场景95%都是在铺装路面上跑。同时带来的好处就是舒适、操控好、省油。如果有用户需要应对复杂的路况，虽然这种路况很少，只占了5%，但是轿车的底盘就是没法过去。LangGraph这种框架就像设计跑在铺装路面上的轿车，5%的烂路过不去，使用LangGraph去适应烂路，难度无异于把轿车改造成越野车。
很火的开源AI应用项目Dify，上个月已经公告，把LangChain从他们的项目中移除。对于Dify这种相对成熟项目来说，自己实现一套架构应该也不是什么难事。这里可能还有一个原因，LangChain破坏性更新频繁，适应起来比较耗精力。
总的来说，LangChain和LangGraph还是非常优秀的项目，LCEL、动态配置的这些设计非常好。对于AI应用项目启动来说，确实可以节省不少时间，还是很推荐使用。

---

欢迎光临 链载Ai (http://www.lianzai.com/)

Powered by Discuz! X3.5