企业官网建设流程全解析

计算化学和计算材料学的工作流有一个共同特点：真正耗时的从来不是“想”，而是“跑”。一个结构优化任务，准备输入文件、检查参数、投递作业、等结果、解析输出、判断是否收敛，这套动作熟练的人也要折腾十几分钟，不熟练的人可能一整天都卡在某个 INCAR 参数或者 k 点设置上。AI Agent 想切入的正是这一段：把自然语言的需求翻译成可执行的工具调用，把散落在几十个文件里的参数和结果串成一条能自动推进的流水线。

这次我们看的不是一个具体软件，而是一类正在成型的方案：用 Agent 框架去调度计算化学、计算材料学的工具链。核心思路很直接，大模型负责理解意图、拆解步骤、选择工具，真正的数值计算交给 RDKit、ASE、pymatgen、LAMMPS、Quantum ESPRESSO、VASP 这类成熟程序。模型不负责算数，只负责编排。

对读者来说，最关心的几个问题无非是：这东西在普通机器上能不能跑起来、本地部署门槛多高、需不需要显卡、能不能接自己的计算集群、批量任务怎么组织、结果可信度怎么保证。这篇文章会围绕这些点展开，给出可落地的环境准备、工具注册、服务启动、功能验证、接口调用和排错清单。

需要先说明一个前提：这个方向目前没有“一键整合包”式的成熟产品，多数团队是在 LangGraph、AutoGen、Semantic Kernel 这类通用 Agent 框架上自建。所以本文的代码都是模板性质，路径、模型名、软件命令需要按你自己的环境替换，但整体骨架是通用的。

1. 核心能力速览

先给一张表，把这类方案的能力边界说清楚。下表描述的是“AI Agent + 计算化学/材料学工具链”这一整类方案的典型形态，具体数值必须按你选用的模型和软件版本实测。

这张表里最容易被误解的是“显存占用”。很多人会以为 Agent 一定要大显存，其实 Agent 本身只是个循环：调模型、解析输出、执行工具、把结果塞回上下文。真正的显存消耗来自你选的 LLM。如果只是做流程验证，7B 级别的量化模型在消费级显卡上就能跑；如果要做复杂的多步推理和长上下文材料解析，那模型规模和上下文长度会直接把显存顶上去。

另一个容易误解的是“批量任务”。Agent 框架天生是给单次对话设计的，它不会自动帮你管理一千个任务的队列、重试和断点续跑。批量能力必须自己在外层加，这一点在第 6 节会展开。

2. 适用场景与使用边界

2.1 这类方案真正能解决的问题

最典型的落地场景是“参数空间预处理”。比如你要做一批钙钛矿材料的带隙筛选，传统做法是人写脚本枚举组分、生成 POSCAR、批量提交。Agent 在这里的价值是把“帮我生成 A 位为 Cs、FA、MA 组合，B 位为 Pb、Sn 的 12 种结构，并给出每种结构的初始晶格常数估计”这种自然语言需求，直接转成一串工具调用，省掉写脚本的时间。

第二个场景是“文献到参数”。计算化学里大量时间花在读论文、抄参数、复现别人设置的截断能、泛函、色散校正。带文档检索能力的 Agent 可以从 PDF 里抽取方法段落，结构化成配置模板，再由人复核。这类任务容错率高，错了人一眼能看出来，是很好的切入点。

第三个场景是“异常诊断”。计算跑挂了、SCF 不收敛、离子步震荡，Agent 可以读取输出文件末尾几十行，结合知识库给出候选原因和调整建议。注意这里给的是“候选”，最终判断必须由人做。

2.2 明确不适合的场景

第一，不能让 Agent 直接“报数”。大模型会一本正经地编造晶格常数、形成能、带隙值。任何数值都必须来自工具返回，Agent 只做搬运和解释。这一点必须在系统提示词里写死，并在测试阶段专门验证。

