做药物研发数据的人，应该都体会过那种无力感：明明数据库里躺着上万项临床试验，真到立项决策时，却翻不出几条能直接支撑判断的信息。不是数据少，是数据太散、太乱、格式太任性。
最近Science刊出的多智能体AI重构早期药物研发工作，把3.7万个智能体同时投入55984项临床试验的整理与结构化，在医药AI领域算是头一回见到这个规模。这套东西我前后拆了两遍，今天把方案的核心逻辑、工程实现路径，还有真正落地时会踩的坑一次性讲透。适合正在做药物研发信息化、LLM Agent工程化，或者想搞清“多智能体到底是不是噱头”的同学。
1. 先搞清楚这3.7万个智能体到底在干什么
1.1 早期药物研发被“数据沼泽”拖住了什么
早期药物研发的决策链路其实非常长：靶点验证、化合物筛选、先导物优化、适应症选择，每一个节点都需要海量历史数据的支撑。而临床试验数据恰好是其中最硬、最接近人体真相的那部分信息——一个化合物在真实患者身上表现如何，不良反应频率有多高，生物标志物有没有跟着应答变化，这些全都在试验文档里。
问题在于，这些数据以极其混乱的形态散落着。光一个phase 2试验，就能拆出方案书、知情同意书、安全性报告、入组排除标准、统计报告、论文发表版本等等七八类文档。字段定义不一致，药物剂量单位有微克也有毫克每千克，病程描述有的按天有的按周。更麻烦的是术语乱：同一家机构在不同年份写的“死亡事件”和“致命不良事件”，可能指的是同一种情况。
这种状态下，传统做法是找医学信息专员人工录入，一个人一周能精细处理几十项试验就算很快，还得搭上质检和二审。面对五万多条的规模，纯人工根本不现实。这也解释了为什么很多团队手里有数据，却始终“用不起来”——不是没有数据，是没有把数据变成结构化知识的手段。
1.2 为什么不是“扔给大模型读文档”这么简单
很多人第一反应是：既然大模型这么强，把所有文档分批喂给它，让它抽取不就行了？我一开始也是这么想的，但实际做了就知道，这里头有三道坎绕不过去。
第一道是规模。55984项试验意味着远不止五万多份文档，一份试验可能对应七八个附属文件，总量是几十万份的颗粒度。单模型串行处理，按每份文档五分钟算，一天24小时不停也要跑几个月，任何项目都等不起。并行是可以，但并发了以后谁来管理任务状态？失败重试怎么做？中间结果怎么汇总？这已经不是“调用API”的层面了，而是完整的分布式任务系统。
第二道是上下文冲突。大模型处理单份文档时表现很好，可一旦要求它把不同来源、不同格式的信息综合判断，很容易出现幻觉和前后矛盾。同一项试验在注册信息和发表论文里入组人数不一样，模型经常二话不说选一个填进去，根本不知道这里需要的是冲突标记和人工裁决。
第三道是可审核性。医药领域的数据是要进报告、支撑决策的，你不能只给一句“AI认为有效”。每条字段必须能追溯到原始出处，必须有置信度，必须能复现。这要求系统在抽取之外，还得有一整套血缘追踪和校验机制。
多智能体方案之所以在这个场景下成立，本质上是顺着这三道坎设计的：单个智能体解决不了规模，就让大量智能体并行；单个模型容易出现观点漂移，就让不同智能体交叉验证；单次推理难以追溯，就让每个智能体的输出自带证据链。它不是为了炫技，是被问题逼出来的工程方案。
1.3 多智能体方案的设计起点
这个项目的设计起点很朴素：把“整理五万项临床试验”拆成“让五万个智能体各自专心整理一项”。每个智能体不需要无所不能，它只需要把分配给自己的那项试验吃透，输出一个结构化的结果包，然后由上层机制负责合并、查重、质检。
这个拆分逻辑和写代码做模块化治理是同一个思路。单智能体像是一个肩上扛了所有活的人，任务一多必然顾此失彼；多智能体则像工厂流水线，每个工位只负责一道工序，但组合起来产能就上去了。
从公开描述来看，这套系统里的智能体是有角色的。有负责读取原始文档并抽取结构化信息的抽取型智能体，有负责对比多来源数据一致性的校验型智能体，也有负责生成简报和汇总分析的撰写型智能体。角色分离带来的直接好处是，你可以针对每一类智能体单独调优prompt和模型参数，而不是靠一个巨型prompt去约束所有行为。
2. 核心架构拆解：分工、调度、协同
2.1 分层任务分解，而不是“一个智能体包打天下”
整套系统在任务组织上做的第一件事，是分层。最顶层是一个任务调度中心，它把55984项临床试验按批次、按疾病领域、按试验类型切成工作单元，然后派发给下一层的负责智能体。每个负责智能体接手后，会再把“整理一项试验”这个任务继续拆成若干子任务：读取注册信息、解析安全性数据、抽取疗效终点、识别入排标准、提取生物标志物信息等等。这些子任务再分配给更细粒度的专家智能体去执行。
这种分层设计最大的好处是可管控性。任何一个层级的失败，都能被限制在一个小范围内重试，不会造成全局返工。我在别的项目里也见过那种“扁平式”的多智能体方案，所有智能体地位对等，靠自然语言互相协调，表面聪明，实际一跑就乱——因为模型和模型之间的通信内容本身就是有损的，A告诉B的信息可能已经丢了一半，这样层层传递下去，最后结果根本没法验收。
分层之后，每一层都有明确的输入输出契约。上层智能体只关心下层返回的结构化结果包，不关心它是怎么做到的；下层智能体只对本层任务负责，不用去猜测全局目标。接口清晰，职责单一，这是这套方案能稳定跑完几万项任务的前提。
2.2 并行调度的工程实现：如何让3.7万个智能体“不打架”
三万多智能体同时在线，听起来是个很酷的事，做工程的都知道这是调度噩梦。每个智能体都是独立的执行单元，都有自己的状态、上下文和输出。调度中心要处理的核心问题有三个：任务分配、优先级、失败重试。
任务分配的公平性很关键。临床数据不是均匀分布的，肿瘤类试验的文档厚度可能是某种罕见病的十倍。如果一个调度器老老实实按“每单平均分”，就会出现一部分智能体早干完跑闲，另一部分被长文档压死。合理的做法是按预估的token量加权分配，让每个执行单元的工作负载趋近于均衡，而不是按任务个数分配。
优先级设计上，这套系统把“失败重试”和“高置信度结果优先归并”放到了比较高优先级的队列。原因是下游的汇总智能体不等全部完成才开始工作，它是滚动式消费上游结果的。早完成的高质量结果可以先进入聚合同步流程，这样尾部的慢任务不会阻塞整体进度。这就像周末做饭，你不能等所有菜洗好切完才开始起锅烧油，边洗边下锅才是真实效率最大的方式。
失败重试更要单独说。LLM推理不会崩溃，但输出超时、JSON格式解析失败、内容截断是家常便饭。调度器必须把这类失败视作“可重试但不阻塞”的事件，给每个任务设置最大重试次数，并追加一条retry记录供审计。我见过太多团队在这里栽跟头，以为大模型不会出错，结果第一天就发现5%的任务输出残废，傻眼在那里。
2.3 多来源证据冲突时，智能体怎么“吵而不崩”
三个智能体读同一项试验，一个说入组人数是120，一个说150，还有一个压根没抽到这个字段。这时怎么办？这套系统最有价值的设计之一，就是冲突不会被压平，而是会被显式标记出来，推送到裁决环节。
在这套架构里，校验型智能体的工作就是专门抓这种不一致。它收到多个抽取智能体对同一字段的提取结果，做比对，如果差异超过阈值，就把不同结果连同各自的原文出处一起打包，生成一个“冲突票据”。这个票据最终流向人工审核队列，由医学专家做最终裁决。
这个设计背后的道理其实很简单：你可以在技术层面接受AI的不完美，但在决策层面绝不能让不确定的信息冒充确定信息。AI给出的“最佳猜测”和专家确认过的“事实”是两个置信级别，必须区别对待。我看到太多AI医疗项目失败，不是模型不准，是自信过头了——系统把自己都拿不准的东西当成结论输出，医生用了一次发现不对，从此再不信任整套系统。
3. 一条临床数据从原始文档到结构化知识的完整流程
3.1 数据接入层：清洗、分块与分配
这套流程的第一步，是把原始文档接入系统并完成基本清洗。文档来源五花八门，有PDF扫描件、有网页抓取、有API拉回的JSON、甚至还有表格图片。这一层的核心工作有两个：OCR识别与格式标准化，以及按语义单元分块。
OCR环节通常是被严重低估的。临床试验文档里的扫描件质量参差不齐，有的页面有印章遮挡、有手写批注、还有水印穿插。实测下来，把OCR模型单独拆成一个前置服务比让主流程的智能体顺带处理要稳定得多——因为OCR模型和抽取模型是两类东西，混在一起会互相干扰。
分块策略也值得较真。很多团队喜欢按固定字符数切段，这对连续叙事型文档勉强可用，但对结构化的临床文档来说非常糟——一个字段的定义被拦腰截断，等于把证据腰斩了。这套系统采用的是语义分块，优先按文档自带的章节层次切，比如把“不良事件表”和“基线特征表”分别切成独立块，让每个块在语义上尽量自洽。切完之后，每个块会带上文档ID、章节路径、页号范围三个标签，方便下游随时随地溯源。
3.2 抽取型智能体的工作逻辑
抽取智能体拿到的是一个语义完整的文档块，它的任务是从中抽出结构化的信息。这个环节的prompt设计有讲究，不是简单的一句“请抽取所有医学信息”就完事。好的抽取prompt必须做到三点：给出明确的输出schema、规定字段取值的来源策略、强制附上原文摘录作为证据。
输出schema尤其重要。医学信息字段不是随便定几个就行，要能够对齐行业里已有的数据标准，比如MedDRA术语、CDISC标准。这套系统的做法是，为每一个字段定义允许的取值范围和格式，例如“不良事件严重程度”只能是“轻度/中度/重度/致命”之一，禁止模型自由发挥写长句。这能极大降低后续归并和统计的难度。
字段取值来源策略解决的是“模型自作主张”的问题。比如“入组人数”这个字段，规定必须优先取试验注册信息中的Primary Completion数据，如果缺失才允许取论文中的报告值，并且要在字段备注里写明实际来源是哪里。这种约束让最终结果不再是一个混合了多种口径的大杂烩，而是有明确依据的单一来源数值。
证据摘录则是最重要的一环。每个抽取结果都必须带着原文中对应句子的摘录，作为未来人工复核的入口。没有证据链的AI抽取结果，在医药行业等于废纸。
3.3 校验、去重与汇总的三道关卡
抽取完成后，数据不会直接进入最终库。它要先过校验关。校验智能体做的事情包括：枚举值合法性检查、必填字段完整性检查、跨字段逻辑一致性检查——比如“死亡人数”大于“总人数”这种低级矛盾，必须在这一轮就被拦下。
第二道关是去重。同一项试验可能以不同标题、不同机构名出现在多个来源里，系统需要识别这种实体对齐关系，把属于同一试验的记录合并成一个主条目，并保留各子来源的引用列表。这里用的是实体解析加LLM语义判断混合的方式，常规编辑距离去重处理不了“AstraZeneca”和“阿斯特捷利康公司”这种跨语言同实体，但加上语义判断后就稳多了。
第三道关是汇总和摘要。各试验的结构化条目最后汇集到撰写型智能体手里，用于生成目标导向的综述报告。比如“类风湿关节炎领域所有IL-6通路相关药物的安全性横向对比”，这类问题虽然看起来是查询，但实际需要对几百条试验记录做二次推理和归纳，不是简单SQL能解决的。撰写智能体的输出一般也不是最终答案，而是带引用编号的草稿，连同引用明细一起交付给研究人员审阅。
4. 工程实操中的关键决策与参数取舍
4.1 3.7万个智能体这个数字是怎么来的
很多人看到“3.7万”会觉得很玄学，觉得是不是越多越气派。实际上这背后是有估算逻辑的。55984项试验，每项试验的文档量平均在6到8份之间，取平均7份，那么总量大约在39万份独立文档。如果每个智能体在存活周期内能稳定处理约10份文档——注意这里考虑的不仅有抽取任务，还有校验、去重、冲突处理等辅助任务占用的容量——那需要的智能体数量就是约3.9万。再扣除重叠、复用、以及部分文档无需抽取的情况，最终落在3.7万这个量级。
这个估算法告诉我们一个经验：多智能体的数量应该由工作量除以单智能体产能的商来决定，而不是由“我想开多少进程”来决定。扩数量解决不了单智能体产能太低的问题，只会让调度器更忙、成本更高、失败率因为基数变大而更扎眼。
实际执行的时候，也不是一次性把3.7万个智能体全放出去。系统是按批次滚动的，先放几千个跑通一个小样——比如挑500项试验做试点——确认抽取准确率达到预期阈值后再逐步放量。我见过不少项目一上来就想全量并行，结果第一批就把API额度打爆，成本预算直接失控。滚桶式放量是控制成本和验证稳定性的正确路径。
4.2 上下文管理：窗口再大也别硬塞
大模型的上下文窗口这几年越来越长，很多团队因此养成了坏习惯：把整份几百页的PDF都喂进去，美其名曰“让模型自己找重点”。这套系统没有这么做，原因很直接。
临床文档动辄每份几十万字，即便窗口能塞下，真正有效的抽取精度并不会因为能看更多而变得更高。实测里，长上下文场景下模型对早期段落内容的记忆会显著衰减，而且输出里的引文定位会变得不稳定。与其挑战模型的极限能力，不如在输入端就把工作做好——用语义分块和检索把需要的片段精确送到模型面前，让它每次只在“看得清”的范围内做判断。
检索这块用的是混检策略：先靠关键词和字段名做精准召回，再用向量相似度找语义同类片段，两路结果合并去重后一起进上下文。这个组合在医学场景下比单用向量检索靠谱得多，因为很多术语在向量空间里并不可靠——比如“ACR20”和“ACR50”在语义向量上长得像，但它们是不同的疗效阈值，绝不能混。
4.3 成本控制：预算怎么分配才不肉疼
做这种量级的项目，成本是绕不开的话题。三次抽取加一次校验，乘以几十万份文档，token消耗是天文数字。实操中有一个很土但极其有效的方法：分档处理。
对文档质量高、结构化程度好的来源（比如CT.gov的API直接返回的XML），不需要让模型逐字重读，直接走规则解析和字段映射，成本几乎为零。只有对PDF扫描件、论文全文这类非结构化文档，才动用抽取智能体。就我自己的经验而言，源头结构化的数据至少能占到30%到40%的比重，这一部分能省下的成本和算力非常可观。
还有一个容易被忽略的成本黑洞是重试。一次抽取任务失败后重跑，等于原任务和重试任务的token都要花。所以prompt里的输出格式约束一定要做扎实，宁可多花几十个token把JSON格式示范写清楚，也别让模型自由发挥然后解析失败，再跑一遍。后者的代价是前者的几十倍。
5. 多智能体方案给早期药物研发带来了什么变化
5.1 从“人找数据”变成“数据等人”
这套系统上线前后最大的区别，是信息获取的方式变了。以前研究人员想了解某个靶点所有在研药物的临床进展，要在三四个数据库里来回切，手动筛选几百页文档，耗时以周计。现在只需要在系统里输入靶点或疾病领域，等几分钟，就能拿到一份带证据来源的汇总报告。
这不是搜索，而是整理。搜索给你的是链接和片段，这套系统给你的是结构化的结论和推理路径。它本质上把研究人员的角色从“信息检索者”变成了“信息审阅者”，省下来的精力可以投入到真正的科学判断上。
这个改变在项目早期尤其有价值。立项阶段最怕的就是忽略了某些已有临床证据，导致方向性错误。五万多试验的结构化整理，相当于给研究人员提供了一张实时更新的全局地图，走错方向的可能性被大幅降低。
5.2 哪些环节最先被重构
从流程上看，最先被重构的是三个最耗时、最重复的环节。
第一个是文献和数据的系统化回顾。以前做适应症调研，团队要花两三个月读文献、人工建表，现在大部分工作量被智能体替代，剩下的时间用来做质量审查和深度解读。
第二个是竞争对手与在研管线分析。识别谁在做什么靶点、做到几期、最近有什么安全信号，这些以前靠手工追踪的工作，现在变成自动化监控。每周跑一次全量比对，新出现的试验或者方案变更都逃不过系统眼睛。
第三个是内部研发决策的材料准备。不管是向管理层汇报还是撰写IND申报的前置分析，都需要大量临床证据支撑。自动化产出的结构化摘要经过专家审校后，可以直接作为底稿，显著缩短材料准备周期。
这里要提醒一句：被重构不等于被完全替代。这套系统产出的是“初稿质量”的结构化知识，它让人的工作起点往前走了一大步，但最终决策和签字确认一定还得人来。谁要是把AI产出的汇总直接当成决策依据不做审校，那是对自己职业生涯不负责。
5.3 这套思路的边界和局限
必须客观说清楚这套方案的边界。多智能体架构擅长的是规模化的信息整理和关系发现，但它不能替你产生新的科学假设，更不能替代动物实验和临床试验本身。它是在“已知信息”的维度上做极致压缩和结构化，它的天花板就是原始数据的覆盖范围。
还有一个局限是时效性。临床试验数据库的更新不是实时的，今天导出的五万多条数据，到下周可能就变了。系统的价值在这里更多是“持续运行的整理者”而不是“一次性输出的报告”，它需要被定期重跑、增量更新，才能保持地图的实时性。这个运维成本是隐性的，但不容忽视。
6. 实操复盘：多智能体项目最容易踩的六个坑
6.1 坑一：把智能体当成普通API调用
第一类心态问题，是把“多智能体系统”理解成“多次调用大模型”。任务拆了，智能体建了，但彼此之间没有任何状态传递和结果协商，本质还是单点处理。真正的多智能体，必须要有明确的输入输出契约、有跨智能体的证据校验、有失败时的降级处理。如果这些都没有，你只是在并发地调用API，不是在做多智能体。
我的判断标准很简单：系统里出现“两个智能体对同一数据源得出矛盾结论，且系统能自行发现并处理”的情况，才算真的多智能体；如果所有结论都朝着一个方向走，而且永远“对不上也不管”，那只是并行脚本。
6.2 坑二：盲目相信长上下文
第二个高频问题我已经提过，但值得再强调一遍：长上下文不是越高越好。模型能接收100万token，不代表它在100万token里找得准。在临床抽取场景里，我建议把每次输入严格限定在和当前抽取目标强相关的语义块上，必要时用检索先把范围锁死。
实测数据给你一个参考：同样是抽取“不良事件发生率”字段，把相关段落单独切成片段喂给模型，F1值比我之前把所有材料一股脑塞进去的做法高出差不多8个百分点。少即是多，在这个场景里是硬道理。
6.3 坑三：评估标准建晚了
很多团队把系统跑通了才开始想“怎么评估”，这是本末倒置。评估标准必须在设计阶段就和方案同步定下来。针对抽取任务，至少要有三套指标：字段级别的精确率和召回率、试验级别的完整性得分、以及证据溯源比例——即有多少输出字段能正确对应到原文摘录上。
这三套指标的评判对象不同，缺一不可。字段准确率只能说明单个点，完整性能看出来有没有漏抽大面积信息，溯源比例则是信任度的核心引擎。没有这套评估体系，你根本说不清系统什么时候算“好”，更谈不上迭代。
6.4 坑四：智能体数量无限扩张
我见过一个项目，明明只有两千项任务，硬是开了五百个智能体跑，结果调度通信开销比任务执行开销还高，延迟感人。智能体的数量不是荣誉勋章，是成本函数。正确做法是先少量开跑，测量单智能体的吞吐和精度，再按目标工期算出最小需要的并行度，留20%到30%的余量就行。
在3.7万这个量级下，通信开销尤其不能当儿戏。如果每个任务完成之后都要向一个中心节点同步一次状态，几万次并发同步会把中心节点的消息队列直接打爆。合理的设计是把同步降级为周期性的批次同步，吞吐会好几倍。
6.5 坑五：默认原始数据是干净的
做这类项目的第一原则：所有原始数据都是脏的。字段错位、单位不一、ID冲突、文档缺失是常态，而不是异常。处理流程里一定要在最开始就加入数据质量探查阶段，先做一次小的抽样，看看各来源的字段完整性和格式规范性，再决定哪些来源可以直接规则解析，哪些必须走模型抽取。
如果跳过这一步直接全量跑，你会在第三天才发现某个来源的日期字段用的是“YYYY/MM/DD”格式，而schema里定义的是“YYYY-MM-DD”，结果模型被逼得自己猜格式，留下几万条不规整的结果。这种低级问题，前置探查了就不会有。
6.6 坑六：忽视结果的版本管理和可复现性
最后一个坑来自工程治理：多智能体系统的结果必须版本化。模型一升级，prompt一微调，同样的输入输出就可能变了。如果系统里跑出过一个版本的结果集，后续又在相同数据上跑出了新版本，两版结果必须能做diff对比，否则研究人员的信任就建立不起来。
实操层面，至少要做到：每次全量运行生成一个不可变的版本号，记录模型版本、prompt版本、输入数据快照和运行参数；任何结论引用都必须带上这个版本号。这件事做起来不难，但对系统长期可信度的影响是决定性的。我在多个项目里验证过：没有版本管理的AI结果系统，最终都会被业务方弃用，因为没人敢对一个“来源不明、变化无常”的数据源做决策。
最后分享一点个人体会
把55984项临床试验交给AI整理，这个方向我琢磨了很长时间，最大的感触不是“AI多厉害”，而是“工程化比模型能力更能决定项目成败”。同样的模型，有人拿来做出了能用的系统，有人只做出了好看的Demo，差别全在数据管道、任务调度、校验机制和工程治理这些不起眼的地方。
如果你也想在自己的业务场景里搞多智能体，建议别一上来就追求大而全。先挑一个最小但真实的业务痛点，比如“把某个疾病领域过去五年所有试验的安全性数据整理出来”，用几十个智能体跑通一版，再把质量指标钉死，再谈规模化。这条路看着慢，但每一步都在为后面几万智能体的稳定运行打地基。
