在AI技术蓬勃发展的当下，医疗Agent作为一款嵌入医院主页的智能模块，本应为患者提供高效便捷的咨询和问诊服务，但许多产品却面临用户使用率低下的困境。本文作者通过亲身参与一款医疗Agent产品的研发与落地，从0到1复盘了其在全国近1000家医院上线的全过程。

最近参与的Agent产品已在全国近1000家医院上线啦～（撒花）

在调研、试点、落地的过程中，我们踩了很多坑，也积累了不少经验。写下这些，希望能给正在做AI落地的朋友们一些参考。

备注：该Agent是嵌入在各医院主页中的模块，患者对该医院有任何问题，例如“有没有急诊？能租赁轮椅吗？小孩肚子痛挂什么科”等都可以进行询问，并直接在线问诊或挂号。

1.作为AI产品经理，找到真实的用户需求比技术理解力更重要

一开始我们没想着做AI Agent，只是后台频繁出现的问题引起了注意：

“怀孕四个月甲亢怎么办？”

“抽血在哪一楼？”

“有无痛胃镜吗？”

这些问题看起来很简单，但几乎没人答得上来。不是医生不专业，而是这些信息太零散，太长尾。很多答案藏在医院的HIS系统、公众号、甚至纸质易拉宝上，用户不是不愿查，是根本不知道去哪查。

因此我们思考：如果连医院工作人员都答不清，那有没有可能，AI能成为那个“统一回答者”？我们手上其实有不少底牌：医疗知识图谱、医生问答数据、医院服务信息和号源……粗略评估，覆盖大多数场景没问题。

但我们也没上来就动手，而是先看了下市场上有没有人做过：平台型产品（康康、安诊儿）偏健康咨询，服务信息回答不了；垂类产品（讯飞晓医）重问诊，医院运营类问题几乎空白。

结论很明确：用户有需求，市场没人做，我们就决定试一试。

2.MVP思路验证需求，不用一开始就All in模型架构

我们并没有一上来就开干，而是利用MVP产品思维，用最小投入，在最短时间，验证最核心的用户价值后，才立项。

当时，秘塔AI搜索已有知识库上传能力，因此我将几份医院相关信息上传到秘塔知识库，让秘塔基于知识库回答，完成初步MVP方案。

整个知识库搭建你们猜猜用了多久？

10分钟。

能在这么短时间内搭建一个MVP产品在以前是不敢想的，但现在有了各种AI产品的加持，不懂代码的我也可以分分钟搭建一个可用的产品。

搭建好后，我把这个医院AI万事通发给同事、用户体验，虽然略粗糙，甚至都没有Prompt来优化回答，他们依然觉得在获取医院信息上，提效了不少，因为这些信息原本需要他们自己去找公众号、小红书、找熟人问，甚至给医院打电话咨询的。

除了信息获取的效率更高了，有些用户甚至还想直接在MVP方案里找到合适的医生在线问诊、买药品，或者挂号。你说巧不巧，我们正好也有在线问诊医生、药品和号源，可以完美承接用户诉求。

验证了用户需求真实后，我们就开干了。

3.产品、运营、研发没有边界，谁会谁上

其实我们团队之前没有专门为AI项目立过项，大多是某个子功能需要大模型能力，适当引入大模型。而这次完全是基于大模型的产品，因此产品、运营、研发、测试团队也在项目中探索各自的工作边界和如何协同。

现在回看过来，大家除了完成自己的本职工作，多多少少都会“插手”其他职能的工作。例如：

• MVP方案是产品独立搭建的，完全无需研发参与；
• 运营会参与到写Prompt的工作中来，和产品、研发一起迭代workflow；
• 研发会参与到用户调研中，进行用户访谈和洞察提炼；
• 产品会直接写知识库结构，和研发一起完成知识库设计。

除了这些，大家也使出浑身解数来让这个产品更完美，运营甚至会跑郊区的医院，亲手拍下医院的公示牌，以验证大模型回复问题的准确性。虽然很辛苦，但大家都觉得值得。

4.不需要最好的模型，而是对的流程+对的模型

很多人以为做Agent就一定要用“最强的大模型”，比如GPT-4o，参数多、推理强、理解深。但在真实的工程实践中，我们并不需要最强的模型，而是最合适的位置上，用最合适的模型。

举个例子，在我们的Agent产品中，一个用户的提问，背后可能会依次触发这些模型：

【1】意图识别模型 → 判断患者意图。