第二，不能用 Agent 替代第一性原理计算。它不加速求解器，只加速流程。指望它把 VASP 跑快一倍是不现实的。

第三，涉及商业软件授权时要注意合规。VASP、Gaussian、Materials Studio 这类需要 license 的软件，Agent 只是调用你已经合法持有的可执行文件，不能用来绕过授权限制。跨节点调用还要确认 license 服务器允许的并发数。

第四，数据和成果的合规性。如果你处理的是未公开的实验数据、企业委托的计算任务、含个人信息的样本信息，需要确认数据不会被发送到外部 API。稳妥做法是本地模型 + 内网服务，或者对敏感字段先做脱敏。

第五，涉及新材料配方、药物分子设计等内容时，输出只能作为研究参考，最终结论必须经过实验或高精度计算验证，不能直接用于生产决策。

3. 环境准备与前置条件

3.1 基础环境检查

这类系统对环境的挑剔程度高于普通 Python 项目，因为它要同时满足两个世界的依赖：LLM 侧的 Python 生态和科学计算侧的编译生态。建议用 conda 做隔离，不要混装到系统 Python。

# 基础环境检查，版本号请按实际项目要求调整 python --version conda --version nvidia-smi gcc --version mpirun --version # 创建隔离环境 conda create -n chem-agent python=3.11 -y conda activate chem-agent

Linux 是首选，原因是绝大多数计算化学软件只提供 Linux 版本，且 MPI 并行、作业调度器（Slurm、PBS）都在 Linux 侧。Windows 用户建议用 WSL2 跑服务端，Windows 侧只做浏览器访问。

3.2 依赖分层安装

把依赖分成三层，出问题时好定位：

• 第一层：Agent 框架与 LLM 客户端，纯 Python 包，装错了好恢复。
• 第二层：化学信息学与材料学库，比如 RDKit、ASE、pymatgen，这几个包对编译环境有要求，RDKit 建议走 conda-forge。
• 第三层：外部计算程序，不在 Python 环境里，通过命令行调用。

# 第一层：Agent 框架与 HTTP 服务 pip install fastapi uvicorn pydantic requests # 第二层：化学与材料学工具库，优先用 conda 装 conda install -c conda-forge rdkit ase pymatgen -y # 可选：本地模型推理 pip install vllm # 或者更轻量的方案 # curl -fsSL https://ollama.com/install.sh | sh

如果 RDKit 用 pip 装反复失败，八成是缺少编译工具链或者 Python 版本太新没有预编译 wheel。这种时候不要硬扛，直接退回 conda-forge，能省掉大半天。

3.3 磁盘与端口规划

磁盘空间要分三块算：模型权重、计算工作目录、结果归档。模型权重按你选的规模算，7B 的 fp16 大约十几 GB，量化版本小很多。计算工作目录是真正的空间杀手，一次结构优化可能产生几百 MB 的临时文件，高通量跑起来轻松上 TB。结果归档建议单独挂一块盘。

端口方面，Agent 服务、模型服务、WebUI 各占一个。常见的做法是模型服务 8000、Agent 服务 8080、前端 7860，但这只是习惯，冲突了就换。

# 启动前先确认端口没被占用 ss -lntp | grep -E '8000|8080|7860' # 如果有残留进程，先清理 ps -ef | grep -E 'uvicorn|vllm' | grep -v grep

进程残留是这类项目最常见的问题之一。Agent 在调用长时间计算任务时会挂住，Ctrl+C 之后子进程可能还在跑，下次启动就报端口占用或者 GPU 显存不足。

4. 安装部署与启动方式

4.1 项目结构约定

在写任何代码之前，先把目录结构定下来。这不是形式主义，Agent 项目后期最容易乱的就是文件位置。

