医疗AI面临大模型不确定性与医疗确定性之间的矛盾。郭春晓提出医疗AI五大挑战，强调直接使用通用大模型不可行，需转变研发范式。蚂蚁阿福Agent采用Agent研发范式，以天为单位迭代，以Benchmark驱动，通过Prompt/RAG/模型切换实现高效研发。架构上分层设计，Agent环境独立，适应业务变化。医疗场景检索方案迭代，融合关键词、向量检索和知识图谱。解决大模型长期记忆缺失问题，构建结构化记忆机制。建立多维度评测体系，实现模型快速迭代与质量保证。对技术团队启发：Agent研发需严格工程规范，代码数据化适应业务变化，长期记忆依赖数据工程。
本文整理自QCon北京2026郭春晓《蚂蚁阿福Agent：医疗研发范式与实践》技术分享，通过AI音视频转录总结工具**Ai好记（aihaoji.com）**进行视频转文字整理，以下为精炼整理后的会议笔记内容。
当大模型遇上医疗：一场确定性与非确定性的博弈
医疗 AI 有个天然矛盾——医疗要求绝对的确定性，但大模型天生就有不确定性。
想象一下：同一个病人问同一个症状，今天和明天得到的回答如果不一样，这在医疗场景里是不可接受的。更别说诊断出错可能带来的严重后果。
郭春晓在分享中开门见山，列出了医疗 AI 面临的五大特有挑战：
专业性强、容错率极低
：错误答案可能导致严重后果
完整的循证逻辑体系
：诊断必须依据指南和教科书，不能"随心所欲"
大模型非确定性 vs 医疗确定性
：同一病症多次诊断必须保持一致性
大模型长期记忆缺失
：慢性病诊断需要结合长期病史，但对话模型记不住
严格的风险合规要求
：涉及大量隐私数据，心理问题等高敏感场景还需要特定干预机制
这些挑战决定了：直接拿通用大模型做医疗问答是不行的。必须从研发范式本身开始改变。
三条研发范式的演进：从代码驱动到Agent驱动
郭春晓把研发范式的演进分成了三个阶段，这个框架其实对其他领域的 AI 应用也有启发：
传统业务研发范式（代码驱动）
需求→设计→开发→测试→上线，周期以周或月计。适合确定性高的业务场景，但迭代太慢，完全跟不上 AI 时代的变化速度。
搜推研发范式（数据驱动）
一周迭代1-2次，通过 A/B Test 驱动优化。研发聚焦特征工程和模型训练，适合效果可量化的场景。比传统范式快，但还不够。
Agent研发范式（Benchmark驱动）
这是蚂蚁阿福选择的路径，核心特征有三个：
以天为单位的迭代效率
——比搜推又快了数倍
Benchmark 作为核心牵引
——初期没有评测集走了不少弯路，后来意识到评测集才是"北极星"
从代码实现到 Prompt/RAG/模型切换
——研发模式从根本上变了，核心工作不再是写代码，而是调 prompt、换模型、加 RAG
郭春晓特别强调了一个概念叫“代码数据化”——把过去写在代码里的规则，变成可配置的数据资产。这个转变听起来简单，但影响深远。
支撑Agent范式的分层架构
蚂蚁阿福的架构设计很有层次感，可以分成四层来看：
- 底层数据层：医疗指南、权威网页、医生医院等业务数据，再加上 post-train 数据。数据质量在这里是生命线。
- 模型与Agent层：自研模型 + Agentic model，配合 Agent 环境（Agent Env）和工具环境（Tool Env）。
- 应用层：直接面向用户的各种 Agent 应用。
- 治理与运营层：模型评测、安全合规、运营监控，这是医疗场景下的"基础设施"。
这个架构最值得关注的设计是：Agent 环境被抽象成独立的层，而不是跟业务逻辑强耦合。这样业务变化时，Agent 可以做适配调整，而不需要重写整个系统。
医疗场景下的检索方案迭代
郭春晓专门花了不少篇幅讲检索方案的演进，因为在医疗场景下，检索质量的差异直接决定了回答的质量。
第一步：从传统检索到向量检索
传统的关键词检索在医疗场景下表现很差——"高血压"和"高血压患者"明明密切相关，但关键词匹配就是接不上。切换到向量检索后，语义匹配能力有了质的提升。
第二步：从向量检索到知识图谱赋能
向量检索只能告诉你"这段文本跟查询相关"，但说不清"为什么相关"。引入知识图谱后，可以建立实体之间的关联关系，比如药品和治疗方案之间的因果关系、并发症之间的连锁关系等。
第三步：多路径检索融合
不是简单替代，而是把关键词检索、向量检索、图谱检索三条路径的结果做融合。不同的查询用不同的路径——比如查药品说明书，关键词检索可能更直接；查症状鉴别诊断，知识图谱的效果更好。
医疗"记忆"问题的解法
慢性病管理是医疗 AI 最难也最需要的场景——病人可能反复咨询同一个病症，但每次就诊间隔几个月甚至几年。大模型记不住之前聊过什么，这是 Agent 研发范式必须解决的问题。
蚂蚁阿福的解法是构建结构化的长期记忆机制：
- 把每次对话中的关键信息（症状描述、用药记录、医生建议）抽成结构化数据
- 存储到独立的记忆库（类似 RAG 中的向量库，但做了医疗场景的定制化）
- 下次对话时自动检索相关记忆，拼到上下文中
说实话，这个方案从技术上并不复杂，但落地的难点在于：医疗记忆的抽取得格外谨慎。漏掉一条关键病史，可能导致完全不同的诊断方向。
Agent治理：当模型不断迭代如何保证质量？
郭春晓提到一个非常现实的痛点：模型版本更新太频繁了。可能这周测得好好的模型，下周新版本就"变笨"了。
蚂蚁阿福的做法是建立完善的评测体系：
多维度评测集
：覆盖准确率、一致性、安全性等多个维度
自动回归测试
：每次模型切换或 Prompt 修改后，自动跑全量评测
Badcase 驱动的快速闭环
：生产环境中发现的 Badcase，走最短路径反馈到评测集和训练数据中
这套体系的核心理念是：不要让生产环境踩过的坑再踩第二次。每个 Badcase 都应该变成评测集的一部分。
对技术团队的启发
蚂蚁阿福在医疗 AI 上的实践经验，有几点特别值得做垂直领域 AI 的团队参考：
Agent 研发范式不等于放弃工程规范
——正好相反，Benchmark 驱动意味着需要更严格的评测体系
"代码数据化"是让 AI 应用适应业务变化的关键
——写死的逻辑越多，AI 就越难适配
长期记忆不是技术问题，是数据工程问题
——难点在于怎么抽、怎么存、怎么保证质量
FAQ
Q：医疗 AI 的错误率要求有多严格？
A：传统医疗场景的错误容忍度接近零。大模型虽然在逐步提升，但在涉及诊断建议的场景下，目前更多是辅助角色，最终决策仍需要医生确认。
Q：Agent 研发范式中，代码量真的减少了吗？
A：不是代码量减少了，是代码的能力密度提升了。以前几千行业务逻辑做的事情，现在可能用一个 Prompt 加几条 RAG 配置就搞定了。但框架代码、评测代码、治理代码的量反而增加了。
Q：知识图谱和向量检索在实际场景中怎么选？
A：不是二选一，是多路融合。知识图谱擅长实体关系和因果推理，向量检索擅长语义匹配。医疗场景下两者都需要，具体看查询类型来决定权重。
假如你从2026年开始学大模型，按这个步骤走准能稳步进阶。
接下来告诉你一条最快的邪修路线，
3个月即可成为模型大师，薪资直接起飞。
阶段1:大模型基础
阶段2:RAG应用开发工程
阶段3:大模型Agent应用架构
阶段4:大模型微调与私有化部署
配套文档资源+全套AI 大模型 学习资料，朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】👇👇
