一句话简介：科研平台正从"数据平台"走向"Agent 平台"，AI 原生不是给旧系统加个聊天框，而是把研究者的科研意图变成可执行、可验证、可复现的闭环。
作为医疗云原生架构师，最近在帮一家研究型医院做科研数据平台的架构评审，遇到了一个典型问题：AI 团队想给平台"加个聊天框"，让医生用自然语言问数据；可临床科研处要的不是"能问"，而是"这项研究能不能从头跑到尾、结论能不能被别人复现"。这两周行业里两件事正好凑到一起------医渡科技在 MAIC2026 第二届医学人工智能大会专场分享里，把临床科研产品的演进概括为"工具化→平台化→智能化→AI Native"，并直接说了一句"AI Native 不是给旧系统加一个聊天框"；9 月德适科技与香港理工大学共建的"通用人工智能与医学应用联合实验室"揭牌，首期四年聚焦"用智能体改进医疗 AI 研发流程"，提出"一底座、多智能体、万模型"，目前正在尝试让智能体去开发 5000 多项影像检测任务。方向已经很清楚了，但真到架构这一层，有三个取舍必须提前想明白。
一、验收口径要从"能答"改成"能跑完"
这一条如果一开始没定，后面所有工作都会跑偏。
1、先定义"什么算跑完一项研究"。对话式 AI 的验收是"答得像不像"，科研平台的验收应该是"能不能把一项研究从研究设想推到成果产出"。我们的做法是给平台定一条主验收线：以一个真实课题为样本，走完"文献与证据扫描→数据可行性探底→纳排与队列构建→数据清洗与抽取→统计分析→结果交付"全链路，任何一环需要人工接管都要记录并说明原因。跑不通的环节，就是架构上的缺口，而不是"模型不够大"。
2、把平台分层当成"责任分层"来设计。行业里比较成熟的拆法是六层：客户产品层、领域应用与流程层、共性智能能力层、模型服务与智能编排层、数据与 AI 基础平台层、安全合规与基础设施层。这个分层真正的价值不是好看，而是每一层都能回答"出了问题找谁"。我们评审时踩过的一个坑是：把"统计方法选择"这种需要专业判断的环节放在了共性智能能力层，结果临床统计师既不知道在哪改、也没法留痕，最后整个统计过程被绕过、回到本地 Excel 里手工做------平台于是退化成了一个贵一点的数据查询工具。
3、别把"能问"当"能用"。自然语言问数据是入口，不是能力。我们给平台的定位是：入口可以很轻（对话、表单、模板都行），但底下的每一步必须落成可执行、可验证、可复用的资产------脚本、参数、血缘、版本。否则一年后你会得到一堆"当时是这么算的、现在说不清"的历史结论。
二、数据底座：科研数据是"一次性消耗品"还是"源头活水"
这是决定平台能不能长期活下去的一节。
1、口径必须固化，而且要固化在 Agent 之前。统一标准要落到三样东西上：疾病定义、纳排规则、指标字典。行业里讲"把专病库建设沉淀为高质量数据集底座"，本质就是把过去每个课题各自一套口径，变成全院共享的一套标准。我们的经验是：口径不统一的时候上 Agent，等于在一个错的基础上加速犯错------Agent 会非常高效地把不干净的数据算出一个看起来很专业的结论。
2、质量门禁、评分和血缘要跟着数据一起走。数据从原始病历加工成科研资产，中间要留三样东西：处理脚本、质量报告、数据血缘。这三样缺一样，结论就无法复现。我们踩过的一个坑是：早期版本为了赶进度，让 Agent 直接读原始病历做抽取，中间过程没有留存，结果三个月后审稿人问"这个变量是怎么定义的"，团队没人答得上来，只能把整个数据集重做一遍。
3、目标不是"交付一个数据集"，而是"具备持续生产数据集的能力"。这是最容易被低估的一点。专病库项目的常见结局是：项目验收时交付了一批数据，之后没有新增、没有治理、没有复用，变成一次性的消耗品。正确的做法是把底座做成"源头活水"------标准固化、多源编排、全链路治理、质量评分、权限与脱敏贯穿，让同一批数据能反复为不同课题供数。判断标准很简单：第二个课题来的时候，需要重做的比例有多高。
三、多智能体协同：分工要拆开，"人回路"要放在对的位置
科研流程天然是分环节的，所以多 Agent 的分工比做一个全能 Agent 靠谱得多。
1、按科研链条分角色，不要做一个什么都会的 Agent。比较合理的拆法是：灵感与证据探索、数据处理、统计分析、论文撰写、投稿返修。每个角色只对自己那一段负责，输入输出用结构化契约连接。这样做的好处是每一段都能单独评测、单独替换、单独回退------如果全塞进一个 Agent，你既不知道它哪一步错了，也没法只升级其中一环。
2、人回路要放在"不可逆"和"对外"的节点上。不是所有步骤都需要医生确认，那样效率太低；但有三类必须卡住：纳排规则的最终确认、统计方法的选择、对外结论的表述。这三类一旦错了，返工成本是数量级的差别。我们的落地方式是在流程里做显式卡点，确认人、确认时间、确认内容一起留痕，事后可追溯"这个结论是谁拍板的"。
3、统计环节必须是"方法选择---可信执行---结果交付"的可复现闭环。科研场景里最忌讳的是让 Agent 直接给一个 p 值。我们的做法是：Agent 负责生成分析计划、生成可执行的脚本、跑出结果，但方法选择要落到方案里、脚本要留档、结果要能被第三方用同样数据重跑一遍。行业里讲的"自动生成分析计划、覆盖常规统计与因果推断、让方法选择和结果交付成为可复现闭环"，落点其实就是这句话。
4、最需要防的不是"答错"，而是"生成一篇看起来很规范的错论文"。这是科研场景里 AI 幻觉最危险的地方------文献引用格式工整、统计表格齐全、段落逻辑通顺，但数据、方法或结论有一处是编的。我们的防线有三层：引用必须能回溯到真实文献库条目、数据必须来自有血缘的数据集、结论必须能反查到产生它的脚本和参数。任何一层断链，这篇稿子就不能出平台。
四、算力与合规：科研训练和临床在线抢同一个池子，怎么办
这一节是最容易在真实医院里出事的地方。
1、算力配额和错峰要在架构里写死，不能靠人喊。研究型医院的算力池同时承载三类负载：临床在线的 AI 推理（门诊高峰必须稳）、科研训练与微调（可以排队）、回溯批处理（可以等）。我们的做法是先把优先级排清楚------临床在线永远优先，科研训练用夜间窗口跑批量任务，配额按"并发数 + 显存"双维度限制而不是只限卡数（只限卡数会被同一个卡上的显存吃满）。踩过的坑很典型：一个科研训练任务把生产库和算力都占住了，第二天门诊的 AI 初筛跟着变卡，临床科室直接投诉到院里。
2、数据不出院是底线，不是选项。科研数据同样是患者数据，受《医疗卫生机构数据安全和个人信息保护管理办法（试行）》这类文件约束，分类分级、最小必要、知情同意、出境安全评估这些要求都适用。架构上的落法是把数据留在院内封闭环境，需要跨机构协作时走隐私计算或沙箱，而不是把文件传出去；权限、脱敏、审计贯穿全链路，谁在什么时间访问了哪份数据要能回答得出来。
3、留痕要覆盖到"模型与脚本"这一级。临床场景的留痕通常到"谁看了这份病历"就够了；科研场景还要往前一步------这个结论是哪一版模型、哪一版脚本、哪一版指标字典跑出来的。因为平台会持续迭代，如果不记录版本，一年后没人说得清两个结论为什么不一样。
五、持续学习与版本治理：模型会变，证据链不能断
最后一节，是平台能不能长期被信任的关键。
1、持续学习要有版本和回退。循证证据在更新、医生在反馈、知识图谱在增长，平台能力持续进化是对的，但每一次能力变化都要有版本号、有变更记录、有回退路径。科研场景里最怕的是"模型悄悄变了，历史结论没人知道还成不成立"。
2、模型升级时要能回答"哪些结论基于哪一版"。做不到全量重跑，至少要做到标记：把结论与产生它的模型版本、脚本版本绑定，当模型升级后，能拉出一份清单说"这些历史结论的生成条件已经变了，需要复核"。这件事在架构上就是一个字段和一条索引，但如果没有，后面会变成一次全院性的信任危机。
3、把平台当资产运营，而不是当项目交付。这是研究型医院信息化最容易踩的长期坑：项目验收即巅峰，之后无人运营。可行的做法是把科研平台也纳入运营口径------按课题计量资源消耗、按复用率看数据底座的健康度、按返工率看口径的质量、按返修命中率看写作环节的价值。指标不必多，但必须有人看。
亮点与结论（可直接落地的五条）
1、验收口径先定：以"一项真实研究能不能从头跑到尾、结论能不能被复现"为主验收线，不要用"模型答得像不像"。
2、口径先于 Agent：疾病定义、纳排规则、指标字典先固化并全院共享；口径不统一时上 Agent，等于在错的基础上加速犯错。
3、人回路放在不可逆与对外的节点上：纳排规则、统计方法、对外结论三类必须显式卡点并留痕，其余环节尽量自动化。
4、算力与合规是架构的输入约束，不是上线后的补丁：临床在线优先、科研训练错峰、配额按并发与显存双维度；数据不出院、隐私计算或沙箱、全链路留痕。
5、留痕要延伸到模型与脚本版本：结论必须能回答"是哪一版模型、哪一版脚本、哪一版字典跑出来的"，否则平台越迭代，历史结论越不可信。
一句话总结：AI 原生科研平台解决的不是"让 AI 会回答问题"，而是"让研究可复现、让数据可复用、让能力可持续"------这三件事想清楚了，智能体才真正落得下去。