当医疗AI遇上多Agent协作，一个看似简单的病历纪要生成需求，竟暗藏技术选型与合规布局的双重挑战。从单模型硬扛到多Agent分工，从Dify快速验证到LangGraph核心自研，这篇文章揭秘了医疗AI产品从架构设计到落地部署的全链路思考，尤其值得关注的是其中关于数据合规、失败兜底与人工干预的关键设计。

接了个需求，看着简单：用户上传病历资料，系统自动生成一份诊后纪要。

资料有三种形态：图片格式的病历单、PDF 或 Word 文档、医患沟通的录音。系统要先认出这三类东西，把里面的内容都提出来，再按规定的模块和格式整合成纪要。

我不是技术出身。过去对“Agent”“模型路由”“LangGraph”这些词，基本是听过、点头、其实没懂。这次被这个需求逼着从头捋了一遍，反而捋清楚了。下面是这段折腾的过程，给和我一样、不写代码但要做 AI 产品的同行看。中间有几处我先想错、后来才掰过来的地方，我没藏。

我最初的想法很朴素：找一个最强的大模型，东西丢进去，让它全包了。

把这想法跟做技术的朋友一说，他没否定，只问了一句：“图片识别、录音转写、文字推理整合，这三件事，你确定一个模型每样都做得最好？”

我答不上来。后面所有的事，都是从这句话开始往下走的。

多 Agent 协作，到底是什么

先搞懂那个被反复提到的词。

网上的解释都很绕。我是靠一个很土的类比想通的：把它想成一个产品团队在干活。

一个复杂项目，你不会让一个人从调研、原型、PRD、测试一路单干到底。你会拆：调研给 A，原型给 B，文档给 C，最后你这个负责人把大家的产出收回来拼成方案。多 Agent 就是这个意思——一个主 Agent 做协调，把活拆开分给几个各管一摊的子 Agent，每个子 Agent 有自己独立的工作记忆，干完把结论交回来，主 Agent 再整合。

放到我这个需求里，几乎是天然契合：

• 一个 Agent 专门啃图片病历单；
• 一个 Agent 专门处理 PDF/Word；
• 一个 Agent 专门转写录音；
• 这三件事互不依赖，可以同时干；
• 等三份结果都回来，再交给一个汇总 Agent 按规定格式写纪要；
• 最后我特意加了一个校验 Agent，拿写好的纪要去对照原始资料查错查漏。

这里有个细节想多说一句，校验为什么要单拎一个 Agent，而不是让汇总那个自己检查自己？因为医疗场景错一个字代价都很大，自己写自己审是有盲区的，跟你自己写的方案自己永远挑不出毛病一样。让一个独立的角色、最好换个模型去挑刺，才靠谱。

多 Agent 的好处，我自己总结是三点：能并行的同时跑，所以快；每个 Agent 只揣自己那摊信息，主线不会被一堆中间过程撑爆，所以省；交叉检查，所以少出错。

缺点也得说清楚，不然就是吹。子 Agent 之间是靠交代办事的，你指令说不清它就跑偏。它给你的“总结”是它打算做的，不一定等于实际做对了，尤其涉及内容必须复核。强依赖的活别硬并行——汇总必须等三路抽取都回来，这步快不了。多个 Agent 多份调用，成本也更高。

想清楚这些，我才接受了这个需求不该用单模型硬扛。

一个模型，还是多个模型

接受了多 Agent，新问题马上来了：这些 Agent 背后，是同一个模型，还是不同模型？

先搞懂一个比喻——插槽。

一个 Agent 的职责是固定的（它是干 OCR 的还是干汇总的），但它背后接哪个模型，是一个可以替换的位置，像电脑上的内存插槽、USB 口。换模型不用重写这个 Agent，改个配置就行。

想通插槽，按模型强项分工这件事就顺下来了。朋友给我举的例子很直白：有的模型在图像识别和 OCR 上更强，有的在推理和长文本整合上更强。既然 Agent 背后的模型是可换的插槽，那我完全可以让每个 Agent 接它最擅长的那个：图片病历单接视觉强的，录音转写接专门的语音模型，汇总成纪要接推理强的，校验那一路故意换一个跟汇总不同的。