chem-agent/ ├── config/ │ ├── agent.yaml # 模型、工具、超时配置 │ └── tools.json # 工具清单 ├── tools/ │ ├── structure.py # 结构解析与转换 │ ├── submit.py # 作业提交 │ └── parse.py # 输出解析 ├── workspaces/ # 每个任务一个子目录 ├── logs/ └── app.py # 服务入口

workspaces按任务 ID 分子目录，每个目录里放输入、输出、日志。这个约定在批量任务阶段会救命，因为 Agent 出错时你只需要看一个目录就能定位问题。

4.2 工具注册与 Agent 启动

Agent 的能力上限取决于你给它注册了什么工具。工具定义要遵守三条：入参有明确类型、出参是结构化的、失败时抛明确异常。不要写“万能工具”，一个大函数里塞十种分支，模型根本选不对。

# tools/structure.py # 结构处理工具示例，实际路径和参数需按项目调整 from pathlib import Path from ase.io import read, write from ase import Atoms WORKSPACE = Path("./workspaces") def convert_structure( input_path: str, output_format: str = "vasp", task_id: str = "default", ) -> dict: """ 将结构文件在常见格式间转换。 input_path: 相对于 workspace 的结构文件路径，例如 "inputs/a.cif" output_format: 目标格式，支持 vasp / cif / xyz """ src = WORKSPACE / task_id / input_path if not src.exists(): raise FileNotFoundError(f"结构文件不存在: {src}") atoms: Atoms = read(str(src)) out_dir = WORKSPACE / task_id / "outputs" out_dir.mkdir(parents=True, exist_ok=True) suffix = {"vasp": "POSCAR", "cif": "out.cif", "xyz": "out.xyz"} if output_format not in suffix: raise ValueError(f"不支持的输出格式: {output_format}") dst = out_dir / suffix[output_format] write(str(dst), atoms, format=output_format) return { "status": "ok", "output_path": str(dst), "natoms": len(atoms), "formula": atoms.get_chemical_formula(), "cell": atoms.cell.tolist(), }

工具函数的 docstring 就是给模型看的说明书，写得含糊模型就会乱传参。返回体一定带status字段，让模型能判断成功还是失败，而不是靠猜。

Agent 主循环的写法各框架不同，这里给一个不依赖特定框架的最小实现思路，用来说明控制流：

# app.py 核心循环示意，需按实际框架替换 import json import re from openai import OpenAI client = OpenAI(base_url="http://127.0.0.1:8000/v1", api_key="local") SYSTEM_PROMPT = """ 你是计算材料学助手。规则： 1. 任何数值、晶格常数、原子数，必须来自工具返回结果，不得自行编造。 2. 只调用已注册的工具，不要虚构工具名。 3. 工具返回 status 不为 ok 时，先解释错误，再决定是否重试。 4. 不要执行未授权的远程连接和文件删除操作。 """ def run_agent(user_input: str, max_steps: int = 8) -> str: messages = [ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": user_input}, ] for _ in range(max_steps): resp = client.chat.completions.create( model="local-model", messages=messages, temperature=0, ) content = resp.choices[0].message.content messages.append({"role": "assistant", "content": content}) # 简化演示：约定模型输出 <tool>{"name":..,"args":..}</tool> m = re.search(r"<tool>(.*?)</tool>", content, re.S) if not m: return content call = json.loads(m.group(1)) result = TOOL_REGISTRY[call["name"]](**call["args"]) messages.append({ "role": "user", "content": f"工具返回: {json.dumps(result, ensure_ascii=False)}", }) raise RuntimeError("超过最大步数，任务未收敛")

temperature=0在这个场景里几乎是必须的。你要的是稳定复现，不是创意。同一句需求跑两次给出不同参数，后面根本没法排查。

4.3 启动服务

# 启动本地模型服务（示例，参数需按显存和模型调整） python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --served-model-name local-model \ --host 127.0.0.1 \ --port 8000 \ --max-model-len 8192 # 另开终端，启动 Agent 服务 uvicorn app:app --host 127.0.0.1 --port 8080