这个模型的职责很明确：快速、稳定、低成本地判断患者是在问：症状挂什么科？楼层位置在哪？医院是否有停车场？此时，我们会选择响应快、成本低的模型，不需要多强的“思考力”，但必须稳、准、快的把意图分发到对应的工作流中。

【2】信息检索模型 → 找到医院信息、医生、号源。

这一部分对“准确性”要求极高，查错楼层、医生信息会直接误导用户。所以我们更依赖结构化数据库 + 检索能力，而不是纯靠生成模型自由发挥，能答对、答全、答准最重要。

【3】内容生成模型 → 给出清晰易懂的回答。

当检索到的信息结构化地返回后，我们需要一个模型来“润色”回答，让内容更口语化、亲和力强，符合医疗场景的语气。这里我们用了中等能力的大模型（不是参数最多的那种），但做了精细的Prompt设计，以保证回复内容“准确、简洁、友好”。

【4】安全审查模型 → 确保内容不出风险。

医疗是高度敏感的场景，模型不能乱推荐、不能瞎猜、不能打擦边球，因此还需要做内容过滤 + 安全规则审查。这部分模型必须加多重兜底机制，比如关键词过滤、白名单、灰度控制等。

所以，我们的Agent产品不是“塞一个大模型进去让它全盘接管”，而是我们作为指挥官，让对的模型，在对的节点，做对的事。

5.数据集和测评体系是落地Agent的生命线

在我们最初上线时，其实并没有投入太多时间在“测评体系”上。我们以为只要大模型能答对几个典型问题，效果就差不到哪儿去。

但事实是：我们踩坑了。

我们遇到过很多“看起来答了，其实没答对”的问题，细看背后，其实都是缺乏测评集覆盖导致的，例如：

用户问：“我胸闷3天了现在一直咳嗽怎么办？”

模型答：“建议拨打医院电话咨询”。

分析：这属于意图理解正确，但模型选择了保守拒答且回答冰冷，说明缺少SFT微调+人文关怀+兜底机制。

用户问：“我嗓子痛，顺便能打HPV疫苗吗？”

模型答：“建议您挂耳鼻喉科。”

分析：这属于用户有多个意图，但只回答了一个，说明模型缺乏多意图识别能力或缺少“主次信息判断”的机制。

后来我们意识到，必须建立系统性的测评方式：

【1】构建测评集。覆盖所有核心意图类型（症状问科室、问服务、问科普等）。

【2】拆分维度测评。每种意图下的问法要覆盖“规范问法”、“模糊问法”、“口语问法”、“单轮询问”、“多轮询问”等，甚至区分患者是老年、中年，还是儿童。

【3】精细标注预期输出。区分“正确 / 不完整 / 错位 / 胡编 / 拒答”等级。

【4】对错误做归因。到底是识别问题？检索不到？提示词没写好？语料覆盖不足？

有了这些系统测评，我们才能让模型从“能答”走向了“答得对、答得稳”。

6.医疗场景一定要SFT，否则风险不可控

在通用大模型性能强大的今天，我们一开始也有幻想：“模型已经很强了，说不定不用调教也能答得不错？”但当我们真正把 Agent 放进医疗场景里，才意识到：医疗，不是“说得像”，而是“必须对”。

不做 SFT（Supervised Fine-Tuning，监督微调）会遇到什么问题？

• 模型会推荐医院根本没有的科室，因为它从互联网上“想当然地胡编”；
• 患者说“我孕早期肚子痛”，它说“挂消化内科”，忽略了风险词“孕”；
• 模型偶尔输出“我建议您做××手术”，这是医疗禁区，普通模型完全没边界感。

这类问题极具隐蔽性，在 Demo 阶段也许看不出来，一旦上线就可能出医疗事故式舆情。所以我们后来做了什么？

• 自建了医疗问答数据集，人工标注 + 精调；
• 建立高风险关键词库，联合内容安全模型做多层过滤；
• 所有生成都限定在“回答服务信息 + 推荐问诊挂号”这类低风险任务内；
• 做多轮灰度测试，确保模型“宁愿不答，也不硬答”。

这次Agent项目，我最大的体会有两点：

第一，哪怕是做 AI 的产品经理，最重要的依然是，找到真实的用户需求。

不是卷模型参数、不是堆复杂框架，而是踏踏实实地观察用户、理解问题、验证需求。

第二，我彻底放下了对“大模型”的盲目崇拜。

AI不是魔法棒，它只是一个强大的工具。真正让产品落地的，从来都是：

• 真实的用户调研
• 系统的数据测评
• 一次次“答错了为什么”的复盘