这套“按任务类型决定调哪个模型”的机制，叫模型路由。说穿了不神秘，就是一个调度员：来了个任务，先看它什么类型，按一张事先定好的对照表把活派给对的模型，再把模型吐出来的东西收拾成统一格式交给下一棒。

到这我才回过味来，朋友那句反问的潜台词是：别迷信单一最强模型，让专业的模型干专业的事。

代价当然有。你从一个调用者，变成了一个集成方——要管多套接口，要让不同模型吐出来的东西能对得上，要处理某家挂了怎么办。但对这个需求来说，这个代价值得付。

那些我差点踩进去的坑

真正交学费的（还好只是认知上的），是选型这一段。

Dify 还是 LangGraph。 我先接触的是 Dify，拖拖拽拽就能搭流程，一度以为用它做后端得了。后来弄明白两件事。

第一，Dify 和 LangGraph 不是一个层面的东西。Dify 是可视化低代码平台，拖拽配置，出 MVP 快，产品运营也能上手；LangGraph 是代码框架，要写 Python，门槛高，但逻辑随便定制、复杂流程扛得住、代码就是自己的资产。思路相似，形态完全不一样。

第二，也是我差点想当然的地方：Dify 能不能直接当一个 To B 产品的后端，扛大流量？别指望。它适合 MVP、中小流量、内部工具。真要高并发商用，核心链路还是得代码化，Dify 单独扛不住大流量，而且核心逻辑长期绑在第三方平台上不是好事。

所以我给自己定了分阶段：早期用 Dify 快速验证产品到底成不成立，别一上来就啃代码；一旦核心链路定型、对准确性和流量要求上来了，把核心识别加汇总加校验那条链路用 LangGraph 代码化收回来。两者可以共存一段，核心迟早要收口。

顺带说一句，LangGraph 要写代码这事没把我劝退——这种框架代码可以让 AI 帮我写骨架，我描述清楚流程，工程师在上面改，这条路走得通。

用不用 API 中转站。 像硅基流动、OpenRouter 这类聚合中转站，一个 key 接几十个模型，切换模型改一行配置，确实方便。我差点就决定全用它。

把我拽住的是医疗数据合规这条线。

病历是敏感个人信息。走第三方中转站，意味着这些内容要经过它再转一道手，这在合规上是个硬伤。我后来想明白的取舍是：不碰真实病历的实验、模型选型对比，用中转站没问题，方便；一旦涉及真实病历内容，比如 OCR、转写、含病历的汇总，别图省事走公共中转站，要么直连有合规资质的官方接口，要么敏感环节本地部署开源模型，数据不出自己的服务器。

我还纠结过：直连官方 API，数据不也上传给模型厂商了吗，有啥区别？区别在于，直连只过一家、通常有数据不用于训练的合规承诺；经过中转站是多了一个第三方环节，风险面更大。要隐私最强，就本地部署开源模型，代价是自己买算力、自己运维，专业能力通常还不如头部闭源模型。最后我倾向混合：敏感环节本地或直连合规接口，非敏感环节用 API。

这一段让我记住一句话：做医疗 AI，合规是从架构第一笔就要画进去的约束，不是做完再补的功能。

怎么让它别翻车

方案能跑通不算本事，跑挂了能兜住才算。这部分我想得最久。

先说 Fallback。这个词我以前总听不懂，这次算搞清了。它就是兜底回退：主的那个失败了，自动切到备用的继续，用户无感。配置上就是给一个优先级列表——主模型、备用模型一、备用模型二，主的超时或报错就自动试下一个。模型挂了切模型，某家限流切另一家，都靠它。

但医疗场景我加了个限制：汇总那一环的备用模型不能随便切，得是能力对得上、而且验证过的，切完照样要人工复核。不能为了系统别停就让它随便换个模型瞎写。

把路由、重试、降级串起来，逻辑就三层：按任务类型查表选模型，同一个模型失败了重试几次，还不行换列表里下一个，全挂了转人工。