两个服务分开起，好处是模型崩了不影响 Agent 侧的日志，排查时能快速定位是哪一层的问题。如果显存不够，可以把max-model-len降下来，或者换更小的量化模型。

5. 功能测试与效果验证

测试要按照“从简到繁”的顺序推进，每步都确认通过再做下一步。跳过基础测试直接跑复杂任务，出问题根本不知道是哪一环坏的。

5.1 工具调用基础测试

测试目的：确认模型能正确识别工具、传对参数、读懂返回。

输入一句最简单的需求，比如“把 inputs/a.cif 转成 POSCAR 格式”。观察三件事：模型有没有选对工具、input_path和output_format传得对不对、返回后有没有复述原子数和化学式。

判断成功的标准很明确：workspaces/default/outputs/POSCAR文件真实存在，且natoms和formula与源文件一致。用 ASE 自己读一遍交叉验证：

from ase.io import read a = read("workspaces/default/outputs/POSCAR") b = read("workspaces/default/inputs/a.cif") assert len(a) == len(b), "原子数不一致" assert a.get_chemical_formula() == b.get_chemical_formula(), "化学式不一致" print("转换校验通过")

常见失败原因有两个：模型把相对路径写成了绝对路径，或者把格式名写成了POSCAR而不是约定的vasp。前者说明提示词里路径约定没讲清，后者说明工具枚举值没有在描述里列全。

5.2 多步任务编排测试

测试目的：确认模型能拆解需要多个工具串联的任务。

给一个两层需求：“读取 inputs/a.cif，统计元素种类和原子数，然后生成一个 POSCAR。”这需要先解析结构、再转换格式，两次工具调用。

这里重点观察模型的中间状态管理。很多 Agent 在第二步会忘记第一步的结果，重新读一次文件，虽然结果对但浪费时间；更糟的是把第一步的返回值当成字符串硬拼进参数，导致格式错误。

判断成功的标准：日志里出现两次工具调用，第二次的入参来自第一次返回的结构信息，而不是重新读盘。如果模型反复读盘，说明上下文管理有问题，可以考虑把结构摘要（元素、原子数、晶胞参数）作为一条系统消息固定下来。

5.3 数值可信度测试

测试目的：验证模型会不会编造数值。这是整个测试环节最重要的一节。

故意问一个工具无法直接回答的问题：“这个结构的带隙是多少？”正确的行为是模型说明需要执行计算才能得到，并提出调用计算工具或询问你是否已有结果文件。错误的行为是直接给一个数字。

再问一个更隐蔽的：“晶胞体积是多少？”如果工具有体积计算能力，模型应该调用工具；如果没有，应该说不确定。测试时把工具全部禁用再问一遍，如果模型仍然给出具体数字，说明系统提示词的约束没有生效。

这一步不通过，后面所有测试都没有意义。一个会编造带隙值的 Agent，在科研场景里是负资产。

5.4 计算任务提交与结果回读测试

测试目的：打通“生成输入 → 提交 → 等待 → 解析”的完整链路。

先用一个极小的算例，比如一个单胞的能量计算，几秒钟能跑完的那种。不要一上来就跑几百原子的结构优化。

# tools/submit.py 提交逻辑示意，命令需按实际软件替换 import subprocess from pathlib import Path WORKSPACE = Path("./workspaces") def submit_job(task_id: str, workdir: str = "calc", timeout: int = 600) -> dict: """ 在指定工作目录执行计算命令并返回退出码。 task_id: 任务标识 workdir: 相对于 workspace 的计算目录 timeout: 超时秒数，超时会终止进程 """ cwd = WORKSPACE / task_id / workdir if not cwd.exists(): raise FileNotFoundError(f"计算目录不存在: {cwd}") try: proc = subprocess.run( ["your_solver", "input.inp"], # 替换为真实命令 cwd=str(cwd), capture_output=True, text=True, timeout=timeout, ) except subprocess.TimeoutExpired: return {"status": "timeout", "timeout": timeout} return { "status": "ok" if proc.returncode == 0 else "error", "returncode": proc.returncode, "stdout_tail": proc.stdout[-2000:], "stderr_tail": proc.stderr[-2000:], }

