LangGraph多智能体实战：从零构建医疗Agent系统

最近跟几个做大模型落地的朋友聊天，发现一个特别有意思的现象——大家都在说Agent、说智能体，但真正能把一个多智能体系统从零搭起来跑通的，其实没几个。今天正好请到了在医疗行业做过多Agent项目的专家，咱们就拿这个真实案例来聊聊，企业级Agent到底是怎么回事。 对，你说的这个现象特别真实。其实很多人对Agent的理解还停留在一个比较表面的层次。你看现在各种平台上的所谓'AI智能体'，比如豆包上那些，本质上就是给大模型套了一层人格设定——你是一个医生、你是一个律师，然后按这个角色来聊天。但严格来讲，这根本算不上真正的Agent。 嗯，那在你看来，真正的Agent和这种'套壳聊天机器人'之间的分界线在哪？ 核心就三个能力。第一是独立思考，它得能根据上下文自己判断下一步该干嘛；第二是执行能力，能调用工具、访问外部系统去完成具体任务；第三是问题解决能力，能独立把一个业务问题给解决掉，而不是简单地你问我答。你可以这么理解——普通聊天机器人像一个只会背课本的学生，而真正的Agent更像一个能独立出诊的医生，会问诊、会开检查单、会根据结果调整方案。 这个类比特别好。那你们做的医疗项目里，为什么要用多个Agent而不是一个超级Agent搞定所有事？ 你想啊，一个完整的诊疗流程涉及好多环节——问诊收集症状、分析病情做诊断、生成治疗方案开处方、后续随访管理。每个环节需要的专业知识和工具都不一样。你让一个Agent又当问诊医生又当药剂师又当随访护士，它的Prompt会复杂到不可控。所以我们把它拆成了问诊Agent、诊断Agent、处方Agent、随访Agent，各司其职，又紧密协同。这其实跟现实中医院的分工是一个道理。 明白了，那这些Agent之间怎么协调呢？我知道你们用的是LangGraph，能不能讲讲为什么选它？ 好，这个得从LangChain说起。LangChain大家都知道，大模型应用开发的主流框架，但它本身是链式调用的模式——A做完给B，B做完给C，像一条流水线。可是真实的业务场景哪有这么线性？比如诊断Agent分析完，可能需要回到问诊Agent补充信息，也可能直接走处方，还可能几个Agent并行处理。LangGraph就是解决这个问题的，它把工作流抽象成有向图，每个节点是一个处理步骤，边是流转逻辑。图结构天然支持分支、循环、并行，比线性Chain灵活太多了。 所以LangGraph管的是流程编排。那光有流程还不够吧？医疗领域的专业知识从哪来？ 对，这就要说到整个技术组合了。其实是三驾马车：LangGraph管流程编排，RAG管领域知识，MCP管外部工具调用。RAG就是让Agent能访问企业私有的知识库，比如最新的诊疗指南、药物说明书这些。你不能指望大模型的通用知识来处理专业医疗问题，那太危险了。MCP呢，是标准化Agent跟外部系统交互的协议，比如查电子病历、调检验结果，都得通过它。三者拼在一起，才能撑起一个真正可用的系统。 你看，技术栈讲清楚了，但我特别想聊一个你之前提到的观点——你说在这种项目里，需求分析和架构设计占了百分之七八十的工作量？这个比例是不是有点夸张了？ 一点都不夸张，甚至在大模型时代这个比例还在加大。你想想，现在AI编程工具已经能帮你写大量代码了，编码实现的门槛在快速降低。但有一件事AI替代不了——把控需求。你不可能跟大模型说一句'帮我做个医疗多智能体项目'就完事了。你得想清楚每个Agent的职责边界在哪、它们之间数据怎么流转、出了异常怎么降级、系统后续怎么扩展。这些问题想不清楚，代码写得再漂亮也是白搭。 嗯，这让我想到一个说法——写代码的含金量在下降，但设计系统的含金量在上升。 完全同意。而且我还想补充一点，学LangGraph这类框架，千万别只停留在背API的层面。更值得花时间的是理解它背后的设计逻辑。比如为什么用图结构？因为复杂业务流程本身就不是线性的。为什么需要状态管理？因为多Agent协作必须共享上下文。搞懂了这些'为什么'，换一个框架你也能很快上手，遇到新场景也能做出靠谱的技术选型。 说到医疗场景，这个领域做多Agent有没有什么特别需要注意的坑？ 坑还真不少。首先是知识库，医学知识更新特别快，而且专业性极强，RAG系统的检索准确性直接决定了Agent的输出质量，这个要是不行，后面全白费。其次是流程的严谨性，医疗场景对错误的容忍度几乎为零，Agent之间的协作流程必须经过严格验证，不能有模糊地带。还有合规性，医疗数据的隐私保护是红线，这个没得商量。所以医疗虽然是多Agent落地的典型场景，但也是最难做好的场景之一。 那对于想入门这个方向的开发者，你有什么实用建议？比如很多Java开发者就纠结要不要转Python。 其实完全不用焦虑语言问题，编程思想是相通的。真正需要投入精力的是三个核心能力：Prompt工程、RAG架构设计、Agent编排思维。这些是跨语言通用的硬本事。然后最重要的一点——一定要动手做项目。光看文章、看演示和自己真正走一遍从需求分析到系统构建的完整流程，差距非常大。哪怕没有真实的企业项目，也要自己模拟一个场景练手。 所以总结一下，企业级多智能体系统的构建，本质上是技术、业务、架构三位一体的事情。框架提供了技术底座，但真正决定项目成败的，是你对业务的理解和对架构的设计能力。 对，说到底，在大模型时代，掌握'做什么'和'为什么这样做'的能力，远比'怎么写代码'更关键。与其追着每个新框架的API跑，不如沉下心来把需求分析、架构设计这些底层逻辑吃透。这才是长期不贬值的核心竞争力。 说得好。技术在变，但解决问题的思维方式不会过时。希望今天这期能帮大家建立起对企业级Agent开发的完整认知，少走一些弯路。