AI 给肿瘤病人开处方，谁来兜底？
前两天刷 HuggingFace，看到一个叫 OncoAgent 的项目。lablab.ai 和 AMD 合办的黑客松参赛作品，做肿瘤临床决策支持系统。
乍一看标题，我以为又是一个”用大模型辅助诊断”的 demo。这类东西太多了，大多数就是套个 RAG，灌几篇指南进去，跑个漂亮 demo，完事。
但往下看了几页，我停下来了。这个项目做了几件不太寻常的事。
先说一个场景
Section titled “先说一个场景”假设一个 Stage IV 胰腺癌患者，带着 KRAS 和 BRCA2 双突变来找你看病。你输入这些信息，OncoAgent 的路由模块给这个病例打了 0.80 分（满分 1.0），直接踢给 27B 深度推理模型处理。
模型很快给了治疗建议。但它没有直接推到你面前。
先过了一道 Critic。这个 Critic 不是另一个大模型，是代码。三道检查：格式对不对、有没有踩安全红线（比如没引用指南就给剂量）、推荐有没有被检索到的文献真正支持。
有一条没过，反馈打回 Specialist，重来。最多两次。两次都没过，系统不硬撑，直接弹出一句：「所提供的指南中没有结论性信息。」
就这句话。不编，不猜，不硬给一个看起来合理但没依据的答案。
等一下——这不是正常操作吗？AI 给不出靠谱答案就该说不知道啊。
但你去看市面上大多数医疗 AI 产品，做不到这一点。它们的”安全机制”通常是让另一个大模型来审前一个大模型的输出。用 AI 审 AI，用不确定审不确定。出问题的概率比你想象的高。
OncoAgent 的做法不一样：让 AI 做脏活（检索、推理、生成），让代码守底线（格式校验、安全扫描、证据核验）。
这个分工才是整个系统最值钱的地方。
四层防线，没有一层是 AI
Section titled “四层防线，没有一层是 AI”OncoAgent 的安全架构是四层独立防线，任何一层单独崩了都不致命：
第一层：检索关卡。 每条检索结果过一个余弦距离阈值（0.10）。低于这个阈值的直接丢弃，系统返回「无结论」。简单粗暴，但有效——它把那些看起来相关但实际跑偏的文献在第一道门就拦住了。
第二层：置信度门控。 RAG 置信度低于 0.3 的输出直接拦截。不给模型任何机会在低质量检索结果上胡说八道。
第三层：Reflexion 安全循环。 就是上面说的 Critic 节点——格式检查、安全检查、推理一致性检查。关键设计：Critic 是确定性代码，不是 LLM。这意味着它不会被 prompt injection 攻破，不会因为上下文窗口溢出而漏检，不会”心情好就放水”。
第四层：人工闸门。 所有高复杂病例（Tier 2）和低置信度输出，必须经过临床医生确认才能继续。系统在这里暂停，等医生介入。
四层里没有一层依赖”AI 自己管好自己”。
这让我想起软件工程里的一个老原则：Don’t trust, verify. 你不会因为代码”看起来对”就上线，你会写测试、做 code review、设 CI 门禁。OncoAgent 把同样的思路搬到了医疗 AI 里——不信任模型的输出，用工程手段逐条验证。
有意思的是，项目引用了四个经典架构模式：Claude Code 的确定性安全骨架、Hermes Agent 的会话隔离、Corrective RAG 的文档相关性评分、Reflexion 的自我纠错循环。它不是从零发明，是把已验证的工程模式组合到了医疗场景里。这种”组装”能力，比发明新算法更接近真实工程。
数据不出楼，不是口号
Section titled “数据不出楼，不是口号”OncoAgent 有一个设计选择让我觉得它真的想清楚了：全流程本地化。
不只是推理本地化——训练也跑在一块 AMD MI300X 上。192GB HBM3 显存，QLoRA 4-bit 量化，26 万条样本微调两个模型（9B + 27B），总共 50 分钟跑完。
50 分钟。
他们最初估计要 5 小时。通过 Unsloth 的 Triton 内核优化 + 序列打包（sequence packing），实际训练时间压缩到原来的六分之一。合成数据生成速度更夸张：每小时 6800 条，比调 API 快 56 倍。
为什么这件事重要？因为如果训练必须依赖云 API，就意味着患者数据要离开医院。在美国有 HIPAA，在欧洲有 GDPR，在中国有《个人信息保护法》。数据出楼不是技术问题是法律问题。很多医院不是不想用 AI，是合规不允许。
OncoAgent 的方案：一块 MI300X 放在医院机房里，训练、推理、RAG、UI 全跑在上面。知识库用本地 ChromaDB，不用任何云服务。患者信息在进 LLM 之前就被专门的脱敏节点替换成占位符，原文直接丢掉。
这不是”也可以本地部署”的附加选项，是从架构设计开始就围绕本地化构建的。RAG 用的嵌入模型（S-PubMedBert）选的是能在本地跑的，向量数据库选的是不依赖云的，训练框架选的是 ROCm 原生支持的。每一层都在回答同一个问题：如果这台机器是医院唯一能用的计算资源，系统还能跑吗？
答案是能。
OncoAgent 是 lablab.ai 和 AMD 联合黑客松的作品。
你可能会想：比赛项目能有多靠谱？
但这个项目的工程成熟度让我重新想了想”黑客松产出”这个标签。
它的训练语料叫 OncoCoT，26.6 万条，包含约 8.5 万条真实临床案例（来自 PMC-Patients 和 Asclepius）、约 9.7 万条合成案例。合成数据用 Qwen 3.6-27B 生成，拒绝率只有 0.65%——也就是说生成质量经过筛选。
它的 RAG 管道不是”把 PDF 扔进向量数据库”。77 份 NCCN 和 ESMO 指南 PDF，用 PyMuPDF 做块级结构化解析（保留多栏临床文档的语义阅读顺序），正则清洗机构标识，排除面向患者的内容，最后用专门针对医学语义的嵌入模型建索引。检索分四步：宽召回→距离过滤→交叉编码器重排序→上下文裁剪。
它还发现了一个有趣的工程 bug：用 Qwen 3.5 做文档相关性评分时成功率是 0%，换成 Qwen 2.5 Instruct 后变成 100%。这不是调参能解决的问题，是模型版本间的行为差异。他们找到了，修了，记了。
这种迭代深度在黑客松项目里不常见。大多数比赛作品是”能跑就行”。OncoAgent 更像是”先让它能跑，再让它不能跑错”。
开源的另一层意思
Section titled “开源的另一层意思”OncoAgent 承诺代码、模型权重和训练语料全部开源。
这意味着什么？医院可以审计每一条推理路径，看模型的每个输出依据了哪段指南。可以拿自己的数据重新训练。可以在自己的硬件上跑，不依赖任何第三方服务。
这跟商业医疗 AI 是两条路。商业产品通常是黑盒——你不知道它检索了什么，不知道它的安全检查覆盖了什么边界，不知道它什么时候会悄悄调用外部 API。你只能信任厂商的承诺。
开源不等于安全，但开源让验证成为可能。
OncoAgent 这个项目让我意识到一件事：AI 医疗的真正瓶颈不在模型有多聪明，在系统设计有多严密。
一个 27B 参数的模型，放在一个没有安全骨架的系统里，就是一个定时炸弹。放在 OncoAgent 这种四层防线、确定性校验、强制人工介入的系统里，它才有可能成为医生的工具而不是威胁。
模型是引擎，架构是刹车。没有好刹车的车，马力越大越危险。
这个项目目前还有局限——36% 的训练数据是合成的，还没经过执业肿瘤医生大规模验证；指南主要是英文的 NCCN，ESMO 和非英文语料还没覆盖。但方向是对的。
在 AI 医疗这个赛道上，方向对，比跑得快重要。
你在工作中用过 AI 做医疗或健康相关的判断吗？或者你见过哪些”AI 给建议但没人兜底”的场景？
Máximo López Chenlo. OncoAgent: A Dual-Tier Multi-Agent Framework for Privacy-Preserving Oncology Clinical Decision Support. Hugging Face Blog / lablab-ai-amd-developer-hackathon. https://huggingface.co/blog/lablab-ai-amd-developer-hackathon/oncoagent-official-paper