注意stdout_tail只截取末尾。计算程序的输出动辄几万行，全塞给模型会直接撑爆上下文，而且大部分是无用信息。截断策略要按软件定制，比如只保留包含 “converged”“energy”“error” 关键字的行。

判断成功的标准：退出码为 0，输出目录里有结果文件，解析工具能读出能量值且数值量级合理。

5.5 长任务与中断恢复测试

测试目的：验证任务跑很久时系统是否稳定。

把超时设成 30 秒，跑一个需要几分钟的任务，观察超时后的行为。理想情况是工具返回status: timeout，Agent 向用户说明超时并给出建议，而不是自己重试十次把机器拖死。

再测一次正常中断：任务跑到一半手动 Ctrl+C，检查子进程是否被清理。这一步经常出问题，进程残留会占用计算节点，批量跑起来很快就堆满。

# 中断后检查残留 ps -ef | grep your_solver | grep -v grep # 必要时按 PID 清理 kill -TERM <PID>

6. 接口 API 与批量任务

6.1 暴露 HTTP 接口

Agent 服务包装成 HTTP 接口之后，才能被外部系统调用：实验室的调度平台、内部的知识库、甚至一个简单的网页前端。

# app.py 中的接口部分 from fastapi import FastAPI, HTTPException from pydantic import BaseModel, Field app = FastAPI(title="Chem Agent Service") class TaskRequest(BaseModel): task_id: str = Field(..., description="任务唯一标识，用于隔离工作目录") instruction: str = Field(..., description="自然语言指令") max_steps: int = Field(8, ge=1, le=20) class TaskResponse(BaseModel): task_id: str status: str answer: str steps: int @app.post("/v1/task", response_model=TaskResponse) def run_task(req: TaskRequest): try: answer = run_agent(req.instruction, max_steps=req.max_steps) except Exception as e: raise HTTPException(status_code=500, detail=str(e)) return TaskResponse( task_id=req.task_id, status="ok", answer=answer, steps=req.max_steps, )

task_id由调用方传入而不是服务端生成，这样批量任务和日志能对上号。生产环境还要加一层校验，防止task_id里出现../之类的路径穿越。

启动后先用 curl 打通一次：

curl -X POST http://127.0.0.1:8080/v1/task \ -H "Content-Type: application/json" \ -d '{ "task_id": "t-0001", "instruction": "把 inputs/a.cif 转成 POSCAR 格式并报告原子数", "max_steps": 6 }'

预期返回里status为ok，answer中提到的原子数与你提前用工具算好的一致。

6.2 批量任务队列设计

Agent 框架不提供队列，需要自己搭。最小可用的批量层包括四件事：任务清单、并发控制、失败重试、结果落库。

{ "queue": { "input_file": "./batch/tasks.jsonl", "output_dir": "./batch/results", "log_dir": "./batch/logs", "max_concurrency": 2, "retry": { "max_attempts": 3, "backoff_seconds": 30 }, "timeout_seconds": 1800 } }

并发数不要设太高。Agent 任务本身会调用计算程序，计算程序又要抢 CPU 和内存，两个 Agent 并发跑两个结构优化，很可能两个都因为内存不足挂掉。先从 1 或 2 开始，观察资源曲线再调。

任务清单用 JSONL，一行一个任务，方便流式读取和断点续跑：

{"task_id": "t-0001", "instruction": "读取 inputs/a.cif，统计元素和原子数"} {"task_id": "t-0002", "instruction": "把 inputs/a.cif 转成 POSCAR"} {"task_id": "t-0003", "instruction": "解析 outputs/relax.out 的最终能量"}

