这是药企AI Agent落地三部曲的第1篇。三篇分别解决本篇文献调研与竞品情报——信息淹没人工整理效率极低第2篇临床方案与注册文件——长文档修改联动格式校验耗时第3篇跨部门数据孤岛——多部门数据不通协作靠手工转格式本三部曲完整记录了从单Agent逐步扩展到多Agent协作系统的过程。所有工具全线开源可私有化部署。1. 问题描述先说痛点。在药企做过竞品情报的人应该都有经历每周花20多个小时在文献筛选和整理上真正坐下来做分析判断的时间不到5小时。大部分时间都耗在找这个动作上——翻PubMed、刷ClinicalTrials.gov、盯竞品官网、查财报、看会议摘要……几个数字比较说明问题竞品动态追踪靠人工平均滞后2周。等你看到人家发了新闻稿其实临床数据早就在会议摘要或者SEC filing里了一份竞品周报花4小时制作其中至少3小时是花在找数据、对齐口径、格式调整上同一段数据在不同报告里重复整理。临床部的报告、注册部的报告、BD的报告各写各的数据来源都不一样每周检索文献200篇真正有用的不超过20篇但是你还得一篇篇点进去看再说说硬约束药企场景跟互联网场景最大的区别就在这儿数据不能出内网。患者数据、临床数据、商业分析——这些碰都不能碰外部API。用GPT-4o数据过境的合规风险你扛不住必须满足GxP合规。GxP不只是个标签它意味着你得有审计追踪、版本控制、数据溯源已有PostgreSQL基础设施。核心业务跑在PG上面LIMS、CTMS、eTMF不可能为了一个AI项目单独搞一套新的数据库集群运维团队会把你骂死全线需要开源可私有化部署。自主可控不是喊口号是药企IT部门审批的红线。不开源不部署在内网直接否掉说白了你要在数据不出内网 GxP合规 复用现有基础设施 全线开源这四个约束条件下搭一套能干活的AI系统。我之前帮另一家药企评估过一套商业化方案——某大厂的智能知识管理平台功能演示确实炫酷。但是一问到数据部署对方说可以部署私有云版本再一问价格光授权费就够买三台GPU服务器了。更关键的是它的文档解析引擎不支持药企常用的双栏排版论文格式改都没法改。这种黑盒方案在药企根本过不了合规审查。所以我给自己定了个原则所有组件必须开源、可审计、可二次开发。出了问题自己能改不用等供应商排期。2. 方案设计先说一个我踩过的最大的坑Agent的核心不是对话能力是工作流能力。很多人一上来就想做一个AI聊天机器人能回答医药问题就行了。这是把Agent当搜索引擎用。真正有价值的Agent是一条完整的工作链检索→解析→结构化→生成→学习。每一步都能自动化串起来才是做情报而不只是搜信息。按这个思路我把整个系统拆成了几个模块每个模块选一个最合适的开源方案。技术选型组件选型开源协议选择理由考虑过但没选Agent平台Dify.ai开源GitHub 90k Star原生支持多Agent编排和Workflow支持私有化Docker部署Langflow可视化好但是多Agent支持弱、Flowise轻量但不适合企业级向量数据库PGVectorPostgreSQL扩展开源药企已有PostgreSQL基础设施加个扩展即可Milvus功能更强但是需要独立部署运维对这个规模偏重LLM底座Qwen3.535B-A3BApache 2.0最新开源旗舰Apache 2.0中文能力顶级MoE架构推理高效可私有化部署GPT-4o数据出境合规风险、GLM-4中文略逊Qwen记忆层Mem0开源版Apache 2.0分层记忆Dify原生集成LangChain Memory功能弱、自建开发成本高重排序BGE-Reranker-v2-m3MITBAAI开源中英文检索精度优秀Cohere Rerank商业API数据出境风险文档解析pdfplumber MinerU开源MinerU专攻学术论文双栏排版上海AI Lab开源Unstructured.io通用性强但是学术论文解析不如MinerU精准文档存储RustFS开源分布式对象存储S3兼容私有化部署MinIO开源优秀但是核心维护团队在海外报告生成Jinja2 python-docx开源模板引擎Word输出—GPU预算升级建议如果GPU资源充足可以把Qwen3.5-35B-A3B升级到Qwen3.5-397B-A17B总参数397B激活参数17B中文理解和长文本能力更好不过需要4×A100 80G起步。初期建议先上35B-A3B跑通流程再说。为什么选Dify不选LangflowDify的Workflow编排能力是真的强条件分支、并行节点、循环——这些在复杂的检索工作流里都是刚需。Langflow可视化确实好看但是一旦涉及多Agent编排就不太够用了。为什么用PGVector不单独上Milvus因为药企已经有跑着的PostgreSQL了。加个扩展就能做向量检索不需要额外部署一套新系统。800篇文献的向量规模PGVector完全够用杀鸡不用牛刀。Qwen3.5-35B-A3B怎么样MoE架构总参数35B但是激活参数只有3B。这意味着什么推理的时候只需要跑3B的参数速度很快1-2张A100 40G就能跑得很流畅。显存占用大概在70GB左右因为要加载全部权重这个后面Step 2详细说。初期建议先上这个够用。架构图整个系统就一个Agent干一件事把散落在各处的文献和情报数据收集起来、解析、结构化、生成周报然后记住用户喜欢什么。不复杂但是每一步都跑通了。3. 实施过程下面按天拆解。所有命令和代码都可以直接复制跑。Step 1Dify环境搭建Day 1Dify用Docker部署十分钟就能跑起来。# 克隆Dify仓库 git clone https://github.com/langgenius/dify.git cd dify/docker # 复制环境配置文件 cp .env.example .env # 编辑.env改几个关键参数 # SECRET_KEY你随机生成的密钥建议用 openssl rand -hex 32 # DB_PASSWORD设个强密码 # REDIS_PASSWORD同上 # LOG_LEVELWARNING默认INFO日志量太大排查问题的时候再改成DEBUG # MAX_WORKERS4Celery Worker并发数文献量大的时候可以调高到8 # WEB_API_RATE_LIMIT60API限流防止被刷爆 # 启动所有服务 docker compose up -d启动完访问 http://你的内网IP/install完成初始化设置创建管理员账号。整个过程跟装个WordPress差不多。踩坑记录坑1Docker镜像拉取很慢或者直接超时。内网环境没有外网访问权限docker compose pull直接卡死。解决办法是提前在内网的镜像仓库Harbor里把Dify的几个镜像同步好或者找运维要离线安装包tar包用 docker load 手动导入。别到了现场才发现拉不了镜像那就尴尬了。坑2启动之后浏览器访问不了。最常见的原因有两个一是防火墙没开端口firewall-cmd --add-port80/tcp --permanent 然后 firewall-cmd --reload二是SELinux阻止了Docker的网络访问临时测试可以用 setenforce 0 关掉生产环境建议配置SELinux策略而不是直接关。官方文档[Dify Docker部署指南](https://docs.dify.ai/getting-started/install-self-hosted/docker-compose)Step 2Qwen3.5模型部署Day 1-2这一步需要有GPU的服务器。我用的是vLLM做推理服务部署完暴露一个OpenAI兼容的API接口Dify直接对接。# 安装vLLM注意版本必须0.6.0才支持Qwen3.5的MoE架构 pip install vllm0.6.0 # 启动Qwen3.5-35B-A3B推理服务MoE架构1-2张A100 40G即可 python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen3.5-35B-A3B \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.9 \ --max-model-len 32768几个关键参数说明一下--gpu-memory-utilization 0.9默认是0.9意思是允许vLLM用90%的显存。如果你的GPU还要跑别的服务需要调低这个值比如设0.7--max-model-len 32768最大上下文长度。这个值要根据显存来调32K在双卡A100 40G上是跑得动的。如果发现OOM先试24576或者16384--tensor-parallel-size 2张量并行数用几张卡就设几跑起来之后去Dify后台设置→模型供应商→添加OpenAI-API兼容→填入地址 http://内网IP:8000/v1。模型名称填 Qwen/Qwen3.5-35B-A3B。测一下连通性curl http://内网IP:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model:Qwen/Qwen3.5-35B-A3B,messages:[{role:user,content:你好}]}返回正常JSON就说明没问题了。踩坑记录坑1MoE模型的显存占用跟你想的不一样。Qwen3.5-35B-A3B虽然激活参数只有3B推理速度接近3B模型但是显存占用不能按3B来算——全部35B的权重都得加载到显存里实际占用大概70GB。也就是说如果你只有2×A100 40G总共80GB留给KV Cache的空间只有10GB左右长文本场景可能会OOM。解决办法要么降 --max-model-len要么用3张卡分摊。坑2vLLM版本兼容性。确保vLLM版本 0.6.0老版本比如0.4.x不识别Qwen3.5的MoE架构启动直接报 Model architecture not supported 的错误。安装完之后先用 pip show vllm 确认一下版本号。官方文档[vLLM文档](https://docs.vllm.ai/)[Qwen模型文档](https://qwenlm.github.io/)Step 3PGVector向量数据库配置Day 2不用额外部署任何东西直接在你现有的PostgreSQL里加个扩展。# 安装PGVector扩展根据你的PG版本选对应包名注意大版本要匹配 sudo apt install postgresql-15-pgvector # 连接你的数据库执行以下SQL psql -U your_user -d your_database-- 启用PGVector扩展 CREATE EXTENSION IF NOT EXISTS vector; -- 创建文献向量表 -- 注意维度要跟embedding模型匹配Qwen3.5配bge-m3的话维度是1024不是1536 CREATE TABLE document_embeddings ( id SERIAL PRIMARY KEY, content TEXT, metadata JSONB, embedding vector(1024) -- bge-m3输出1024维向量 ); -- 创建向量索引加速余弦相似度检索 -- 注意ivfflat索引需要先有数据才能建空表建索引会报错 -- 建议先灌一批数据再建索引或者改用HNSW索引支持空表建索引但是构建更慢 CREATE INDEX ON document_embeddings USING hnsw (embedding vector_cosine_ops);然后在Dify后台配置外部知识库连接填入你的PostgreSQL连接信息。这样Dify的Agent就能直接检索你库里的文献了。踩坑记录坑1PGVector版本要跟PostgreSQL大版本匹配。PG15装PG14的vector扩展会报错 could not open extension control file因为控制文件路径是按大版本分的。安装之前先 psql --version 确认PG版本然后装对应的pgvector包。坑2ivfflat索引在空表上建不了。第一次跑建表SQL顺手建索引的话会直接报错。解决办法先灌一批数据进去再建ivfflat索引或者像上面SQL里写的改用HNSW索引。HNSW支持空表建索引好处是后面新增数据不需要重建索引坏处是初次构建比ivfflat慢不少。800篇文献的规模两种索引差别不大看个人偏好。官方文档[PGVector](https://github.com/pgvector/pgvector)Step 4文档解析流水线搭建Day 2-3这一步我踩了不小的坑。一上来我用pdfplumber解析论文PDF结果双栏排版的论文表格直接乱成一锅粥。测了50篇论文表格解析准确率只有67%。后来换上了MinerU上海AI Lab开源的项目专攻学术论文解析准确率直接拉到89%。但是MinerU也不是万能的大概5%的复杂表格合并单元格特别多那种还是会错位。最后定下来的方案是两个一起用MinerU为主pdfplumber补刀。# 安装MinerU注意full版本会拉很多依赖包括paddleocr pip install magic-pdf[full] # 安装pdfplumber作为补充 pip install pdfplumberfrom magic_pdf.data.data_reader_writer import FileBasedDataWriter, FileBasedDataReader from magic_pdf.data.dataset import PymuDocDataset # 读取PDF reader FileBasedDataReader() pdf_bytes reader.read(paper.pdf) ds PymuDocDataset(pdf_bytes) # 解析为Markdown表格、公式结构都保留 md_content ds.apply( PdfFlashParsePipeline(), ImageWriter(/tmp/images), )解析完的Markdown不是直接就能用的。页眉页脚要清掉引用格式要统一参考文献要剥离——这些预处理做完再向量化入库。别问我怎么知道的第一次入库的数据检索出来全是页眉和页码差点以为自己搞了个假系统。踩坑记录坑1MinerU需要额外的GPU显存。MinerU内部用了布局检测模型基于PaddleOCR需要额外的2-4GB显存。如果跟LLM推理服务跑在同一张卡上需要预留这部分显存。建议把MinerU的任务放到非高峰时段批量跑或者单独用一张卡跑解析不要跟vLLM抢显存。另外 magic-pdf[full] 在离线环境安装的时候需要提前准备好paddleocr等依赖的whl包不然装到一半卡住就很烦。坑2解析速度比想象的慢。MinerU解析一篇10页的论文大概需要30-60秒GPU模式800篇文献的初始入库需要预留半天时间。别把初始入库安排在上线前一天老老实实提前两三天开始跑。如果CPU模式的话更慢一篇可能要5-10分钟。官方文档[MinerU](https://github.com/opendatalab/MinerU)Step 5Dify Workflow配置——检索摘要Day 4-5这是Agent的核心工作流。在Dify里用Workflow编排搭了一条这样的流水线开始节点 → 接收用户输入竞品名称/靶点/关键词并行检索节点三路同时跑PubMed E-utilities API通过HTTP请求节点Semantic Scholar API内部知识库PGVector重排序节点 → BGE-Reranker对合并结果排序摘要生成节点 → Qwen3.5按竞品维度组织输出结束节点 → 返回结构化摘要BGE-Reranker的部署也在这一步完成。用Xinference起一个推理服务就行# 安装xinference建议0.10.0低版本可能找不到bge-reranker-v2-m3 pip install xinference0.10.0 # 启动Reranker服务 xinference-local --host 0.0.0.0 --port 8001 # 在xinference web UI中启动 bge-reranker-v2-m3 模型 # 或者直接命令行 xinference launch --model-name bge-reranker-v2-m3 --model-type rerankerDify的Workflow里用HTTP请求节点调用这个Reranker接口对三路检索的合并结果做二次排序。实际跑下来效果很明显——不加重排的时候Top 10结果里大概6-7篇是相关的加上之后能到9篇以上。有一个配置细节要注意Dify Workflow里HTTP请求节点的超时时间要调大一些默认值太短了。PubMed API响应慢的时候可能要10-20秒才返回建议把超时设到30秒。不然高峰期检索直接超时失败报错信息还不太明显排查了半天才发现是超时问题。这里有两个坑说一下第一个坑PubMed API返回的摘要太短了基本就是一两句话根本不够做分析。解决办法是通过DOI去抓CrossRef的全文摘要信息量翻了好几倍。如果CrossRef也没有全文摘要退而求其次去Semantic Scholar拿 enriched abstract。两条路都试了基本上90%以上的论文都能拿到足够的摘要信息。第二个坑是多源检索的去重。PubMed和Semantic Scholar有重叠同一个论文可能两边都检索到。我用DOI标题双重匹配做去重先匹配DOI精确DOI缺失的再用标题模糊匹配。标题匹配有个细节要先把标题统一转成小写、去掉标点不然Phase III和Phase 3会匹配不上。另外还有一个容易忽略的问题三路检索返回的结果格式不统一。PubMed返回的是XML格式Semantic Scholar返回JSON内部知识库返回的又是另一种结构。在做重排之前必须先写一个适配层把格式统一掉——统一成 (title, abstract, source, doi) 这样的标准结构然后再喂给Reranker。这个问题一开始没处理好Reranker直接报错了因为输入格式不对。踩坑记录坑1Xinference版本太低找不到模型。如果xinference版本低于0.10.0xinference launch 启动bge-reranker-v2-m3的时候会报模型不存在的错误。升级一下就好pip install --upgrade xinference0.10.0。坑2三路检索结果格式不统一。这个问题上面提了再多说一句——PubMed的XML解析用Python的 xml.etree.ElementTree 就行不需要额外装库。关键是把所有来源的字段名对齐不然后面重排和生成都会出问题。这个问题后面单独展开说第2篇会讲到多数据源适配的通用做法。官方文档[Dify Workflow指南](https://docs.dify.ai/guides/workflow)[FlagEmbeddingBGE-Reranker](https://github.com/FlagOpen/FlagEmbedding)Step 6竞品周报自动生成Day 6-8检索完了得输出。我一开始犯了一个经典错误直接让Qwen3.5写文献综述。结果生成的周报又长又学术根本没人看。后来调整了prompt方向——写给决策者看的简报每个信息点不超过2行。效果马上就出来了。周报模板用Jinja2定义最终用python-docx输出Word文档from docx import Document from docx.shared import Pt, Inches from docx.enum.text import WD_ALIGN_PARAGRAPH # 样式预定义很重要不然默认样式很丑 def setup_styles(doc): 定义Word文档样式这一步不能省 # 设置正文字体 style doc.styles[Normal] font style.font font.name 微软雅黑 font.size Pt(10.5) # 设置标题样式 for i in range(4): heading_style doc.styles[fHeading {i}] heading_style.font.name 微软雅黑 heading_style.font.color.rgb None # 用默认黑色别搞花里胡哨的 # 设置列表样式 list_style doc.styles[List Bullet] list_style.font.name 微软雅黑 list_style.font.size Pt(10.5) list_style.paragraph_format.space_after Pt(4) # 段后间距别挤在一起 # Jinja2周报模板 template # 竞品情报周报 - {{ week_range }} ## 1. 管线进展 {% for item in pipeline_updates %} - **{{ item.company }}** {{ item.drug }}: {{ item.update }} {% endfor %} ## 2. 临床数据 {% for item in clinical_data %} - **{{ item.trial_id }}** {{ item.phase }}期 | {{ item.indication }} - 主要终点: {{ item.primary_endpoint }} - 结果: {{ item.result }} {% endfor %} ## 3. 专利动态 {% for item in patent_updates %} - **{{ item.company }}**: {{ item.detail }} {% endfor %} ## 4. 合作交易 {% for item in deals %} - **{{ item.company_a }}** × **{{ item.company_b }}**: {{ item.detail }} {% endfor %} # 用python-docx输出Word doc Document() setup_styles(doc) # 先设样式 doc.add_heading(竞品情报周报, 0) for section in report_data: doc.add_heading(section[title], level1) for item in section[items]: doc.add_paragraph(f{item[company]}: {item[detail]}, styleList Bullet) doc.save(weekly_report.docx)踩坑记录坑1Jinja2模板里的中文在python-docx里可能显示乱码。确保模板文件和docx的编码都统一为UTF-8。如果模板文件是用Windows记事本编辑保存的可能是GBK编码读进来就乱码了。用VS Code或者任何正经编辑器打开另存为UTF-8格式就行。坑2让LLM按模板生成结构化数据的时候输出格式经常不稳定。有时候多一个字段有时候少一个字段偶尔还会自己加一个总结板块。这个问题一两句话说不清楚后面第2篇会单独展开说怎么用Pydantic做格式校验确保LLM输出的JSON严格符合模板定义的结构。这里先记住一个原则不要相信LLM的输出格式一定要加校验。官方文档[python-docx](https://python-docx.readthedocs.io/)Step 7接入Mem0记忆层Day 9-10这一步是让Agent从工具变成助手的关键。Mem0能记住用户的偏好。比如重点关注PD-L1和ADC方向的竞品动态、核心竞品公司是阿斯利康、罗氏、默沙东。Agent下次检索的时候就会自动过滤无关文献优先推送用户关心的内容。# 部署Mem0 git clone https://github.com/mem0ai/mem0.git cd mem0 pip install -e .这里有一个非常重要的配置Mem0默认会调用OpenAI的API做记忆提取。如果不改配置你的数据就直接走外网了药企数据出境这个事就不用我多说了吧。必须把config指向本地部署的模型# config.yaml llm: provider: openai config: model: qwen3.5-35b-a3b base_url: http://内网IP:8000/v1 # ↑ 必须指向本地vLLM绝对不能走OpenAI embedder: provider: openai config: model: bge-m3 base_url: http://内网IP:8001/v1 # 记忆类型选择 # 默认用vector向量检索对于偏好类信息够用了 # 如果涉及复杂的事实关系比如阿斯利康的PD-L1管线跟默沙东有合作这种 # 可以用graph模式但是需要额外配置图数据库初期不建议折腾 memory_type: vector # 记忆检索相关度阈值 # 默认0.5对中文场景偏高建议调到0.3-0.4 # 不然很多相关的记忆检索不出来 threshold: 0.35from mem0 import Memory m Memory() # 记录用户偏好 m.add(重点关注PD-L1和ADC方向的竞品动态, user_idresearcher_1) m.add(核心竞品公司阿斯利康、罗氏、默沙东, user_idresearcher_1) # 检索时自动结合记忆 results m.search(最新临床数据, user_idresearcher_1)接上Mem0之后Agent推送的文献相关度明显提升。之前推10篇大概6篇有用现在8篇都有价值。踩坑记录坑1Mem0默认调OpenAI API做记忆提取。这个坑再强调一次——Mem0的config里如果不显式指定 base_url 指向本地模型它会默认调OpenAI的API。数据直接出境合规风险巨大。部署完之后第一件事就是检查网络请求确认没有任何外网调用。坑2记忆检索的相关度阈值。默认阈值是0.5对中文场景偏高很多相关的记忆检索不出来。建议调到0.3-0.4之间。我最后用的是0.35既能召回相关记忆又不会引入太多噪音。如果你的用户群体比较大、记忆条目很多可能需要根据实际效果微调。官方文档[Mem0](https://docs.mem0.ai/)Step 8RustFS文档存储Day 10最后把文档存储也搭好。RustFS是个开源的分布式对象存储S3兼容接口Docker一行就起来了。# Docker部署RustFS # 注意必须通过环境变量设置access key和secret key # 不然默认匿名访问生产环境绝对不能这样 docker run -d \ --name rustfs \ -p 9000:9000 \ -p 9001:9001 \ -e RUSTFS_ACCESS_KEYyour-access-key \ -e RUSTFS_SECRET_KEYyour-secret-key \ -v /data/rustfs:/data \ rustfs/rustfs:latest # 创建存储桶需要配置好认证信息 aws s3 mb s3://reports \ --endpoint-url http://内网IP:9000 \ --region us-east-1 # 周报自动上传 aws s3 cp weekly_report.docx s3://reports/2026-W28/ \ --endpoint-url http://内网IP:9000生成完的周报自动传到RustFS里按年份-周数分目录存放。谁、什么时候、生成了一份什么报告全都有记录。GxP审计追踪这不就来了嘛。踩坑记录坑1boto3连接RustFS的签名问题。RustFS的S3兼容接口跟AWS S3有细微差异用Python的boto3客户端连接的时候需要显式设置 signature_versions3v4不然上传大文件比如几十MB的报告会报签名错误。代码里加一行配置就行pythonimport boto3from botocore.config import Configs3_client boto3.client(s3,endpoint_urlhttp://内网IP:9000,awsaccesskey_idyour-access-key,awssecretkey_idyour-secret-key,configConfig(signature_versions3v4))坑2RustFS本身不做跨节点备份。单节点部署的话硬盘挂了数据就没了。建议配合rsync做定期备份到另一台机器写个crontab每天凌晨跑一次。生产环境别偷懒数据丢了可没人帮你。官方文档[RustFS](https://rustfs.com/docs/)4. 运行结果部署前后对比用数据说话指标部署前部署后变化竞品周报生成时间4小时30-40分钟↓83-85%竞品动态追踪延迟平均2周2-3天获取↓75-80%每周文献整理耗时20h6-8h↓60-70%文献检索相关度人工筛选~75%Agent检索85-88%*↑10-13%周报覆盖信息量3-5个竞品10个竞品↑200%文献检索相关度数据说明85-88%这个数据是基于200篇文献的抽样测试Agent检索结果经人工逐篇复核后统计的相关率。不是Agent自动判定的是真有人一篇篇看过了。最让我意外的变化是周报覆盖信息量。之前人工只能盯3-5个核心竞品因为精力有限。现在Agent同时跑10个竞品的动态人只需要看Agent整理好的简报做判断。覆盖面翻了2倍人反而更轻松了。数据方法论说明以上数据取4周实际运行的每周平均值。测试环境为2×A100 40G 64GB内存文献库规模800篇。不同硬件配置和文献规模下数据会有差异。比如文献库扩到2000篇以上检索延迟和解析时间都会上升GPU显存也可能成为瓶颈。资源消耗方面GPUQwen3.5-35B-A3B推理需要1-2×A100 40GMoE架构显存占用约70GB存储800篇文献解析后约15GB含向量数据内存Dify Mem0 BGE-Reranker合计约16GB说实话这个成本在药企IT预算里不算高。一台带双卡的GPU服务器就能跑起来比买一套商业情报数据库便宜多了。5. 总结与下一步踩坑总结10天跑下来总结几个经验文档解析是地基。MinerU比pdfplumber更适合学术论文但是两者互补使用效果最好。解析质量直接决定后面所有环节的产出质量。垃圾进垃圾出这话在Agent场景里尤其准。复用已有基础设施。PGVector不需要额外部署新系统药企已经有PG了就直接加扩展。别动不动就想上一套新的向量数据库运维成本和稳定性都得考虑。记忆层是Agent从工具变成助手的关键。没有Mem0的时候Agent就是个检索工具每次都从头来。接上之后Agent开始记住你关心什么、不关心什么推送越来越精准。这个差别很大。报告模板决定输出质量。prompt写得再好不如模板定义得清晰。把生成一份竞品周报改成按管线进展、临床数据、专利动态、合作交易四个板块每条不超过2行输出质量直接上了一个台阶。多源检索一定要做去重和格式适配。PubMed和Semantic Scholar的重叠率比想象的高不去重的话周报里同一条信息出现两次很丢人。而且各家返回的数据格式不一样必须先统一格式再做后续处理。核心洞察做了这个项目之后我最大的感受是Agent的价值不是替你检索是替你做情报。检索只是第一步。结构化、判断、呈现、学习——这些串起来才是完整的工作流。很多药企也上了AI工具但是效果不好问题不在工具本身在于只做了点没做链。弄个ChatGPT接口让大家问答这不叫Agent这叫换了个搜索引擎。真正的Agent是一条链它知道去哪找、找到了怎么解析、解析完怎么结构化、结构化完怎么呈现给对的人、呈现完还能记住下次该怎么做得更好。每一步都自动化串起来才有价值。还有一点想说的不要追求一步到位。我见过太多项目死在等我们把架构设计完美了再上线这句话上。我的做法是先跑通最小可用版本——哪怕周报格式丑一点、覆盖范围小一点先让业务方用起来。用起来之后反馈自然就来了迭代方向也就清楚了。从Day 1到Day 10这套系统经历了三版大改每一版都是根据实际使用反馈调的。另外一个心得药企的人其实很愿意接受新工具前提是这个工具真的能帮他们省时间。不要跟业务部门讲什么AI赋能、数字化转型这种空话。你就跟他说这个周报以后半小时就能出你以前花4个小时——他立马就愿意试了。系列预告文献情报解决了但是药企的痛点远不止这一个。100多页的临床方案改一个入组标准样本量、统计方法、安全性章节要联动修改手动检查交叉引用平均遗漏8-12处。下一篇我们用同一套架构给Agent加上长文档理解和参数联动能力。本系列基于真实行业痛点技术方案基于开源工具和通用架构设计可迁移至真实场景。文中涉及的工具选型仅代表个人实践偏好不构成商业推荐。