光学仿真圈子里有个非常常见的画面FDTD 的脚本窗口里放着几十行参数设置旁边摆着一本快翻烂的 Ansoft/Lumerical 教材脑子里还同时得记着材料折射率、边界条件、网格尺寸这些细节。尤其是遇到模式计算、参数扫描这类活改动一个变量就要重新跑几十轮仿真整个人被死死按在电脑前面。我最近把一个工作流彻底换了用 Cline 当前台DeepSeek 当大脑中间接了一套 MCP 工具搭出了一个能用自然语言指挥 Lumerical 跑仿真的小 Agent。这篇文章就是记录我从零开始搭的过程包括环境配置、MCP Server 代码、实跑的仿真案例还有几个把我坑得够呛的问题。如果你平时写 FDTD 脚本写到烦或者正在琢磨 AI Agent 怎么落地到工业软件这篇应该能给你一个完整的参考。1. 为什么是 Cline DeepSeek MCP 这个组合1.1 三个组件各自扮演什么角色先说 Cline。你可以把它理解成一个住在编辑器里的“AI 操作员”。它不只是聊天窗口它能读写文件、执行终端命令、管理多步骤任务还能通过 MCP 协议调用外部工具。我用的版本是 Cline Desktop也有 VS Code 插件版两者核心能力差别不大。Cline 内部会维护一个任务队列模型每生成一步它就去执行一步执行完把结果再喂回给模型形成闭环。这个机制决定了它能承担 Agent 的“骨架”功能。DeepSeek 在这里干的是“思考”的活。它负责把用户自然语言转换成可执行的计划比如“帮我把这个波导结构仿真跑一遍”会变成“先读现有 fsp 文件检查结构参数修改网格精度提交运行读取 S 参数”。我选择 DeepSeek 而不是默认的 Claude 或 GPT主要因为它的 API 走 OpenAI 兼容格式Cline 可以直接填 Base URL 接上而且便宜仿真脚本这类代码任务对模型要求不算极端DeepSeek 的代码能力和中文理解都够用。MCP 是整个方案里的“手”。没有 MCP 的话DeepSeek 只能生成文本Cline 只能做通用文件操作它俩没法直接控制 Lumerical。MCP Server 暴露出来一组与仿真相关的工具例如“列出项目文件”、“修改 FDTD 区域属性”、“提交仿真任务”、“查询运行状态”。模型看到这些工具的描述后会自动决定调用哪个、传什么参数。这是 Agent 能够“动手做事”的关键。1.2 从工程可行性看方案选型可能有人会问为什么不直接用 LangChain 自己写一个 Agent我试过的感受是框架功能强大但小团队要处理的工作太多。你要写对话循环、工具调用解析、上下文管理还要处理并发和异常代码量会迅速膨胀。Cline 已经把这些 Agent 基建做好了我们只需要聚焦在 MCP Server 的业务逻辑上。另一个选择是直接用 Codex 或 Copilot但这俩对自建 MCP 的支持不如 Cline 顺手尤其在桌面端场景上Cline 的扩展点更开放。这个组合还有一层好处每一层都可以单独替换。今天觉得 DeepSeek 不够强可以把 Base URL 换成别的 OpenAI 兼容模型不需要动 MCP Server。明天想给 Agent 加一个“识别仿真结果峰值”的功能只需要在 MCP Server 里加一个 tool 函数Cline 会自动把新工具暴露给模型。所以这套架构非常适合作为日常仿真助手的起点。2. 环境准备Lumerical 脚本自动化与 Agent 基础2.1 先把 Lumerical 的自动化基础打好在接 Agent 之前要确保 Lumerical 本身能被外部程序驱动。Lumerical FDTD 的 .fsp 工程文件本质上是一个序列化仿真对象它提供了 Python API在 Lumerical 安装目录下通常能找到lumapi.py安装好 Python 版本后直接用import lumapi就可以启动 Lumerical 并执行脚本。我的环境是 Windows 11、Lumerical 2025 R1、Python 3.11。Python API 的基本使用方式是这样先用lumapi.FDTD()启动一个 FDTD 会话然后通过addfdtd、addmode、setglobalsettings这类方法设置参数最后run()开始仿真getresult()提取结果。这种脚本模式和我们平时在 GUI 里操作的逻辑是一致的只是把鼠标点击变成代码。所以环境准备的第一步不是写 Agent而是先确认你能用 Python 独立跑通一个小型仿真。我通常会在一个测试目录里放一个test_sim.py里面只创建一个最简单的矩形波导仿真能够正常跑完就算基础环境通过。这里有个很容易踩的坑Lumerical 的 Python API 依赖版本匹配。如果你电脑里同时装了多个 Pythonimport lumapi可能找不到包。建议用 Lumerical 默认绑定解释器创建虚拟环境或者直接在 Anaconda 里指定。另一个坑是 License 类型有些教育授权不支持外部 Python API启动时会报 license 错误那就要联系管理员开通了。2.2 安装并配置 Cline 接入 DeepSeekCline 桌面版安装非常简单不过我更推荐在 VS Code 里装扩展方便看日志和改配置文件。安装完成后第一件事是配置模型供应商。因为 DeepSeek 提供 OpenAI 兼容接口所以在 Provider 那里选择 OpenAI Compatible然后填Base URLhttps://api.deepseek.com/v1API Key你从 DeepSeek 开放平台申请的 KeyModel IDdeepseek-chat如果你需要更复杂的推理也可以选deepseek-reasoner但实际用下来处理 Lumerical 脚本的普通任务deepseek-chat就够用了任务响应速度会更快。首次配置完建议新建一个会话输入“请读取当前目录下的文件列表”来测试 Cline 的读写能力。Cline 的配置文件里还可以设置最大 token 数、温度等参数。我不建议把温度调高仿真脚本对确定性要求高温度设置在 0.2 左右比较合适。如果你在配置 Cline 的时候发现模型回答经常断在代码中间多半是请求超时需要把连接超时时间调大或者换一个更快的网络环境。2.3 准备 MCP Server 的运行环境MCP Server 用 Python 实现最顺手因为 Lumerical Python API 本身就是 Python。MCP 官方提供了 Python SDK可以直接用pip install mcp安装。另外还要装python-dotenv用来管理密钥用uvicorn作为本地服务。MCP Server 默认走 stdio 或本地 HTTPCline 和它之间通过配置文件建立连接不需要部署到公网。我的推荐操作流程是先建一个独立目录lumerical-mcp-server在里面创建虚拟环境安装依赖。然后在cline_mcp_settings.json里加一段配置指定这个 server 的启动命令。配置里最关键的是command和args比如你的 Python 环境路径、server.py 的路径。Cline 启动时会自动拉起这个进程不需要你手动启动。首次配置完可以在 Cline 的 MCP 面板里看到服务器状态然后试着调用一个最简单的工具比如list_projects来验证链路是通的。3. 动手实现一个轻量级 Lumerical MCP Server3.1 我需要哪些 MCP 工具MCP Server 的价值不在于工具数量多而在于工具边界清晰。我一开始只想做一个能提交仿真任务的接口但实际跑起来后发现Agent 要完成一次仿真至少要具备几个能力扫描目录找工程文件、读取现有仿真脚本、修改参数、提交运行、监控状态、读取结果。所以我把 Server 拆成六个工具list_projects扫描指定目录返回所有.fsp和.lms文件。read_script读取指定工程文件对应的脚本方便 Agent 理解当前结构。modify_setup修改 FDTD 区域或结构参数输入是参数列表。run_fdtd调用 Lumerical Python API 提交仿真任务。query_status返回仿真任务运行进度和最近日志。get_results读取指定监控器中的 S 参数或场数据返回结构化数据。这六个工具已经覆盖了我在日常仿真中使用最多的动作。可能你会觉得modify_setup应该拆得更细比如单独的set_mesh、set_wavelength但我的经验是如果工具拆分太碎模型就需要多次调用来完成任务反而增加了出错概率。一个工具接受多个参数并在描述里写清楚参数含义是目前最平衡的做法。3.2 用 Python 快速写出一个可用的 Server核心代码骨架长这样。我先定义了一个LumericalFrontend类封装所有 Lumerical API 调用MCP 的工具函数只负责解析参数、调用业务方法、返回结构化的字典结果。from mcp.server.fastmcp import FastMCP import lumapi import os import json mcp FastMCP(lumerical-mcp) class LumericalFrontend: def __init__(self, project_dir: str): self.project_dir project_dir def list_files(self): results [] for root, _, files in os.walk(self.project_dir): for f in files: if f.endswith((.fsp, .lms)): results.append(os.path.join(root, f)) return results def run_simulation(self, fsp_path: str, runtime_sec: int 300): with lumapi.FDTD(fsp_path) as fdtd: fdtd.run() return {status: completed, file: fsp_path} mcp.tool() def list_projects(project_dir: str) - str: 列出指定目录下全部 Lumerical 工程文件 frontend LumericalFrontend(project_dir) return json.dumps(frontend.list_files(), ensure_asciiFalse) mcp.tool() def run_fdtd_simulation(fsp_path: str, max_seconds: int 300) - str: 运行一个 FDTD 仿真工程返回运行状态 frontend LumericalFrontend(os.path.dirname(fsp_path)) result frontend.run_simulation(fsp_path, max_seconds) return json.dumps(result, ensure_asciiFalse) if __name__ __main__: mcp.run()这段代码为了方便展示省掉了一些异常处理。实际使用里我会在run_simulation里加入超时机制用subprocess或threading来控制 Lumerical 进程避免仿真卡住时整个 MCP Server 被拖死。还要在工具函数里加上项目目录白名单校验防止模型从对话里随意读取系统路径。3.3 工具拆分与安全边界的设计思路我踩过一个很实际的问题给 Agent 暴露一个“通用命令行执行”工具4 秒钟之后它就开始调用pip uninstall了。所以 MCP Server 里的每一个工具都必须是封闭的、有边界的。所谓封闭是工具的参数和返回值都严格定义不接受任意字符串命令。你要让 AI 修改网格精度就给它mesh_step参数而不是给它一条“修改文件里第 30 行数字”的自由指令。你不想让它碰的东西从一开始就不要出现在工具列表里。安全边界的另一个层面是资源限制。FDTD 仿真本身很耗内存和 GPUAgent 一旦失控可能同时提交好几个任务把工作站跑挂。我在工具里加了一个“当前活动任务数”计数最大 2 个超过就拒绝新的仿真请求。另外每次仿真前必须在 MCP Server 里记录初始时间戳当运行超过某个阈值自动终止底层进程。这些硬保护逻辑是 AI 自己不会想到去写的必须由我们预先埋好。4. 用自然语言驱动一场硅波导仿真4.1 一个真实的使用场景我准备了一个简单的测试工程一个硅波导定向耦合器文件放在C:/simulations/waveguide/fsp目录。下面的内容是我实际在 Cline 里输入的一句话“读取 waveguide_coupler.fsp把中心波长改成 1550nm网格精度设在 2nm跑一次模式仿真然后把 S 参数结果导出成 CSV。” 这句话看起来简单但对 Agent 来说经历了完整的“理解-规划-执行-反馈”链条。Cline 拿到任务后先在系统提示里看到了我用 MCP 列表定义的六个工具它很快决定先调用list_projects确认文件是否存在再调用read_script检查初始的波长和网格设置接着调用modify_setup修改关键参数再调用run_fdtd提交任务。期间如果某个参数不符合 Lumerical 语法Agent 会根据工具返回的报错信息重试一次。我们要做的只是给它足够清晰的工具描述剩余路线它自己会选。4.2 从描述到脚本Agent 的思考链条我打开了 Cline 的任务日志看它内部是怎么一步步实现的。日志显示它首先把中文需求拆解为四个子任务检查工程结构、修改变量、运行仿真、导出数据。然后它对第一个子任务执行了read_script拿到文件里set开头的变量后发现波长来源是lambda0这个参数于是调用modify_setup传入{parameter: lambda0, value: 1550e-9}。因为 DeepSeek 对命名单位有很好的把握它知道 Lumerical 内部默认使用米为单位所以不会把代码写错成 1550 nm 的数字直接放进公式。比较惊艳的部分是网格设置。它没有直接改全局网格大小而是在日志里意识到需要调用set_mesh并限制 mesh order它读取了现有脚本里的 mesh 组名称然后在修改时保留了原扫描区域的边界范围。这个能力不是靠模型凭空猜的而是因为我们把 Lumerical API 常见写法和一些单位换算写进了 Cline 的项目规则文件里模型在生成代码时有了可靠的参考上下文。4.3 仿真结果如何回传和验证仿真结束后get_results工具会从 FDTD 监控器里读取 S 参数返回一个包含频率、S11、S21、S31、S41 的字典。Cline 会把这些数据整理成 Markdown 表格展示在会话里然后自动生成一个coupler_results.csv文件。模型还会在最后给出一段解释哪个波段的插损最低中心波长处的功率耦合比例是多少。如果发现结果与理论预期偏差大它会提示检查耦合距离和波导宽度。我发现这个环节最考 Agent 的其实是“什么算跑完”。Lumerical 里的仿真完成后还有可能进入结果后处理比如画图、导出。如果 MCP 工具定义里没写清楚get_results只在run_fdtd成功后调用模型可能会在仿真正在跑的时候就跑去取结果返回一堆空数组。所以我在工具描述里加了一句仅在仿真状态为 completed 时可以调用。看似多此一举却大大降低了失败概率。5. 仿真与接入中的故障排查实录5.1 Lumerical FDTD Run 卡在 Updating Modes这个可以说是真正的“场景关键词”了。我最初在使用 Python API 提交仿真时遇到过run命令卡在updating modes阶段程序不报错也没有输出了CPU 占满但进度条就是不动。原因其实是 FDTD 在模式计算阶段需要把本征模和网格更新耦合起来特别是在结构里包含高 Q 微腔、紧耦合波导或者非常细的网格时这个过程会陷入很长的迭代。我的排查路径是先确认是不是网格精度设置过高把全局 mesh step 从 2nm 放宽到 5nm 试一次再看是否在addmode时设置了过多的模数模式数越多更新越慢最隐蔽的一个问题是材料拟合精度Lumerical 默认会进行材料多系数拟合如果材料数据跨度很大拟合更新也会很慢。在 Agent 层面我在run_fdtd工具里额外提供了timeout_seconds参数并在超时后自动将 Lumerical 进程终止返回“当前模式更新耗时超过预期”的日志。这样模型就能根据日志自动选择修改网格或模式数而不是在会话里干等。5.2 Cline 找不到 MCP Server另一个经常发生的问题是 Cline 启动后 MCP 面板一直显示“连接中”或者工具调不起来。多数情况是 Cline 拉起 Server 时使用的 Python 环境不对。比如我用 poetry 建好的虚拟环境路径是.venv/bin/python但 Cline 默认用了系统 Python导致import mcp失败。解决办法是配置 MCP Server 时明确指定可执行文件的绝对路径。配置示例{ mcpServers: { lumerical: { command: C:/Users/me/.virtualenvs/lumerical-mcp/Scripts/python.exe, args: [ C:/Users/me/projects/lumerical-mcp/server.py ], env: { LUMERICAL_ROOT: C:/Program Files/Lumerical } } } }如果改了配置还是不行我建议手动在终端里跑一遍server.py看它启动时报什么错。很多时候是lumapi库导入失败而 Cline 的日志面板又不会显示 Python 堆栈手动跑一遍能够快速定位。还有一个小经验Windows 上路径分隔符容易写错配置 JSON 里要用双反斜杠或正斜杠一个斜杠加一个反斜杠的混合写法会让你找半天错误。5.3 DeepSeek 生成代码不稳定DeepSeek 写脚本整体很流畅但偶尔会犯一些“自以为见过”的错误。比如在 Lumerical 里添加一个矩形结构时它可能会写成addrect但实际在 Python API 里是addrect没错问题在于参数顺序它可能会把x_min和x_max的顺序写反又比如对波导宽度使用微米单位时换算错误。这些错误不致命但会让仿真结果完全不对。我的处理方法是给 Cline 加一层“项目规则”。我在规则文件里写了几个必须遵守的约定所有长度单位用米所有脚本开头必须打印结构数量修改参数前先读取原脚本运行完必须检查日志中的 warning。这样在同一会话里模型每次生成代码都会先过一遍这些规则。就算模型犯了错Cline 执行后返回的错误信息也会让模型进行自我修正大多数情况下第二轮就能成功。6. 让 Agent 真正好用的小经验6.1 把领域知识写进 Cline 规则文件这是整个项目里投入产出比最高的一步。Lumerical 的 Python API 虽然不算复杂但冷门方法很多DeepSeek 训练数据里就算有也未必记得准确。我把平时写 FDTD 脚本常用的几十个 API 方法、参数单位、典型网格配置、项目目录约定都整理进了一个CLAUDE.mdCline 会自动读取的规则文件。直接的效果就是模型在生成代码时不再反复问set_global_monitor是否存在也不再编造一个过时的 API 名字。规则文件也不要只堆名词。我会写一些场景化提示比如“当用户提到耦合器时需要同时设置两个监视器” “当仿真结果 S 参数不平凡时先提示检查端口边界”这些领域经验让 Agent 更像一个懂仿真的助手而不是一个只会查找文档的代码生成器。6.2 不要一次给模型过大的操作权限安全边界这件事我再怎么强调都不为过。Agent 最危险的不是它“不会”而是它“会但不理解后果”。如果你给 MCP Server 开了写任意文件的权限模型可能会在你毫不知情的情况下覆盖掉一个跑了三天的扫描结果文件夹。我最终的方案是让 Agent 只能在一个专门的workspace目录下读写文件Lumerical 工程文件也只从该目录读取所有导出结果统一放到results子目录。任何向外部的写操作都需要用户授权。在 Cline 里我们可以设置自动执行权限。我建议把文件编辑和命令执行都设为“每次询问”只有 MCP 工具调用可以自动执行。这样既保证了效率又不会在关键时刻做坏事。等 Agent 跑得足够稳定了再逐步放开权限。6.3 未来可以扩展的方向这套架构可以往几个方向继续加深。一个方向是参数扫描优化让 Agent 根据用户目标自动生成多组结构参数进行扫参然后汇总比较最优结果。另一个方向是结果归因把失败的仿真日志回传给模型让模型判断是收敛问题、材料问题还是边界条件问题。第三个方向是把 MCP Server 推给团队使用做成一个简单的局域网服务让其他工程师也能在 Cline 里直接调用同一个仿真后端。这些扩展都需要 MCP Server 慢慢长出更多业务逻辑但底层架构不用再动。我个人在实际操作中的体会是不要刚开始就追求“万能助手”。把 Agent 限定在“脚本生成 仿真提交 结果整理”这个范围里已经能节省大量时间。后边如果确实需要更智能的结构复用和拓扑优化再往 Agent 里加专门的优化工具箱。先把管道打通再让大脑更聪明这条路最顺。