# batch_runner.py 批量执行骨架 import json import time from pathlib import Path import requests CFG = json.loads(Path("config/queue.json").read_text())["queue"] def load_tasks(path: str): with open(path, encoding="utf-8") as f: for line in f: line = line.strip() if line: yield json.loads(line) def run_one(task: dict) -> dict: for attempt in range(1, CFG["retry"]["max_attempts"] + 1): try: resp = requests.post( "http://127.0.0.1:8080/v1/task", json={"task_id": task["task_id"], "instruction": task["instruction"]}, timeout=CFG["timeout_seconds"], ) if resp.status_code == 200: return {"task_id": task["task_id"], "status": "ok", "result": resp.json(), "attempt": attempt} except requests.RequestException as e: err = str(e) else: err = f"http_{resp.status_code}" time.sleep(CFG["retry"]["backoff_seconds"]) return {"task_id": task["task_id"], "status": "failed", "error": err, "attempt": CFG["retry"]["max_attempts"]} if __name__ == "__main__": out_dir = Path(CFG["output_dir"]) out_dir.mkdir(parents=True, exist_ok=True) for task in load_tasks(CFG["input_file"]): record = run_one(task) with open(out_dir / f"{task['task_id']}.json", "w", encoding="utf-8") as f: json.dump(record, f, ensure_ascii=False, indent=2) print(record["task_id"], record["status"])

结果按任务 ID 单独存一个文件，而不是追加到一个大文件里。原因很实际：批量跑到一半中断，单文件写入容易损坏，分文件则最多丢最后一条。断点续跑的逻辑就是启动时扫描results目录，跳过已存在且状态为 ok 的任务。

7. 资源占用与性能观察

这类系统的资源消耗要分两部分看，混在一起会得出错误结论。

第一部分是 LLM 推理。显存占用主要由模型参数量、量化方式、上下文长度决定。上下文长度的影响经常被低估：一次 Agent 循环会不断往 messages 里追加工具返回，跑十几步之后上下文可能上万 token。KV cache 随上下文线性增长，这是显存突然爆掉的常见原因。

观察方法很直接：

# 每 2 秒采一次显存 nvidia-smi --query-gpu=timestamp,memory.used,utilization.gpu \ --format=csv -l 2 # 同时观察 CPU 与内存 pidstat -u -r -p <AGENT_PID> 1

第二部分是计算程序本身。结构优化的内存占用跟原子数、k 点密度、并行进程数强相关。同一台机器上，4 个 MPI 进程和 16 个 MPI 进程的内存占用可能差三倍。

真正需要盯的是两者的叠加。Agent 服务常驻占用一部分内存，模型服务常驻占用一部分显存，计算程序再抢一块 CPU 和内存。三者同时跑，机器很容易进入 swap，速度断崖式下跌。

降低显存占用的几个方向，按性价比排序：

• 降低上下文长度上限。把工具返回的截断阈值调小，别把几万行输出全塞进去。
• 减少 Agent 最大步数。多数任务 8 步够了，给 20 步只是给了模型乱试的空间。
• 换更小的模型或更高压缩的量化。流程验证阶段不需要最强的模型。
• 把长文本解析类任务拆出去，单独用一个小模型做摘要，再喂给主模型。

降低 CPU 侧压力的方向：

• 计算任务的并行度单独配置，不要跟 Agent 并发数耦合。
• 把计算结果文件放独立磁盘，避免和模型权重抢 IO。
• 解析大输出文件时用流式读取，不要read_text()一把梭。

还有一个容易被忽视的点：文件句柄。Agent 每轮都读文件、写日志，批量跑几千个任务时句柄泄漏会让服务在某个时刻突然报 “Too many open files”。用with管理所有文件操作，批量跑之前先看一眼ulimit -n。

8. 常见问题与排查方法

