1. 从“AI龙虾”说起一个被名字耽误的硬核项目第一次听到“AI龙虾”这个名字我以为是哪个团队做的海鲜识别小程序。直到在一个做创新药的朋友那里看到他的工作流才发现这玩意儿跟龙虾没有半毛钱关系——它是把OpenClaw、Codex、Agent、LLM这一整套东西串起来专门用来啃创新药研发里那些又臭又长的文献、专利和分子数据的。我朋友小豪某创新药企的早期研发负责人手底下管着十几个人的团队。他跟我吐槽过一件事做创新药最耗人的环节不是实验本身而是实验之前的“信息消化”。一个靶点从立项到确定候选分子团队要读几百篇文献、扒几十份专利、比对上千条化合物活性数据。这些活儿技术含量不算高但极其吃时间一个博士一个月有三分之一的时间花在查资料和整理表格上。他后来搭的这套东西核心思路就一句话让LLM带着Agent去干那些“读、比、记、报”的活人只负责判断和决策。名字里的“龙虾”其实是他们内部对OpenClaw的戏称因为Claw这个词总让人联想到钳子钳子又联想到龙虾叫着叫着就顺口了。所以别被名字骗了这本质上是一套AI Agent驱动的创新药情报处理系统。这篇文章我会把整套东西拆开讲为什么选OpenClaw而不是别的框架、Codex在里面扮演什么角色、Agent怎么设计才能不胡说八道、LLM的幻觉在医药场景下怎么兜底、以及实际跑起来之后效率到底提升了多少。适合两类人看一类是做创新药研发、想用AI提效的同行另一类是做AI Agent开发、想看看真实垂直场景怎么落地的工程师。2. 整体架构设计为什么是OpenClaw Codex Agent这套组合2.1 创新药研发的信息处理到底难在哪先把这个场景的特殊性说清楚不然后面的技术选型没法解释。创新药早期研发的信息处理有三个特点。第一是数据源极度分散PubMed上的文献、专利局的公开专利、内部实验记录、供应商的化合物目录、临床试验注册平台的进度信息格式从PDF到CSV到网页到扫描件都有。第二是容错率极低一个分子结构的误读、一个IC50值的单位搞错可能导致整个立项方向跑偏损失的是几百万的研发投入和几个月的时间。第三是知识更新快同一个靶点这个月新发的文献可能推翻上个月的结论系统必须能持续跟踪而不是一次性处理。传统的做法是买商业数据库加人工整理但商业数据库的问题是更新滞后、覆盖不全、而且没法跟内部数据打通。小豪团队之前的做法是让实习生和初级研究员手动整理效率低不说人员流动一频繁知识就断层了。2.2 为什么选OpenClaw作为Agent框架市面上Agent框架不少LangChain、AutoGPT、CrewAI这些我都试过。小豪最终选OpenClaw我问他理由他给了三条我觉得挺实在。第一条是工具调用的稳定性。OpenClaw在工具调用tool calling这一层的抽象做得比较干净定义好skill之后Agent调用外部工具的成功率明显比用LangChain那套chain式拼装要高。创新药场景里Agent需要频繁调用文献检索、分子指纹计算、专利全文抓取这些工具调用失败一次可能整个任务链就断了所以这一层稳定性是刚需。第二条是skill机制的可扩展性。OpenClaw的skill可以理解成“给Agent装的一个个插件”每个skill封装一个具体能力。小豪团队把“查PubMed”“解析专利权利要求书”“计算分子相似度”“提取实验数据表格”分别做成了独立skill后面要加新能力直接写新skill就行不用动核心逻辑。这种解耦在长期迭代里太重要了。第三条是跟Codex的配合。这一点下面单独说。2.3 Codex在链路里的真实角色很多人以为Codex就是个写代码的在这个项目里它的角色要更微妙一些。Codex在这里主要干两件事。一是动态生成数据处理脚本。创新药的数据格式千奇百怪今天来个PDF专利明天来个Excel活性表后天来个JSON格式的化合物库。你不可能提前写好所有解析脚本。小豪的做法是让Codex根据文件的实际结构现场生成解析代码跑完就丢。这比维护一个庞大的解析脚本库要灵活得多。二是做Agent的“代码执行后端”。Agent决定要做什么之后具体的数据处理动作比如批量计算分子描述符、做聚类分析、生成可视化图表交给Codex生成的代码去执行。Agent负责“想”Codex负责“算”分工明确。注意Codex生成代码后一定要在沙箱环境里跑尤其是处理外部来源的文件时。小豪团队踩过一次坑一个专利PDF里嵌了恶意宏Codex生成的解析脚本直接执行了幸好沙箱隔离做得好没影响到主系统。2.4 整体数据流长什么样把上面的东西串起来整个系统的数据流是这样的用户提出一个查询比如“帮我整理近两年关于KRAS G12C抑制剂耐药机制的文献和专利重点看联用方案”→ Agent拆解任务 → 调用文献检索skill和专利抓取skill → 原始数据落到本地 → Codex生成解析脚本 → 结构化数据入库 → LLM做信息抽取和摘要 → Agent汇总生成报告 → 人工审核。这个链路里LLM负责理解和生成Agent负责调度和决策Codex负责执行OpenClaw负责把这三者粘起来。每一层各司其职出了问题也容易定位是哪一层的锅。3. 核心细节拆解Agent设计、LLM选型与幻觉兜底3.1 Agent的任务拆解逻辑怎么设计Agent最容易犯的毛病是“想太多”或者“想太少”。想太多就是过度拆解一个简单查询拆成二十步每步都调一次LLM又慢又贵还容易出错。想太少就是直接把整个任务丢给LLM结果LLM编一堆看起来像那么回事但根本不存在的信息。小豪团队的做法是预设任务模板加动态调整。他们把创新药研发里常见的查询类型归纳成几类文献综述类、专利分析类、化合物比对类、临床进度跟踪类、竞品情报类。每类任务有一个预设的拆解模板Agent先按模板走走到某一步发现实际情况跟模板不符再动态调整。举个例子“化合物比对类”的模板是这样的第一步确认比对目标是比对活性、选择性还是成药性→ 第二步确定数据来源内部数据还是公开数据→ 第三步拉取化合物列表 → 第四步统一数据格式和单位 → 第五步计算相似度或做差异分析 → 第六步生成对比报告。这个模板不是死的。如果Agent在第三步发现某个化合物的数据缺失严重它会自动插入一步“数据补全”去公开数据库里找补充信息。这种“模板打底、动态微调”的方式比纯动态规划稳定得多也比纯模板灵活。3.2 LLM选型为什么不是越大越好这里有个反直觉的点。很多人觉得医药这种专业场景肯定要用最大的模型。小豪的实际测试结果不是这样。他们对比了几个主流LLM在创新药信息抽取任务上的表现指标是实体识别准确率能不能正确识别出化合物名、靶点名、适应症、实验数值和关系抽取准确率能不能正确判断“化合物A抑制靶点B”这种关系。模型类型实体识别准确率关系抽取准确率单次推理成本适用环节超大参数通用模型94%89%高最终报告生成中等参数专业微调模型91%92%中信息抽取主力小参数快速模型82%76%低初步筛选和分类结论是信息抽取环节用中等参数的专业微调模型性价比最高最终报告生成用超大模型保证语言质量初步筛选用小模型快速过滤。不是所有环节都需要最贵的模型。小豪特别提到一点医药领域的LLM一定要做领域适配。通用模型对“IC50”“EC50”“Ki”“Kd”这些参数的区分经常出错对化合物命名规则IUPAC名、CAS号、通用名、商品名的对应关系也容易搞混。他们用内部积累的标注数据做了一个轻量级的微调准确率提升很明显。3.3 幻觉兜底三层防护机制LLM在医药场景下胡说八道是要出人命的——不是真的出人命是项目出人命。小豪团队设计了三层防护。第一层是检索增强生成RAG。所有LLM的输出必须基于检索到的原文不能凭空生成。具体做法是Agent在让LLM生成任何结论之前先把相关的原文片段检索出来作为上下文一起喂给LLM。LLM如果生成了原文里没有的信息会被后处理模块标记出来。第二层是交叉验证。关键信息比如化合物的活性数值、靶点的突变位点必须从至少两个独立来源确认。如果两个来源的数据不一致系统会标记为“待人工确认”而不是随便选一个。第三层是置信度评分。每条LLM生成的信息都带一个置信度分数低于阈值的自动进入人工审核队列。置信度的计算综合考虑了来源可靠性、信息一致性、LLM自身的输出概率等因素。实操心得三层防护里RAG是性价比最高的。小豪说他们上了RAG之后幻觉率直接降了六成以上。交叉验证和置信度评分更多是锦上添花但RAG是底线。3.4 Skill的设计原则一个skill只干一件事OpenClaw的skill机制很好用但设计skill有个原则一个skill只干一件事而且这件事要定义得足够窄。小豪团队一开始犯过错误做了一个“文献处理skill”想让它同时干检索、下载、解析、摘要四件事。结果这个skill又臃肿又难维护改一个地方影响一大片。后来拆成了四个独立skill文献检索skill、PDF下载skill、全文解析skill、摘要生成skill。每个skill的输入输出都定义得很清楚组合起来用反而更灵活。他们现在有二十多个skill覆盖了从数据采集到报告生成的完整链路。每个skill都有独立的测试用例改一个不会影响其他的。这种模块化设计在长期迭代里省了太多事。4. 实操过程从零搭一套能跑的创新药情报Agent4.1 环境准备与OpenClaw部署先说环境。小豪团队用的是Linux服务器Ubuntu 22.04Python 3.10。OpenClaw的部署方式有好几种他们选的是源码部署因为需要改一些底层的东西。部署的大致步骤是这样的先从官方仓库拉代码然后建虚拟环境装依赖接着配置模型接入信息最后跑一个测试任务验证链路通不通。具体命令我不在这里贴了因为版本更新快直接看官方文档最准。但有几个坑要提醒。第一个坑是依赖冲突。OpenClaw依赖的一些库跟科学计算库比如RDKit、NumPy的版本要求可能打架。小豪的做法是给OpenClaw单独建一个虚拟环境跟数据处理的环境隔离开两边通过API通信而不是直接import。第二个坑是模型接入的配置。如果你用的是云端LLM API注意配置好超时和重试。医药场景的查询往往比较长响应时间可能到几十秒默认的超时设置经常不够用。第三个坑是skill的加载路径。OpenClaw加载skill的路径配置要写对不然会出现“skill找不到”的错误。小豪建议把skill放在独立的目录里用绝对路径配置别用相对路径。4.2 文献检索skill的实现要点文献检索skill是整个链路的入口它的质量直接决定了后面所有环节的上限。这个skill的核心逻辑是接收查询关键词 → 构造检索式 → 调用PubMed E-utilities API → 解析返回结果 → 去重和排序 → 输出结构化文献列表。检索式的构造有讲究。创新药场景的查询往往涉及多个概念靶点、疾病、化合物类型、研究阶段需要把它们用布尔逻辑组合起来。小豪团队的做法是让LLM先把用户的自然语言查询翻译成结构化的检索参数再由skill构造最终的检索式。这样比让用户直接写检索式要友好得多。去重和排序也有讲究。PubMed返回的结果里经常有重复同一篇文章的不同版本需要根据DOI或PMID去重。排序不能只看发表时间还要考虑期刊影响因子、引用次数、跟查询的相关性。小豪他们用了一个简单的加权评分公式来做综合排序。4.3 专利解析skill的难点与解法专利解析比文献解析难得多因为专利的格式极不统一而且关键信息往往藏在权利要求书里语言极其绕。这个skill的处理流程是抓取专利全文 → 识别专利类型化合物专利、用途专利、制剂专利等→ 提取权利要求 → 解析技术方案 → 抽取关键信息化合物结构、适应症、给药方案等。难点主要在权利要求书的解析。权利要求书用的是法律语言一句话可能嵌套好几层而且经常用“所述”“其特征在于”这类指代。小豪团队的做法是先用规则做初步切分再用LLM做语义解析最后用规则做校验。纯规则搞不定纯LLM又容易出错两者结合才稳。注意专利解析的结果一定要人工抽检。小豪说他们抽检了100份专利的解析结果发现LLM在解析“马库什权利要求”时错误率明显偏高。马库什权利要求是一种涵盖多个化合物的概括性权利要求结构复杂LLM经常漏掉或搞错取代基的定义。4.4 化合物数据比对skill的参数计算这个skill是创新药研发里最核心的工具之一。给定一组化合物计算它们之间的相似度找出结构或活性上的差异。相似度计算用的是分子指纹加Tanimoto系数。分子指纹把化合物的结构编码成一个二进制向量Tanimoto系数衡量两个向量的相似程度值在0到1之间越接近1越相似。小豪团队用的是ECFP4指纹半径21024位。这个参数组合在药物化学里比较常用对结构差异的敏感度适中。活性数据的比对要复杂一些。不同来源的活性数据单位可能不一样nM、μM、mg/mL实验条件也可能不一样细胞系、 assay类型、孵育时间。直接比对会出大问题。小豪的做法是先做单位统一再做条件标注最后才做数值比对。如果两个数据的实验条件差异太大系统会标记为“不可直接比较”。4.5 报告生成与人工审核的衔接Agent跑完所有环节之后会生成一份结构化报告。报告包含文献综述、专利分析、化合物比对结果、竞品情报等模块。但报告不是直接给决策层看的中间必须有人工审核环节。小豪团队设计了一个审核界面审核人可以逐条查看Agent生成的结论看到每条结论对应的原文出处可以标记“确认”“修改”“驳回”。被驳回的结论会反馈给系统用于后续的模型优化。这个反馈闭环很重要。小豪说他们跑了三个月之后Agent的准确率比刚上线时提升了不少主要就是靠人工审核的反馈数据在做持续微调。5. 常见问题与排查技巧实录5.1 Agent任务链断裂怎么排查任务链断裂是最常见的问题表现是Agent跑到某一步就停了或者输出一个莫名其妙的结果。排查思路是从后往前查。先看最后一步的输入是什么如果输入就不对说明问题在前面。然后看倒数第二步的输出以此类推直到找到第一个输出异常的地方。常见的断裂原因有几个。一是工具调用超时某个skill调用的外部API响应太慢Agent等不及就放弃了。解法是给每个skill设置合理的超时时间超时后自动重试或降级。二是数据格式不匹配前一个skill输出的格式跟后一个skill期望的格式对不上。解法是给每个skill的输入输出定义严格的schema中间加一层格式校验。三是LLM输出解析失败LLM返回的内容不符合预期的JSON格式解析器报错。解法是用更宽容的解析策略或者让LLM重新生成。5.2 LLM输出不稳定的应对策略同一个查询跑两次结果不一样这在医药场景里很让人头疼。小豪团队的应对策略是降低温度参数加多次采样投票。温度参数调到0.1以下让LLM的输出尽量确定。对于关键结论让LLM跑三次取多数一致的结果。如果三次结果都不一致说明这个问题本身就有歧义标记为“待人工确认”。另一个策略是固定随机种子。有些LLM API支持设置随机种子设置之后同样的输入会得到同样的输出。这个在调试和复现问题时特别有用。5.3 数据源访问受限的替代方案做创新药情报数据源是命脉。但很多数据源有访问限制比如某些专利数据库需要付费某些文献只有摘要没有全文。小豪团队的替代方案是多源互补加开放获取优先。文献方面优先用PubMed Central的开放获取全文没有全文的就用摘要加其他来源的补充信息。专利方面用公开专利数据库加商业数据库的免费额度组合。内部数据方面建了一个内部知识库把团队积累的实验数据和经验沉淀下来。实操心得数据源不在多在精。小豪说他们一开始接入了十几个数据源后来发现常用的就五六个其他的要么质量差要么更新慢。现在他们只维护核心数据源把精力放在提升数据质量上。5.4 性能瓶颈的定位与优化系统跑起来之后性能瓶颈通常出现在两个地方LLM调用和数据处理。LLM调用的优化空间在于批处理加缓存。把多个小请求合并成一个大请求减少调用次数。对于重复的查询把结果缓存起来下次直接读缓存。小豪他们做了一个查询缓存命中率大概在四成左右省了不少调用成本。数据处理的优化空间在于并行化。文献解析、专利解析、化合物计算这些任务之间没有依赖关系可以并行跑。小豪用了一个简单的任务队列把独立的任务分发到多个worker上并行执行整体速度提升明显。5.5 常见问题速查表问题现象可能原因排查方法解决方案Agent任务中途停止工具调用超时或失败查看任务日志最后一步增加超时时间加重试机制LLM输出格式错误提示词不够明确检查LLM原始输出优化提示词加格式示例数据解析结果异常源文件格式变化对比解析前后数据更新解析规则加格式校验相似度计算结果离谱分子指纹参数不对检查指纹类型和位数统一指纹参数加验证用例报告内容前后矛盾多源数据冲突追溯每条结论的来源加交叉验证标记冲突项系统响应越来越慢缓存失效或数据堆积查看缓存命中率和队列长度清理缓存优化队列策略6. 效率提升的实测数据与经验总结6.1 上线前后的效率对比小豪给了一组他们内部统计的数据我觉得挺有参考价值。任务类型上线前耗时上线后耗时提升幅度靶点文献综述3-5个工作日4-6小时约85%专利分析报告5-8个工作日1-2个工作日约75%化合物比对分析2-3个工作日2-4小时约90%竞品情报跟踪持续人工跟踪自动日报加人工审核约70%这些数字是平均值具体项目差异很大。但整体趋势很清楚重复性信息处理任务的效率提升最明显需要深度判断的任务提升有限。这也符合预期AI擅长的是“读得多、记得住、算得快”不擅长的是“判断哪个方向更有前景”。6.2 团队工作方式的改变效率提升带来的不只是时间节省还有工作方式的改变。以前团队的工作模式是“先查资料再讨论”查资料占了大头。现在变成了“先让Agent跑一轮拿到初步结果再讨论”讨论的起点高了讨论的质量也上去了。研究员的时间更多花在实验设计和数据分析上而不是文献整理上。另一个改变是知识沉淀。以前实习生走了他整理的资料可能就散落了。现在所有Agent处理过的信息都结构化入库了新人来了可以直接查不用从头再来。6.3 我个人的几点体会跟小豪聊完加上我自己试跑了一些环节有几个体会比较深。第一别追求全自动。创新药研发的决策链条太长全自动不现实也不安全。人机协作才是正路AI负责信息处理人负责判断决策。小豪他们的系统里人工审核环节从来没去掉过也不打算去掉。第二数据质量比模型大小重要。同样的模型喂高质量的结构化数据输出质量明显更好。小豪他们花在数据清洗和标注上的时间比花在模型调优上的时间多得多。这个投入是值得的。第三从小场景切入。别一上来就想做全流程覆盖。小豪他们最早只做了文献检索这一个环节跑通了再逐步加专利、加化合物、加报告生成。每一步都验证过再往下走比大干快上稳得多。第四保持对LLM输出的警惕。不管做了多少层防护LLM的输出永远需要人工抽检。小豪说他们到现在还保持着每周抽检的习惯不是不信任系统而是医药这个领域容错率太低多一道检查多一份安心。最后分享一个我觉得很实用的小技巧给Agent的提示词里加上“如果你不确定就说不知道”。这句话看起来简单但能显著降低LLM的胡编乱造率。在医药场景里“不知道”比“编一个”有价值得多。小豪说他们加了这句话之后需要人工纠正的错误少了很多。这个技巧不限于医药场景任何对准确性要求高的Agent应用都适用。