重点说转人工。我一开始把它想得太简单，以为就是报错喊人来弄。后来想清楚，转人工得按失败原因分流，走不同的路。

第一种，内容问题——某份资料太糊、录音太吵、缺页，但系统是好的。这时候不该让 AI 硬猜，而是进一个人工工作台，标清楚哪份资料、什么原因失败，业务人员只补失败的那一段，不是整篇重写，把人工补的内容回填进和 AI 一样的格式，系统拿“AI 成功的部分加人工补的部分”继续往下汇总。

第二种，技术问题——模型全挂、系统报错，但数据本身没毛病。这时候是告警给技术，任务挂起但不丢已上传资料和已完成的中间结果，技术修好后从断点重试，只重跑失败那环，不全流程重来。

第三种，汇总或校验出问题——抽取都成功了，但纪要生成失败，或者校验 Agent 发现可能有编造、有重大漏项。这一种，医疗场景我主张不让系统自动重写，直接把已抽取的结构化内容、AI 草稿、校验发现的问题清单一起推给医生，人工在草稿基础上审校定稿，不是从零写。

支撑这三条路的，有两个东西必须做：一个人工工作台，列出待处理任务、失败环节、失败原因、原件入口、可编辑框；一个断点续跑机制，成功的环节结果存下来，人工补完接着跑。还有一条铁律，医疗场景必须守：普通环节可以自动降级，涉及医学结论的环节失败一律转人工，绝不让系统猜。

落地路线与避坑清单

把这一整套捋顺之后，我给自己画了一张落地路线，分三个阶段走，不贪快也不一步到位。

第一阶段是验证。用 Dify 把流程搭起来跑通 demo，只用非敏感的测试数据，目的就一个——验证这个产品到底成不成立、模型选型哪个靠谱。这个阶段别碰真实病历，别上来就啃代码。

第二阶段是核心自研。产品价值验证过了，把核心的抽取加汇总加校验链路用 LangGraph 代码化收回自己手里，敏感环节直连合规接口或本地部署，把统一的中间数据结构、模型路由表、重试降级兜底这层搭起来。这阶段决定产品上限。

第三阶段是商用强化。补全审计留痕，做成本归因——哪个用户、哪个功能花了多少钱，这是一个不复杂的内部后台，本质是调用日志表加统计页；做私有化和合规部署，把高并发扛起来。

最后，把我这一路差点踩进去的坑列成清单，给同行省点时间。

• 一，别迷信一个最强模型全包。不同模型强项不同，该分工就分工，这是这类需求的正解，不是过度设计。
• 二，概念先打比方再较真。Agent 想成团队分工，模型想成可换的插槽，路由想成调度员——先把直觉建起来再抠细节，比硬啃定义快。
• 三，合规从第一笔架构图就画进去。医疗数据走不走第三方，这是架构约束，不是后期补丁，想明白再动手。
• 四，Dify 用来验证，不要指望它扛商用大流量。分阶段，核心迟早要代码化收口。
• 五，能用确定的代码规则解决的，别动用大模型。判断文件是图还是音，看后缀两行代码就行，没必要花钱花时间让模型猜，又慢又贵又不稳。
• 六，兜底要分层，转人工要分流。技术问题修复重试，内容问题人工补缺失片段，医学结论失败医生审校定稿。配套是人工工作台加断点续跑，成功的环节绝不重跑。
• 七，涉及医学结论，失败一律转人工，不让系统猜。这条没有例外。
• 八，代码不用自己硬写。路由兜底封装、LangGraph 骨架、成本看板这些，描述清楚是可以让 AI 帮你产出骨架的，你和工程师在上面改。不懂代码，不等于做不了 AI 产品的架构判断。

这个需求到现在还没上线。但走完这一圈，我最大的收获不是学会了多 Agent，而是想明白一件事：作为不写代码的产品经理，我们不需要会实现，但必须看得懂取舍。模型怎么分工、要不要中转站、合规这条线划在哪、失败了怎么兜，这些没有一个是纯技术问题，全是产品判断。技术能帮你把方案写出来，但该怎么权衡，得你自己想清楚。

希望我这趟折腾，能帮你少绕点路。