这张表里最值得展开的是“结果数值明显异常”。这个问题的隐蔽性在于它不会报错，只会悄悄产出错误结论。防御手段有两个：一是所有数值强制带来源标记，让模型输出“数值 + 来自哪个工具调用”；二是关键结果用第二个独立工具复算一次，两条路径结果不一致就人工介入。

另一个值得展开的是“SCF 不收敛”。Agent 在这类问题上能帮上忙，但它给的调整建议必须验证。常见的方向包括降低混合系数、增加迭代步数、调整初始磁矩、换更宽松的截断能先收敛再收紧。让 Agent 提出候选方案，人挑一个改，改完再跑，这个循环比让它自动连改五轮要安全得多。

9. 最佳实践与使用建议

第一，先跑通一个最小闭环再扩功能。最小闭环 = 一个工具 + 一次调用 + 一次结果复述。这个通了，再加第二个工具、第三个工具。反过来先搭十个工具再调试，出了问题无法定位。

第二，把提示词当成配置文件管理。系统提示词里写清楚：不能编造数值、只能用已注册工具、失败要报告不要静默重试、涉及文件删除和远程连接必须显式确认。这几条建议固定成模板，每个项目复用。

第三，工作目录按任务隔离，日志按天切分。workspaces/<task_id>/下面分inputs、outputs、logs三个子目录。批量任务出问题时，你只需要进一个目录就能还原现场。

第四，所有工具函数都返回结构化结果，都带status字段。不要用异常穿透到 Agent 层，模型看不懂 traceback，只会盲目重试。

第五，批量任务的并发数从 1 开始。观察一轮资源曲线，再逐步加到 2、3。计算类任务的资源消耗不是线性的，两个并发可能刚好卡在内存边界上。

第六，接口服务限制访问范围。默认绑127.0.0.1，需要对外时加一层反向代理和鉴权，并限制单次请求的最大步数和超时时间。Agent 服务被恶意构造的指令打到死循环，会把整台机器拖垮。

第七，涉及文献全文、实验数据、企业委托内容时，确认数据流向。本地模型最稳妥，外部 API 需要评估合规性，敏感字段先脱敏。

第八，商用或发表前做效果复核。Agent 产出的参数、结构、结论都要经过人工或高精度计算验证。它能提高效率，但不能替代判断。

第九，给计算程序设硬超时。Agent 侧的超时只终止了它自己的调用，计算程序可能变成孤儿进程继续跑。稳妥做法是在提交工具里用进程组管理，超时后连带子进程一起清理。

第十，保留一套“最小可运行配置”。模型、工具、提示词各留一份能跑通的最简版本，放在单独的目录里。后续升级框架或换模型出问题时，用这套配置做对照，能快速判断是环境问题还是代码问题。

10. 写在最后

AI Agent 在计算化学和计算材料学里的定位，目前更像一个熟练的流程执行者，而不是一个能替你做科研判断的合作者。它最擅长的是把重复的、有明确步骤的工作串起来：读结构、转格式、生成输入、投作业、解析结果、整理成表。这些环节做好，一件事能省掉大量机械操作时间。

如果你准备试，建议第一个验证的不是复杂工作流，而是数值可信度。把工具全部关掉，问它一个只有计算才能回答的问题，看它会不会编数字。这一步过了，再往下做工具链；这一步不过，后面全是沙上建塔。

最容易踩的三个坑：一是上下文失控，工具输出不截断，跑几步就 OOM；二是超时和进程管理不到位，任务中断后留下大量孤儿进程；三是把模型输出当结论直接采信，没有做交叉复算。

后续可以扩展的方向不少。工具层可以接更多计算程序，形成从分子到周期性体系的覆盖；调度层可以对接 Slurm 这类作业系统，把 Agent 提交的任务真正投到集群；评估层可以加一套自动化回归测试，每次换模型或改提示词都跑一遍固定用例，观察成功率变化。这三块做完，这套东西才算从演示走向可用，建议收藏备用。