尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

AI Agent驱动新材料发现:通用工程架构与可验证闭环实践

AI Agent驱动新材料发现:通用工程架构与可验证闭环实践 这次 HN 上的 Launch 帖子讨论度不低Discovered MaterialsYC 背景定位是用 AI agents 去发现新材料。硬核方向好在没有落入“又一个人工智能套壳助手”的套路。它把大模型从对话问答往科研工作流推近了一步——检索文献、生成候选材料、调用数据库和模拟工具、最后返回可解释的结果。这篇博客不会假装拿到了官方实现细节目前公开信息能确认的只有项目定位和启动背景。更实际的做法是把材料发现 agent 这类系统需要的通用工程结构拆开数据从哪来、agent 怎么设计、用什么中间工具、哪种验证闭环才可信以及实际跑起来要看哪些指标。适合三类读者在做 LLM agent 应用开发的、在做材料或化学信息学的、以及想判断 AI for Science 到底能落到哪一层的人。1. 核心能力速览先给一张速览表把能确认和需要保持不确定的信息分开。能力项说明项目名称Discovered Materials项目背景YC 批次项目通过 Hacker News 发布 Launch 帖子项目方向AI agents 新材料发现核心能力按定位推断候选材料推荐、文献/数据库检索、模拟计算工具调用、生成可解释结论是否开源公开信息未确认不能默认可二次开发一键启动无公开一键包未确认是否提供 WebUI 或 CLI接口 API未公开不能编造调用路径批量任务材料筛选场景天然适合批量扫描但需以官方能力为准推荐硬件不确定取决于背后用的模型和模拟工具离实验验证的距离AI 推荐只是起点最终要靠模拟和高通量实验复核表格里的信息刻意做了收敛。因为 Launch 帖子只有项目名称、赛道定位和团队背景任何具体参数都需要官方文档确认。下面所有工程内容按照“材料发现 agent 当前主流工程方式”来展开并不是对特定产品的实测。2. 适用场景与使用边界AI agent 发现新材料解决的本质问题是科研流程的“多步信息处理”研究人员通常要从文献里抽数据、从数据库里比对已知结构、用模拟工具预测性能再决定合成哪些样品。这个流程重复、繁琐、跨度大agent 的价值在于把多步工具调用串起来让大模型承担“调度者”和“假设生成者”的角色。适合使用的场景有三类第一候选材料初步筛选。给定目标性能比如高离子电导率、高容量、热稳定温度超过某个阈值agent 可以按知识库和数据库约束先生成一批结构描述或化学式候选。第二文献信息聚合。材料领域文献量很大agent 可以做检索、抽取、对比把“某类氧化物在什么温度下表现出什么性能”这类分散信息整理成结构化结果。第三与计算工具联动。把第一性原理计算、分子动力学、热力学计算等命令行工具封装成 agent 可调用的函数实现“生成结构 - 提交计算 - 读取结果 - 调整候选”的循环。不适合的场景也要说清楚。AI agent 不能替代实验验证不能保证生成的材料真实可合成也不能把模拟结果直接当作工业量产性能。材料发现链条很长agent 负责的是“缩小搜索空间”而不是“自动造出能用的材料”。涉及化工、医药、能源等下游应用时合规边界更严格生成的内容必须经过专业复核和实验确认。3. 材料发现 Agent 的通用技术栈与环境准备这里不写具体产品的安装方式而是给出搭建一个“材料发现 agent”通常需要的技术环境。目标用户如果想复现类似能力可以按这份清单准备。3.1 运行环境基础建议使用 Linux 服务器或 WSL2 环境Python 3.10 以上包管理用 conda 或 venv。如果只做 API 层的 agent 调度不跑本地模拟一台 16G 内存的 CPU 机器就能跑通如果涉及第一性原理计算或机器学习势函数则需要 GPU 和对应 CUDA 环境。需要安装的基础依赖包括# 通用环境准备示例 conda create -n materials-agent python3.10 -y conda activate materials-agent pip install requests pandas numpy httpx3.2 材料数据库访问材料发现 agent 最关键的“知识来源”是数据库。目前材料科学领域常用的公开数据库包括Materials Project 提供材料结构、热力学稳定性、带隙等计算数据支持 REST API 和 Python SDK。OQMD开放量子力学数据库覆盖大量 DFT 计算结果。ICSD无机晶体结构数据库但通常是订阅制。PubChem / ChemSpider化学结构与基础性质查询。要调用 API一般需要先申请访问令牌比如 Materials Project 需要注册账号并生成 API Key。这个 Key 要放到本地环境变量里不要写进代码仓库。export MATERIALS_PROJECT_API_KEYyour_key_here3.3 大模型服务接入agent 的“大脑”通常是一个大语言模型。可以选择 OpenAI、Anthropic、国产大模型、或者本地部署的开源模型。材料发现场景对推理准确率要求较高建议使用支持 function calling 的模型这样 agent 才能在对话中真实触发数据库查询。export LLM_API_KEYyour_llm_key_here export LLM_BASE_URLhttps://your-llm-endpoint.example.com3.4 工具封装准备如果 agent 需要调用模拟软件比如 Quantum ESPRESSO、VASP、LAMMPS必须先把这些软件装好并确认命令行入口。问题在于模拟软件版本和编译方式差异很大不可能覆盖所有环境。最合理的做法是先用一个“占位脚本”模拟测试跑通 agent 调度链路后再替换成真实软件命令。4. 最小可用 Agent 骨架搭建先给一个能跑通的最小闭环演示。它不是用来替代 Discovered Materials 的而是用来理解材料发现 agent 的调度逻辑。整个流程分三步定义工具、让模型决策、返回结果。核心思路是agent 不是让大模型直接编一个材料出来而是让它调用工具查询数据库再基于结果给出推荐。4.1 定义查询工具用 Materials Project 官方 SDK 写一个查询函数输入化学式输出材料的基础结构信息和稳定性参数。import os from mp_api.client import MPRester API_KEY os.environ.get(MATERIALS_PROJECT_API_KEY) if not API_KEY: raise ValueError(请先设置 MATERIALS_PROJECT_API_KEY 环境变量) def query_materials(formula: str, limit: int 5): with MPRester(API_KEY) as mpr: docs mpr.materials.summary.search( formulaformula, fields[material_id, formula_pretty, energy_above_hull, band_gap], ) result [] for doc in docs[:limit]: result.append({ material_id: doc.material_id, formula: doc.formula_pretty, band_gap: doc.band_gap, energy_above_hull: doc.energy_above_hull, }) return result这个函数做的是“真实性检查”你说某个化学式可能存在我先去数据库里查它是否存在、结构是否稳定。注意band_gap、energy_above_hull的字段名以你安装的 SDK 版本为准。不同版本命名可能有差异运行时报错就按提示调整参数名。4.2 用 LLM 生成候选材料写一个通用的 LLM 调用函数让它根据目标任务产出候选化学式。这里不绑定具体模型只给调用框架。from openai import OpenAI client OpenAI( api_keyos.environ.get(LLM_API_KEY), base_urlos.environ.get(LLM_BASE_URL), ) def generate_candidates(target_property: str, model: str your-model-name): prompt ( 你是一个材料信息学研究助手。请根据目标性能给出 3 种候选材料体系 每种材料用化学式表示并说明推荐理由、可能的晶体结构类型、潜在风险。\n f目标性能{target_property}\n 要求优先选择已有数据库或文献支持的材料不要编造不存在的化学式。 ) resp client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], temperature0.3, ) return resp.choices[0].message.content这里model和base_url需要按你的实际服务替换。如果用的是 OpenAI 官方接口就把base_url去掉。4.3 完成 Agent 循环把“生成候选”和“数据库校验”串起来就是一个最简单的 agent。import json import re def extract_formulas(text: str): # 简易提取代码块或文本中类似化学式的子串实际场景需要更严谨的解析 return re.findall(r([A-Z][a-z]?\d*(?:[A-Z][a-z]?\d*)*), text) def run_agent(target_property: str): print(f[1] 目标性能{target_property}) response_text generate_candidates(target_property) print([2] LLM 生成候选) print(response_text) formulas extract_formulas(response_text) print([3] 数据库校验) for formula in formulas[:5]: db_result query_materials(formula) if db_result: print(f {formula}: 数据库存在 {len(db_result)} 条记录) for item in db_result[:2]: print(f - {item}) else: print(f {formula}: 未查到匹配记录需要人工判断)这段代码并不完美化学式提取规则在实际场景中非常容易出错。但它足够演示“LLM 生成 - 工具校验 - 输出结构化信息”这个闭环。真正生产级系统需要用更严格的结构化输出协议让模型返回 JSON而不是从自由文本里抠化学式。5. 功能测试与效果验证有了骨架之后关键是验证 agent 是不是真的在工作。材料发现 agent 的验证逻辑和普通聊天机器人不一样不能只看“生成的文本通顺”要看“生成结果是否有可追溯的事实依据”。5.1 测试一候选材料生成输入一个目标性能看 LLM 是否给出具体化学式而不是空泛描述。if __name__ __main__: run_agent(寻找一种用于固态电池的高离子电导率硫化物材料)判断成功标准返回结果中包含明确的化学式或材料体系。每个候选都附带了推荐理由。推荐理由不依赖“可能有”这类模糊表述而是提到已知结构类型或文献基础。如果输出全是“可以考虑某类材料”而没有具体化学式说明模型没有按约束执行需要强化 prompt 中的输出格式约束。5.2 测试二数据库真实性校验这是材料 agent 最关键的测试。LLM 回答的化学式可能并不存在数据库校验可以把这一步兜住。上面代码执行后如果输出里出现“未查到匹配记录”不代表 agent 失败而是代表它把不确定的候选单独标记出来了下一步可以进入文献检索或人工复核流程。这才是正确行为而不是把不存在的东西当结论输出。5.3 测试三模拟工具调用闭环如果项目需要对接第一性原理计算可以先用一个假脚本测试调度逻辑。# 模拟脚本实际应替换为 QE/VASP/LAMMPS 调用命令 echo structure relax calculation started run.log sleep 2 echo total energy -12.345 eV run.logagent 调度时只需要把“运行脚本 - 读取 run.log - 解析能量值”封装成工具函数。判断成功标准脚本被正确调用日志被正确解析解析结果能被模型当成下一轮推理依据。这个逻辑跑通后再替换成真实计算命令。5.4 测试四可复现性同一个 target_property 连续跑 3 次如果每次返回的候选材料差异很大说明稳定性不够。材料发现场景里温度参数不要设太高一般建议 0.2 到 0.4必要时把 seed 固定下来。resp client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], temperature0.2, )5.5 失败排查思路失败表现可能原因排查方向LLM 返回非结构化文本prompt 缺少输出约束改用 function calling 或规定 JSON 输出数据库查询报 401API Key 未生效或已过期检查环境变量和服务商账号状态数据库查不到候选化学式提取失败查看正则提取结果改用结构化输出模拟脚本执行后没生成日志工作目录或权限问题检查脚本路径、执行权限、输出重定向重复运行结果差很多temperature 过高降低温度固定 seed6. 接口 API 与批量任务材料发现场景最适合批量任务。“找一种候选”只是单点查询实际研发需要的是扫描一个成分区间、多个目标性能或多种合成路径。批量任务需要一个明确的任务队列和统一的输出格式。6.1 通用批量扫描示例把前面两个函数组合成一个批量任务脚本targets [ 高离子电导率的锂硫化物固态电解质, 高温稳定的钙钛矿型催化剂载体, 高容量层状氧化物正极材料, ] def batch_run(targets_list): all_results {} for i, target in enumerate(targets_list, start1): print(f[任务 {i}/{len(targets_list)}] {target}) try: output run_agent(target) all_results[target] output except Exception as exc: all_results[target] {error: str(exc)} print(f 失败{exc}) return all_results result batch_run(targets) with open(batch_result.json, w, encodingutf-8) as f: json.dump(result, f, ensure_asciiFalse, indent2)判断成功标准每个任务都有输出失败任务被单独记录。结果文件是一个可被后续程序读取的 JSON。单任务失败不会中断整个批次。建议在真实项目里加入重试机制。LLM 接口偶尔超时、数据库偶尔返回空值重试两到三次能显著提高批次成功率import time def call_with_retry(func, *args, retries3, delay2, **kwargs): for attempt in range(retries): try: return func(*args, **kwargs) except Exception as exc: print(f第 {attempt 1} 次调用失败{exc}) if attempt retries - 1: raise time.sleep(delay)6.2 输出格式规范材料 agent 的输出不应该是一段自然语言而应该是一个结构化的候选列表。推荐格式{ target_property: 高离子电导率硫化物固态电解质, candidates: [ { formula: Li3PS4, structure_type: thio-LISICON, confidence: medium, database_status: exists, reason: 已有实验和计算文献支持离子电导率存在提升空间 } ], generated_at: 2025-01-01T10:00:00Z }这个格式便于后续接入自动筛选、可视化排序和人工复核。判断一个材料发现 agent 是否专业看它返回的是“一段话”还是“结构化候选记录”就够了。6.3 API 服务化如果要做成 Web API可以用 FastAPI 起一个简单服务。需要说明的是这不是 Discovered Materials 的官方接口只是一个通用模板。from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class TargetRequest(BaseModel): target_property: str batch_size: int 3 app.post(/discover) def discover(req: TargetRequest): results [] for _ in range(req.batch_size): candidate generate_candidates(req.target_property) results.append(candidate) return {target: req.target_property, results: results}启动方式uvicorn app:app --host 127.0.0.1 --port 8000服务化之后前端、实验自动化系统、数据看板都能接入。但要注意API 服务不要直接暴露到公网至少要加访问令牌和限流防止被滥用。7. 资源占用与性能观察材料发现 agent 的资源占用主要集中在三个地方LLM 推理、数据库请求、模拟计算。7.1 LLM 推理成本如果使用云端大模型接口主要成本是 token。一次候选材料生成可能需要 1000 到 3000 token批量任务就是线性增长。如果使用本地模型则需要关注显存。7B 级别模型量化后大约需要 6G 到 8G 显存13B 级别通常要 12G 以上。具体以模型版本和量化方式为准。观察方式很简单本地部署时用nvidia-smi看显存占用云端接口则在服务商控制台看 token 用量。watch -n 1 nvidia-smi7.2 数据库请求频率材料数据库 API 通常有频率限制。批量扫描时不要用 for 循环疯狂请求建议加上必要延时。前面call_with_retry里的delay2就是基础限流。7.3 模拟计算资源第一性原理计算对资源需求差异非常大。一个小体系可能在普通工作站 CPU 上跑几十分钟一个复杂掺杂体系可能需要高性能集群。在 agent 接入模拟计算时必须做资源预估先跑一个小体系验证输入格式再提交大任务。不要让 agent 直接提交一个需要 200 核跑一周的任务那会把预算瞬间烧光。7.4 进程与端口管理API 服务化后容易遇到的问题就是端口残留。启动前检查端口占用# Linux / macOS lsof -i :8000 # Windows netstat -ano | findstr :8000如果端口被占用换一个uvicorn app:app --host 127.0.0.1 --port 80018. 常见问题与排查方法材料发现 agent 项目最典型的问题不在模型能力而在工程链路。问题现象可能原因排查方式解决方案LLM 调用超时网络问题或模型服务负载高查看模型服务日志增加超时时间并做重试数据库返回数据为空化学式不在数据库覆盖范围手动在网站查询验证增加文献检索或人工复核路径模型生成不存在的材料模型幻觉对比数据库记录强制让模型引用数据库结果再回答批量任务中途中断单任务异常未捕获检查异常日志给每个任务加 try-except 和断点续跑模拟计算无法收敛输入结构或计算参数不合理查看模拟输出文件降低计算精度或简化初始结构输出结构不统一没有使用结构化输出检查原始输出改用 function calling 或 JSON Mode显存不足本地模型太大查看 nvidia-smi换小模型或使用量化版本API 端口被占用服务未正常关闭检查监听端口结束残留进程或更换端口其中“模型生成不存在的材料”是最需要重视的问题。材料发现 agent 的底线是所有生成结果都要能回指到数据库记录或文献来源否则就是无效信息。这个校验逻辑必须在 agent 内部不能靠用户事后判断。9. 最佳实践与使用建议9.1 先跑通小闭环再追求广覆盖第一次搭建不要直接做全流程。先只接一个数据库 API让模型能查询一个化学式再把验证结果打印出来。这个最小闭环跑通后再加入文献检索、批量任务、模拟计算逐步扩展。9.2 数据可溯源材料发现 agent 的输出一定要带来源。来自数据库的要带上 material_id来自文献的要带上标题和 DOI来自模型推理的要明确标注“未经实验验证”。可溯源意味着结果可复核这比自然语言通顺重要得多。9.3 分目录管理模型任务建议把输入材料、日志和输出分离materials-agent/ inputs/ # 任务清单、目标性能文件 logs/ # 每次运行的日志 outputs/ # 结构化结果 JSON cache/ # 数据库查询缓存缓存数据库查询结果能显著降低 API 成本和响应时间批量扫描时尤其有效。9.4 合规与安全边界材料发现涉及多个合规点数据库使用要遵守各自的许可协议材料和化学数据不是所有来源都能自由商用。涉及专利布局、企业研发数据、未公开结构时要注意数据安全和保密协议。涉及催化剂、医药分子、能源材料等应用方向生成结果不能直接用于生产决策必须经过实验验证和专业人员审核。模型生成的“新材料”如果被用于商业开发需要确认知识产权归属和数据库的引用要求。9.5 日志与失败重试批量任务必须设计断点续跑。每次运行完成后把已处理任务标记为 completed下次启动时跳过。这能避免大批量任务在中途因为单点失败而全部重跑。10. 总结与下一步Discovered Materials 这个 Launch 帖子价值在于把一个高门槛科研方向拉到 agent 应用的视野里。材料发现不是靠“问大模型”就能完成的它需要 agent 能查询数据库、调用模拟工具、然后基于结构化结果提出可验证的假设。这种多工具闭环才是 AI for Science 真正落地的形态。如果你对这个方向感兴趣最先要验证的不是某个复杂模型而是三个基础能力数据库查询能不能跑通LLM 能不能稳定输出结构化候选模拟工具能不能被 agent 调度起来。这三步一旦串起来后续加批量扫描和文献检索就是工程扩展问题。最容易踩的坑是跳过校验环节让模型直接输出“看起来对”的化学式。先把可溯源这条底线守住再谈发现新材料这种宏大目标。下一步可以考虑从开源数据和通用 agent 框架切入先搭一个内部原型把“目标性能 - 候选材料 - 数据库校验”这条链路跑通。等这个循环稳定了再决定是接入模拟计算还是扩展到自动化实验设备。这个方向目前缺的不是模型能力而是稳定、可复现、可追溯的工程链路。
返回列表