1. 为什么是“仿真智能体”TCAD领域那些年我们吃过的苦先讲一个我观察过很多次的场景。器件工程师接到一个新结构验证任务比如评估一种新型高K栅介质对FinFET短沟道效应的影响。按传统流程他先翻文献找到近似的结构参数然后在TCAD工具里手动搭网格、设掺杂分布、选物理模型跑一轮静态特性仿真把I-V曲线导出来用脚本提取阈值电压、亚阈值摆幅、DIBL系数再和上一版结果对比。这一轮下来顺利的话半天不顺利的话——比如不收敛、网格畸变、材料模型不匹配——一整天就搭进去了。而这只是一个分支后面还有变分扫描、温度扫描、可靠性验证。这个场景里真正吃时间的不是“求解薛定谔方程”或“解漂移扩散方程”本身而是两件事喂参数和读结果。喂参数是指把一个物理概念转化为仿真器能接受的具体数值组合。工程师脑子里想的“一个28nm节点、低掺杂沟道、倒梯形鳍”对应到TCAD里是几十个坐标点、掺杂浓度、热预算、应力模型开关。这些参数之间的耦合关系非常复杂老工程师靠经验能快速给出初始值但新人往往会卡很久。读结果则更依赖领域语义理解——曲线出来了但这条曲线是否物理合理这个拐点是数值噪声还是真实的击穿前兆该调栅氧厚度还是调源漏注入剂量当前工具链缺少一个能把这套“经验语义”自动化、产品化的层。AI智能体切入的机会就在这里。它不是替代仿真求解器而是把“人围着仿真转”变成“仿真围着语义转”。工程师用自然语言描述目标智能体负责拆解意图、检索历史案例、生成仿真配方、调度仿真任务、判读结果、给出下一步建议。本质上是把老工程师的“手艺”沉淀成一套可复用的系统能力。我在这篇文章里要讲的就是我自己搭建这样一套“半导体器件仿真AI智能体系统”的完整过程。包括架构怎么分层、模型怎么选、工具怎么封装、结果怎么让Agent自动判读、部署时有哪些坑。这不是PPT层面上的概念设计是我在一个研发环境里真正跑起来、并且让器件组同事愿意日常使用的版本。适合正在做AI Agent落地、但又不想只做“聊天机器人”的工程师参考也适合半导体行业里想引入AI能力但不知道从哪下手的团队。2. 系统架构从LLM到仿真工具的调用链路设计2.1 整体分层不要让大模型直接碰仿真器我见过不少团队做AI仿真助手一开始就把各种仿真工具直接用function calling暴露给大模型让模型自由调用。结果就是模型偶尔会传错参数格式甚至把工作目录里的文件路径猜错导致仿真器报一堆晦涩错误。本质上大模型不适合直接操作底层工具它擅长的是语义理解和任务编排。我最终采用的分层结构如下表每一层只依赖下一层不能越级层级职责关键技术选择交互层接收自然语言需求、展示结果与建议Web UI / 命令行交互流式输出编排层意图识别、任务分解、多步骤调度、人工审核Agent循环 任务队列 状态机知识层检索器件物理、工艺文档、历史仿真案例向量数据库 RAG 元数据过滤工具层统一封装仿真工具、参数扫描、结果解析标准化Tool接口JSON输入输出模型层提供LLM推理能力本地vLLM部署 / 内部API支持工具调用仿真层真正执行TCAD/FDTD等数值计算Sentaurus / Silvaco / 自研求解器这个架构最关键的决定是把“工具层”单独抽出来做标准化。所有仿真器在接入系统之前必须先封装成统一的Tool接口输入输出全部是结构化JSON。大模型只能通过这套接口间接控制仿真工具不允许直接拼命令行。这样做有几个好处。一是安全性模型给出的命令不会直接在仿真机上执行避免了误删文件或跑飞任务二是可观测性每一次工具调用都有完整记录出了问题能做到审计回溯三是可替换性今天底层用Sentaurus明天想换Silvaco只需要改工具层的适配器上游的Agent逻辑完全不用变。2.2 模型选型本地部署还是API不是成本问题而是数据主权问题模型选型这件事我踩过不少弯路。一开始图省事直接用外部API接口调通了、对话效果也不错但到了真正接器件仿真数据的时候被叫停了。原因是晶圆厂和流片相关的参数属于内部敏感数据不能出内网。这就导致我不得不转向本地部署方案。如果你所在的团队没有严格的数据合规要求或者仿真数据不涉密那直接调用成熟API确实省事。但对半导体研发场景我建议从一开始就评估本地部署路线否则后面再做迁移会很痛苦。本地部署的核心是选基座模型和推理框架。我实测过几套方案的差异列在下面供参考模型量化方案显存占用工具调用能力中文领域理解Qwen2.5-72B-InstructAWQ 4bit约40GB强支持多轮function calling很好半导体术语识别准确Qwen2.5-32B-InstructGPTQ 8bit约36GB较强偶尔少传参数较好DeepSeek-R1-Distill-Qwen-32BAWQ 4bit约22GB强但推理链较长会拖慢响应好但需要更长超时Llama-3.1-70BAWQ 4bit约40GB中等需要更多few-shot引导英文表现好中文术语稍弱我最终选了Qwen2.5-72B的AWQ 4bit版本在两张RTX 4090上跑vLLM配合OpenAI兼容接口接入Agent框架。推理吞吐大概能到每秒20到30个token对内部工具使用足够。用vLLM部署的配置大致如下model: Qwen/Qwen2.5-72B-Instruct-AWQ served_model_name: qwen72b tensor_parallel_size: 2 gpu_memory_utilization: 0.9 max_model_len: 32768 enforce_eager: true这里有个细节容易被忽略max_model_len要设得足够长。半导体仿真场景下的对话上下文会一直叠加工具返回结果、仿真日志摘录、数值表格如果模型窗口不够大早期的关键信息会被截断Agent会“失忆”。32K起步有条件的直接上64K。2.3 工具层设计把仿真工具变成Agent手里的一台“数字仪表盘”工具层是整个系统里最需要花心思的地方。我的设计思路是把每个仿真能力封装成一个“虚拟仪器”Agent像实验员操作仪器一样操作这些封装好的工具。举个例子一个标准的“执行IV特性仿真”工具它的Schema定义如下{ name: run_iv_simulation, description: 基于给定的器件结构文件和物理模型配置执行直流I-V特性仿真返回曲线文件和关键电学参数, parameters: { type: object, properties: { structure_file: { type: string, description: 器件结构描述文件路径由create_structure工具生成 }, model_config: { type: object, description: 物理模型配置如开启量子修正、碰撞电离等, properties: { quantum_correction: {type: boolean}, impact_ionization: {type: boolean} } }, bias_range: { type: object, description: 扫描偏压范围, properties: { gate_start: {type: number}, gate_stop: {type: number}, gate_step: {type: number} } } }, required: [structure_file, bias_range] } }注意description字段里明确写了“由create_structure工具生成”这是刻意为之的目的是引导Agent在执行仿真之前先完成结构建模形成正确的工具调用顺序。后来我还在系统里加了工具调用顺序校验如果Agent跳过了上一步直接调用仿真编排层会拦截并提示它先完成前置操作。工具层的返回值也必须高度结构化。统一格式是{ status: success, output_files: [/results/iv_curve_vg_0.5v.csv], extracted_metrics: { threshold_voltage_vth: 0.312, subthreshold_swing_mv_dec: 68.5, dibl_mv_v: 42.3 }, warnings: [convergence_tolerance_relaxed_at_high_vg], logs_summary: 收敛正常在高栅压区域启用了默认的Newton阻尼策略 }把仿真日志压缩成一个summary字段交给模型而不是把几百行原始日志塞进上下文这能显著降低token消耗也能避免模型被日志里的噪声干扰。3. 核心模块实现意图解析、知识检索与参数映射3.1 从“用户一句话”到结构化仿真配方用户说“帮我仿真一个沟道长度32nm、栅氧厚度1.2nm、鳍高45nm的FinFET看看阈值电压和漏电流”这句话要变成仿真器能执行的东西中间隔着很多步结构文件生成、网格划分、材料参数赋值、物理模型选择、偏压设置、求解器配置。我设计了一套“配方生成”机制让模型先把用户需求解析成结构化的JSON配方再由下游的模板渲染器把它转换成具体的仿真输入卡。配方的Schema长这样{ intent: simulation, device_type: finfet, geometry: { channel_length_nm: 32, gate_oxide_thickness_nm: 1.2, fin_height_nm: 45, fin_width_nm: 8 }, doping_profile: { channel_doping_cm3: 1e17, source_drain_doping_cm3: 1e20, halo_doping_cm3: 5e18 }, physics: { model: drift_diffusion, quantum_correction: true, mobility_model: masetti, recombination: srh }, bias_sweep: { type: iv_transfer, vg_start_v: 0, vg_stop_v: 0.8, vg_step_v: 0.05, vd_fixed_v: 0.8 } }为了让模型稳定产出这种结构化内容我用的是“约束解码Schema校验”的组合。模型输出JSON之后系统先用Pydantic做严格校验发现字段缺失或者数值越界就自动回退让模型重写最多重试三次。这一套下来配方解析的成功率从最初的82%提到了96%以上。3.2 提示词约束与少样本设计半导体术语里藏着很多语义陷阱半导体领域的术语坑比我预想的多得多。比如“耗尽”在器件物理里指载流子耗尽区在工艺语境里可能是指源漏耗尽再比如“击穿”可能是雪崩击穿、隧穿击穿或热击穿对应的物理模型和偏压条件完全不同。如果提示词不做约束模型很容易按通用语义理解。我维护了一套领域术语映射表在系统提示词里明确告诉模型当你说“击穿”时必须判断具体的击穿类型并回填到physics.model字段当用户给的尺寸参数缺少单位时默认按纳米处理掺杂浓度如果没有显式单位默认是atoms/cm^3。少样本示例里我放了几个典型的对话模板。举一个有用的例子用户帮我看看这个器件的亚阈值特性沟道掺杂是不是太高了 助手工具调用链 1. knowledge_query(subthreshold_characteristics_optimization) 2. create_structure(geometry{...}, doping_profile{...}) 3. run_iv_simulation(bias_sweep{type:transfer, vg_start:-0.3, vg_stop:0.8}) 4. analyze_subthreshold_region(vth, subthreshold_swing) 5. 输出结论当前掺杂下亚阈值摆幅为XX mV/dec建议将沟道掺杂降低到XX cm^-3并提示该改动可能对短沟道效应产生的影响。这个例子教会了模型几件事先检索知识库再动手亚阈值分析要重点关注亚阈值摆幅和阈值电压的提取给建议时要同时说明权衡关系。这比单纯在提示词里写“请给出优化建议”要管用得多。3.3 RAG知识库把器件物理与工艺经验真正接入对话知识库是让这个智能体从“通用大模型仿真聊天”变成“领域仿真助手”的关键一环。我构建知识库时主要采集了三类数据一是公开的器件物理教材和TCAD工具手册二是团队内部沉淀的历史仿真报告和实验数据总结三是经过清洗的文献摘要。这三类数据在向量化之前都做了统一的元数据标记包括来源类型、时间戳、工艺节点、器件类型。检索时采用了混合策略先按语义相似度召回Top 20再用元数据过滤掉不符合当前工艺节点或器件类型的文档最后重排取Top 5作为上下文。举例来说用户问的是“FinFET的量子效应修正”那么知识库里针对Planar器件的文档即便语义相似度很高也会因为器件类型不一致被过滤掉。这里给一个非常具体的建议知识库切块的粒度不要用固定字数。对于工艺手册里的参数表格整表作为一个切片对于仿真报告按章节加小标题切块对于公式和物理模型描述尽量单独成块。固定500字硬切会把表格拆碎导致检索到的片段缺失关键参数列模型回答的准确性会明显下降。我还加了一层“版本可信度”机制。每个知识片段都带creation_date和valid_until字段检索时如果命中过期的工艺参数比如某节点的标准工艺已于两年前变更系统会在回答里自动追加提示告诉用户这条信息来自历史版本。4. 仿真执行与结果自动判读让Agent具备“手”和“眼”4.1 仿真任务执行器从subprocess到带监控的状态机工具层的仿真执行器不能只是简单的subprocess调用。半导体仿真任务的特点是耗时、不规则、容易卡死。一个普通的二维TCAD仿真可能跑几十分钟三维器件仿真甚至要数小时。如果执行器没有完善的监控和超时机制任何一次非收敛挂起都会把Agent循环卡死。我封装了一个仿真任务状态机包含pending、running、converged、failed、timeout、rejected六个状态。核心执行逻辑用Python实现关键部分长这样class SimExecutor: def __init__(self, timeout1800, poll_interval10): self.timeout timeout self.poll_interval poll_interval def run(self, cmd, workdir, env_varsNone): process subprocess.Popen( cmd, cwdworkdir, env{**os.environ, **(env_vars or {})}, stdoutsubprocess.PIPE, stderrsubprocess.STDOUT, textTrue ) output_buffer [] start_time time.time() last_checkpoint None while True: line process.stdout.readline() if line: output_buffer.append(line) if CONVERGED in line: last_checkpoint converged elif ERROR in line or DIVERGED in line: last_checkpoint failed elif process.poll() is not None: break else: if time.time() - start_time self.timeout: process.kill() return SimResult( statustimeout, logs.join(output_buffer[-200:]), checkpointlast_checkpoint ) time.sleep(self.poll_interval) return SimResult( statuscompleted if process.returncode 0 else failed, logs.join(output_buffer[-200:]), checkpointlast_checkpoint )日志解析不能只依赖进程退出码。很多TCAD工具即使加了-error参数退出码也可能是0但日志里其实写着“DIVERGED AT STEP 52”。所以我额外做了一层关键词扫描实时把日志中的关键状态抽出来同步到状态机里这样Agent可以在任务运行过程中就感知到进展而不是等到结束才拿到结果。4.2 结果判读不在提示词里让模型“看曲线”而是先提取特征再解读最开始做结果分析时我直接把CSV曲线数据丢给大模型让模型“分析这条I-V曲线的特性”。效果很差。模型虽然能说出一些看起来专业的术语但它无法精确识别曲线里的拐点也不能准确算出亚阈值摆幅。大模型本质上是语言模型不是数值计算器。后来我把结果判读拆成了两个步骤。第一步用numpy/scipy做数值特征提取第二步把提取出的特征交给LLM做语义解读。数值特征提取层面我写了一套算法集阈值电压Vth提取用恒定电流法如10nA×W/L或线性外推法两条曲线对比时两种方法结果都输出避免单一方法偏差。亚阈值摆幅SS在亚阈值区内对log(Id)-Vg曲线做线性拟合取倒数乘以ln10。DIBL系数在Vd0.05V和Vd0.8V两种条件下分别提取Vth做差值。击穿电压BV在反向偏压扫描中找到电流密度达到1μA/μm对应的电压。开关比Ion/Ioff取VgVDVdVD时的饱和电流除以Vg0时的泄漏电流。这些数值提取出来之后再拼成一个结构化的“特征摘要”交给模型。模型基于这些数值做判断的时候出错率大幅下降因为不需要它自己读数它只需要基于明确的数值做定性或半定量的分析。举一个实际跑通的例子。模型拿到特征摘要后给出的判读结论是该器件在Vd0.05V下的阈值电压约0.31VVd0.8V下约0.27VDIBL约42mV/V短沟道效应控制较好。但亚阈值摆幅达到68.5mV/dec与理想值60mV/dec差距明显建议检查栅氧/沟道界面态密度或栅金属功函数匹配情况。这种回答方式就是数值特征提取和语义解读分工的最佳效果。4.3 迭代优化循环自动搜索加人工审核的双轨模式系统里最让器件组同事兴奋的功能是“自动迭代优化”。用户给定目标比如“把阈值电压调到0.3V附近同时保持亚阈值摆幅低于70mV/dec”Agent会自行决定调整哪些工艺参数跑多轮仿真逐步逼近目标。这个功能的实现借鉴了自动机器学习的思路但做了适合仿真场景的调整。Agent在每轮迭代中会给出参数调整建议但调整步长由一个独立的优化引擎控制而不是让模型直接给出新值。为什么这么做因为模型对数值的敏感度有限它可能建议把沟道掺杂从1e17调到5e16这个方向没错但步长有时候过于激进。我引入了一个参数约束模块把每个可调参数的取值范围和最大步长预先定义好模型的建议如果超出了步长限制会自动按最大步长“压缩”到允许范围内。优化循环每完成一轮会把仿真结果和当前最优解对比并用LLM生成一份“本轮调整说明”记录调整了哪些参数、理论依据是什么、结果变化如何。这些说明被追加到对话上下文中让用户能完整追踪Agent的决策过程。考虑到仿真任务耗时自动迭代在默认情况下不无限跑。我设了一个终止条件三层判断达到目标容差、超过最大迭代轮数默认6轮、或者连续三轮结果无显著改善。三层任意满足Agent就会停下来输出一份迭代总结报告。整个自动迭代过程处于“人工在环”模式下。每一轮仿真任务启动前都会在界面上生成一个待确认卡片工程师可以接受、修改或拒绝Agent的参数建议。实测下来工程师大多时候直接接受建议但偶尔会手动锁定某个关键参数并允许其他参数自由调整这种“部分自动”的交互方式很实用。5. 部署与稳定性从Demo到能被工程师日常使用的系统5.1 推理服务与外网隔离系统可用性的第一道门槛整个系统部署在内网的一台GPU服务器上推理服务用vLLM启动对外提供OpenAI兼容的HTTP API。之所以强调“内网部署”是因为半导体器件的仿真数据涉及大量未公开的结构参数和性能指标数据主权优先级高于一切便利性。vLLM跑起来之后需要做好API层适配。我写了一个简单的请求封装把LangChain或自研Agent框架里的model_name统一指到vLLM的serve_name。这里分享一个实测经验vLLM的API默认只支持同步返回但在Agent循环里模型可能被多次调用工具调用轮次多每次调用如果都要等完整生成结束才返回用户体验会很差。所以我把vLLM的stream模式打开在Agent框架里实现流式解析每出一个工具调用的JSON片段就立刻解析。还需要做并发控制。多个工程师同时使用时blast互相影响。vLLM内部有调度机制但Agent层的工具调用往往需要相对稳定的响应时间所以我加了一层信号量限制同一时刻最多3个Agent任务在跑。超过并发数的请求进入等待队列并在前端显示预计等待时间。5.2 任务队列与超时熔断Agent跑飞是常态要有兜底Agent跑飞是这个系统里最常遇到的事。所谓跑飞就是Agent在一个子任务上不断重试或无限循环思考迟迟不进入下一步。如果不加干预一次会话可能被一个死循环卡住几十分钟。我在编排层引入了三套兜底机制第一是工具调用次数限制。单个会话中Agent调用工具的总次数不能超过15次超过后强制终止并告知用户“当前任务步骤过多建议缩小目标范围”。第8次之后每次开始工具调用都会插入一条提醒你已经调用过N次工具请确认是否在收敛。第二是单轮思考时间限制。如果模型在某个节点上连续生成超过5分钟还没有触发任何工具调用或输出最终答案系统会主动插入一条system消息要求它“请基于已有信息做出决策避免继续分析”。第三是仿真任务本身的超时熔断。前面提到的SimExecutor里已经内置了超时控制仿真任务超过设定时间会被强制终止并把超时原因反馈给Agent。Agent会尝试简化模型配置比如关闭量子修正、减小网格密度重新提交一次如果二次提交仍然超时就会向用户报告并建议拆分仿真目标。这三层下来系统的稳定性有了质的变化。之前工程师吐槽最多的“界面转圈圈”基本被消除了。5.3 可观测性与审计不仅要能跑还要能查、能复盘作为一个会操作仿真工具的系统必须有完整的可观测性设计。我把一次完整的Agent会话记录下来包含以下结构化事件流事件类型记录内容用途user_request用户原始输入需求溯源knowledge_query检索的query、命中的文档ID、相似度知识命中率分析tool_call工具名、入参、返回状态、结果摘要工具正确性追踪model_thought模型的思考摘要如有推理过程回溯result_analysis提取的特征数值、模型判读结论结果可复核human_feedback工程师的修改/确认操作持续优化训练数据这些事件流被异步写入Elasticsearch并同时在本地落一份JSONL备份。出了问题可以精确回放当时模型看到了什么、调用了什么、仿真器返回了什么。日志数据还有一个超级有价值的用途构造高质量微调数据。当工程师明确拒绝了Agent的建议并给出了自己的修改后系统会自动记录这个“修正”信号。积累几百条这样的修正数据后可以用来做LoRA微调让模型在特定的工艺决策偏好上越来越贴合团队习惯。6. 避坑复盘我在搭建过程中踩过的真实问题6.1 “仿真不收敛”被模型误判成“器件物理异常”第一次做结果判读测试时我故意拿了一个不收敛的案例喂给模型。当时仿真日志里写着“Newton iteration failed to converge at bias 0.65V”模型给出的结论却是“高栅压区域可能发生了沟道热载流子注入效应”。听起来好像合理但物理机制判断完全错了根本原因就是数值不收敛。后来我加了一个前置判断模块在把日志摘要交给模型之前先由规则引擎扫描日志里的关键状态词。遇到“DIVERGED”“NOT CONVERGED”“TIMESTEP TOO SMALL”这些词直接把任务标记为“数值问题”而不是“物理分析”模式并在喂给模型的上下文里明确告知本次结果不可用于物理判读需要先排查网格和模型设置。这个规则引擎的优先级高于一切LLM判读。宁可先给出“花哨程度较低但正确”的结论也不能让模型自由发挥。6.2 知识库里的“过时工艺”比没有知识库更危险有一段时间系统会在回答里提到“某某参考工艺节点的标准沟道掺杂浓度是2e18”但实际原因是这条数据来自五年前的工艺文档。如果工程师没有察觉直接照这个参数做仿真结果会和实际工艺严重偏离。教训有两点。第一知识库里所有工艺参数必须有明确的版本标签和有效期第二检索时按时间降序优先过期的数据默认排在末尾甚至直接不进入Top5召回。对于团队内部的历史数据我还加了一个“主数据优先”规则同一类型的参数如果有来自官方工艺文件的数据就优先于论文中的数据更优先于网络博客中的数据。数据源的权威等级在元数据里直接标注。6.3 工具返回格式不统一Agent解析直接失衡早期系统里不同工具返回格式五花八门。参数扫描工具返回CSV结构生成工具返回TXT日志工具返回原文。模型在解析这些不同格式的时候经常出现“漏字段”的情况——明明CSV里有关键的DIBL数据模型却只盯着summary里的阈值电压把其他特征忽略了。标准化返回值是必须做的改造。所有工具一律返回JSON数值型数据放到extracted_metrics字段里原始文件路径放到output_files字段里禁止在顶层直接塞大段文字。对于CSV这类需要进一步解析的产物也必须在工具内部完成关键指标的提取后再返回绝不能把原始CSV直接丢给模型。改造之后Agent做结果分析时的信息完整度显著提升基本不会再出现“模型漏看某个关键指标”的情况。6.4 别指望大模型自己算数值它只会一本正经地瞎编这个坑最具迷惑性。有一回我问系统“当前这个结构的理论迁移率上限大概是多少”模型居然基于已有的仿真数据给出了一个看起来非常合理的数值还带了两处小数点。但我拿这个数去和材料物理的自主论一对比发现和理论值差了接近两个数量级。后来我彻底接受了一个原则任何定量数值不管多简单都不能让模型直接算必须调用真正的计算工具。哪怕只是“把两个阈值电压加一下取平均值”也要定义为工具调用用Python执行。模型只负责描述“该算什么、为什么算”真正算的永远是代码。这个原则在系统提示词里写成了硬性约束并且还在工具调用校验层做了拦截如果模型在回答中直接给出数值结论但本轮没有调用任何数值计算工具系统会在返回给用户之前插入一条横幅提醒这让我和团队对系统输出的数值结果有更高的信任度。7. 扩展与沉淀这套系统下一步还能怎么长7.1 多智能体协作材料、器件、工艺各管一段现在的单Agent架构能处理“从命名到仿真”的完整链路但有一个明显瓶颈不同环节依赖的知识深度不一样让同一个模型在所有环节都保持高质量输出需要非常大的模型和非常复杂的提示词。我下一步计划是把系统拆成多智能体架构一个材料Agent负责材料参数库维护和物性查询一个器件Agent负责结构建模和电学特性仿真一个工艺Agent负责工艺步骤仿真和可行性分析。三个Agent由一个编排Agent统一调度它们之间通过一个“任务黑板”共享信息——器件Agent需要材料参数时不是直接调用知识库而是向材料Agent发送请求拿到经过验证的参数。这种拆分的好处是每个Agent的提示词可以更聚焦工具列表更短模型出错的空间更小。坏处是编排复杂度上升Agent之间的上下文传递容易出现信息丢失。所以在架构上我用结构化消息协议替代了纯文本消息每个Agent的输出都有一段标准化的“结论摘要依据文档引用原始数据路径”避免传递过程中信息被“转述”变形。7.2 与实验数据的闭环从仿真智能体到研发数据平台仿真智能体的价值不只在仿真环节。真正理想的状态是把仿真结果和实际流片测试数据打通。当某个结构的实测阈值电压与仿真预测偏差较大时系统能把偏差标记出来并自动检索可能的原因比如工艺波动、寄生效应、模型参数偏差等。这个方向需要实验数据平台接口目前我们还在建设。先做的是把仿真报告自动归档到统一数据仓库统一命名规则、统一指标单位、统一格式。等实验数据接入后系统就能做更高级的“仿真-实验一致性分析”。对已经积累了多轮仿真结果的场景还可以考虑训练一个轻量级的代理模型用几千组仿真数据训练一个小规模神经网络代替部分粗扫仿真。粗扫阶段用代理模型快速定位参数范围精细阶段再调用TCAD做精确仿真能节省大量算力。7.3 针对领域微调让系统越来越像“自己团队的人”通用大模型对半导体术语的理解已经能做到“不犯大错”但距离“理解我们团队的工艺偏好”还有差距。每个研发团队都有一些不成文的习惯比如某个节点倾向使用较厚的栅氧换可靠性某个结构的掺杂分布喜欢从源端往漏端递减。这些都属于团队的隐性知识。把团队修正反馈积累起来做微调是让系统真正落地的必经之路。微调数据主要来自两个渠道一是工程师在系统界面上改变Agent建议的操作记录二是工程师在会话中明确纠正过的表述。这些数据经过清洗去重后做成LoRA训练集每个月增量微调一次。这样模型在参数建议、报告语气、判断倾向上都会越来越接近团队的真实工作习惯。我个人在实际搭建过程中的体会是这类系统最大的坑往往不在AI本身而在于仿真经验的“知识工程”。模型参数量再大也替代不了把老工程师脑子里的判断规则一条条挖出来、变成结构化逻辑的过程。先把工具封装好、知识库建扎实、结果判读规则定清楚AI能力在上面才能稳定发挥。如果让我再重做一次我还是会从最小闭环开始只不过这次会更早地把工艺和器件工程师拉进来一起写知识库而不是自己闷头搭完整个平台再给他们演示。