PSCAD 里跑一次电磁暂态仿真，真正花时间的从来不是搭模型那一下，而是之后那一整套循环：改参数、点运行、等结果、再回曲线里抠数字，改完再点一遍。这种工况扫描的活儿做多了，人容易变得机械。我最近用大模型加 MCP（模型上下文协议）把 PSCAD 包了一层，让模型直接读工程、改参数、跑仿真、取波形，整套流程只用一句自然语言就能触发，内部给自己起的名字叫 PowerMCP。这篇文章讲的就是这套东西从设计到落地的全过程。适合谁看？手上有电磁暂态仿真任务、被批量工况磨过的电力系统从业者，以及想把大模型真正接进工程软件而不是停在聊天界面的开发者。哪怕你没写过 MCP，照着下面的骨架也能跑通一个最小可用版本。
1. 为什么要把大模型接进电磁暂态仿真
1.1 传统 PSCAD 工作流的真实痛点
PSCAD 的定位很明确：做电力系统电磁暂态仿真，从开关操作过电压到故障暂态电流，从变压器励磁涌流到新能源并网的低穿特性，基本都落在它的射程里。它的图形化建模做得相当好，元件拖一拖、连一连，一个看起来完整的系统就出来了。但一旦进入"参数研究"阶段，图形界面的优势立刻变成负担。
举个很常见的场景：要研究不同故障电阻下母线电压的跌落深度，还得考虑故障初相角的影响。三个电阻、四个相角，就是十二个工况。每个工况都要手动改元件参数、点运行、等仿真跑完、切到曲线图、用光标量峰值或者切换 RMS 显示、把数抄进表格。一轮下来半小时没了，抄错一个数还得倒回去重来。更别提有时候只是想确认一下"步长从 50 微秒缩到 20 微秒，波形会不会变形"这种问题，也得走一遍同样的流程。
这中间其实没有多少智力含量。参数之间的关系是确定的，仿真启动是确定的，曲线读取规则也是确定的。人在里面扮演的更像一个"人肉脚本"，只不过图形界面没有给脚本留出足够的入口。PSCAD 从 5.x 开始提供了 Python 自动化接口，这才让"把人从循环里摘出来"变得可行。
1.2 MCP 解决的是哪一层问题
有人会问：既然有 Python 接口，写个脚本不就完了，为什么要绕到大模型这边来？这个问题很关键，值得单独说清楚。
脚本解决的是"已知任务"的自动化。比如你清楚知道要扫哪几个电阻值、每个工况的输出通道叫什么、结果里要取哪一个量，那确实写个 for 循环就够了，不需要模型。但实际工作中的情况往往是半结构化的：需求以自然语言的形式来，比如"帮我看看这个系统在单相接地且过渡电阻比较大的时候，母线电压还能不能维持在 0.8 标幺以上"，里面涉及的元件名、参数路径、通道名、判定指标，都需要结合具体工程去对应。让传统脚本去解析这种描述，成本比人工操作还高。
MCP 的价值在于给大模型提供了一层标准化的"手"。模型自己不会操作 PSCAD，但你把"加载工程""设置参数""运行仿真""读取通道"这几个动作包装成 MCP 工具，模型就能根据你的自然语言描述，自主决定调用顺序和参数取值。工具本身是确定性的、可测试的、可复用的；模型负责的只是编排，也就是把模糊需求翻译成一系列确定性的动作调用。这种分工比"全部交给脚本"要灵活，也比"全部交给模型"要可靠。
选择 MCP 而不是直接写 Function Calling，还有一层工程上的考虑。MCP 是传输层协议，工具定义在服务端，客户端可以是桌面应用、可以是自研的对话界面、也可以是另一个自动化流程。同一套 PowerMCP 服务，今天接在聊天窗口里用，明天接在批处理任务里用，工具代码一行都不用改。Function Calling 是绑定在特定模型 API 上的，换一家模型就要重写一遍适配层，这在长期维护上是很不划算的。
1.3 PowerMCP 的整体架构与选型取舍
整体结构其实很简单，三层。最底下是 PSCAD 本体和它提供的 Python 自动化接口，负责真正的仿真计算；中间是 PowerMCP 服务端，用 Python 写成，把 PSCAD 的能力包装成一组 MCP 工具；最上面是任意支持 MCP 的客户端，模型通过它发起调用。
选型上有几个决定值得说明。第一，服务端用官方 MCP Python SDK 的 FastMCP 封装，而不是自己实现协议。FastMCP 把工具注册、参数 schema 生成、传输层处理都包掉了，几十行代码就能起一个可用的服务，省下来的精力可以放在工具设计上。第二，状态管理上刻意保持"单工程单实例"，也就是一个服务进程同一时刻只持有一个加载中的 PSCAD 工程。早期我试过多工程并存，结果被 PSCAD 的许可证占用和内存增长折腾得够呛，后来改成单工程加外部队列调度，稳定性立刻上了一个台阶。第三，所有工具都设计成幂等或者可回滚的，比如设置参数之前先记录原值，运行失败时能恢复到调用前的状态，避免模型乱调一通之后工程处于半改半不改的尴尬局面。
这里要多说一句关于"为什么不做成一个大工具"。直觉上会想，干脆做一个run_study(description)工具，模型把需求丢进去，服务端解析完自己跑完返回结果。这条路我试过，很快就放弃了。原因是大工具内部的黑盒逻辑一旦出问题，排查成本极高，而且模型看不到中间状态，也没法根据中间结果调整策略。拆成原子工具之后，模型每一步做了什么、参数是什么、返回了什么，全都可观测，出错时看一眼调用链就知道问题在哪。
2. 环境准备与 PSCAD 自动化接口摸底
2.1 版本对齐与依赖清单
这套东西对环境版本比较敏感，尤其是 PSCAD 的自动化接口在各版本之间有过调整，版本没对齐的话会出现"代码没错但就是跑不起来"的情况。我实测下来比较稳的组合是这样的。
| 组件 | 建议版本 | 作用 | 备注 |
|---|---|---|---|
| PSCAD | 5.0 及以上 | 仿真内核 | 需完整安装，精简版没有自动化接口 |
| Python | 3.10 及以上 | 运行环境 | MCP SDK 对 3.9 支持不完整 |
| mcp | 官方 Python SDK 最新版 | 协议实现 | 提供 FastMCP 封装 |
| pscad | 官方 Python 包 | 调用 PSCAD | 与 PSCAD 版本强相关 |
| numpy | 1.24 及以上 | 波形处理 | 抽稀、RMS、峰值计算 |
| pandas | 2.x | 结果汇总 | 批量结果转表 |
| pydantic | 2.x | 参数校验 | 工具入参校验 |
安装本身不复杂，pip install mcp pscad numpy pandas基本就够了。真正需要注意的是 PSCAD 这一侧：Python 包在底层是通过自动化接口跟 PSCAD 主程序通信的，所以 PSCAD 必须处于可被调用的状态，许可证也必须可用。如果机器上装了多个版本的 PSCAD，要用pscad.set_library_path()显式指定使用哪一个，否则默认加载的可能不是你预期的版本。
注意：PSCAD 的自动化调用会独占一个许可证席位。如果团队许可证数量有限，批量跑仿真的时候要提前跟同事打招呼，不然别人打开图形界面会提示无可用授权。
2.2 PSCAD 的自动化入口到底在哪里
很多人第一次接触 PSCAD 自动化会卡在这一步：文档里说有 Python 接口，但翻遍安装目录也找不到入口。实际上入口就在 Python 包里，装好之后import pscad就能用，关键在于理解它的对象模型。
一个 PSCAD 工程在 Python 侧对应一个Project对象，通过pscad.load(路径)得到。工程里的所有可调参数构成一棵树，用点号分隔的路径来寻址，比如故障元件叫Fault、里面的过渡电阻参数叫Rf，那完整路径就是Fault.Rf。这里有个容易踩的点：路径里的组件名是你在画布上给元件起的名字，不是元件类型名。同一个工程里如果有三个故障元件，名字可能是Fault、Fault1、Fault2，模型没法靠猜知道该改哪一个，所以工具必须提供"列出参数"的能力，让模型先看再改。
波形输出也是类似的结构。PSCAD 的输出通道有自己的一套命名规则，通常是"元件名.信号名"的形式，比如Bus1.V1表示母线 1 的 A 相电压。通道名区分大小写，而且跟工程里实际的输出配置强相关——如果建模的时候没在输出通道列表里勾选这个信号，运行时是不会产生数据的。这一点在自动化场景下尤其要注意，因为人工操作时你会看到"没数据"然后回去补勾，模型看不到图形界面，只能靠工具返回的错误信息来定位。
仿真运行本身是同步阻塞的。proj.run()调用之后会一直等到仿真结束才返回，中间没有进度回调。对于短仿真这没问题，但如果仿真时长设得比较长、步长又小，一次运行可能要好几分钟，这时候需要一个超时机制兜底，避免服务端卡死。
2.3 PowerMCP 服务端骨架搭建
服务端的骨架非常薄，FastMCP 把大部分脏活都干了。最小可用版本长这样：
import os import time import numpy as np import pscad from mcp.server.fastmcp import FastMCP mcp = FastMCP("powermcp") # 全局状态：单工程单实例 _STATE = { "project": None, "project_path": None, "last_run": None, "channels": {}, "param_backup": {}, } if __name__ == "__main__": mcp.run()mcp.run()默认走 stdio 传输，也就是客户端启动服务端进程、通过标准输入输出通信。这种方式部署最简单，适合本地桌面场景。如果要做成团队共享的服务，可以改成 SSE 或者 streamable HTTP 传输，但那样就要额外处理并发和会话隔离，复杂度会显著上升。我的建议是先用 stdio 把功能跑通，确有共享需求再考虑换传输方式。
全局状态这里用了一个普通字典而不是类，理由是工具函数在 FastMCP 里是平铺注册的，用模块级状态访问起来最直接。当然正式项目里更推荐封装一个Session类，把加载、运行、清理都收进去，避免状态散落。这里为了讲清楚逻辑，先用最简单的形式。
还有一个容易被忽略的细节：服务端启动时要检查 PSCAD 库路径和许可证状态，如果环境不对，要在启动阶段就报错退出，而不是等到第一次调用工具才失败。模型拿到一个"仿真失败"的返回值，很难判断是参数问题还是环境问题，这种歧义会显著拉低调试效率。
3. 工具集设计：把仿真拆成可被模型调用的原子动作
3.1 参数注入工具的设计细节
参数注入看起来是最简单的工具，实际上坑最多。最朴素的做法是接收一个字典，键是参数路径、值是目标值，逐个写进去。但这样有几个问题：模型可能给一个不存在的路径，可能给一个类型不对的值（比如把电阻写成字符串），也可能一次改一堆参数改到一半失败，留下半改状态。
我的做法是把校验、备份、原子性三件事都放进工具里。校验阶段先遍历所有路径，确认每一个都在参数树里存在，任何一个不存在就整体拒绝，并把最接近的几个候选路径返回给模型，让它自己纠正。备份阶段把每个参数的当前值记下来，写入_STATE["param_backup"]。真正写入的时候逐个赋值，任何一个抛异常就按备份回滚已写入的部分。这样模型拿到的是一个明确的成功或者失败，不存在"改了一半"的中间态。
@mcp.tool() def set_parameters(assignments: dict[str, float | int | str]) -> dict: """批量设置工程参数。 参数: assignments: 字典，键为完整参数路径（点号分隔，例如 'Fault.Rf'）， 值为目标数值或字符串。键必须与 list_parameters 返回的 路径完全一致，区分大小写。 返回: {"ok": true, "applied": {...}} 或 {"ok": false, "reason": "...", "suggestions": [...]} """ proj = _STATE["project"] if proj is None: return {"ok": False, "reason": "尚未加载工程，请先调用 open_case"} tree = proj.parameters() known = set(tree.keys()) missing = [k for k in assignments if k not in known] if missing: suggestions = {} for k in missing: tail = k.split(".")[-1].lower() suggestions[k] = [c for c in known if tail in c.lower()][:5] return {"ok": False, "reason": "参数路径不存在", "suggestions": suggestions} backup = {k: tree[k] for k in assignments} _STATE["param_backup"].update(backup) applied = {} try: for k, v in assignments.items(): tree[k] = v applied[k] = v except Exception as e: for k, v in backup.items(): try: tree[k] = v except Exception: pass return {"ok": False, "reason": f"写入失败并已回滚: {e}"} return {"ok": True, "applied": applied}这里有个设计上的取舍值得说。返回值里我特意保留了suggestions字段，让模型在参数名写错的时候能拿到候选列表自我纠正，而不是直接把错误抛给用户。实测下来这一条能把"模型瞎编参数名"导致的失败率压下去一大截。模型并不是真的知道工程里有什么，它只能靠工具返回的信息来学习，所以工具的报错信息要写得足够"教学化"。
3.2 仿真运行与状态轮询
运行工具的核心逻辑就是调proj.run()，但外围要包几层保护。第一层是参数合法性检查，步长必须大于零、仿真时长必须大于步长，这些可以在工具入口拦掉，省得 PSCAD 内部报一堆看不懂的错误。第二层是超时保护，用一个时间戳记录开始时刻，在阻塞调用的前后做检查。真正的强杀比较难做，因为proj.run()是同步阻塞的，没法从外部中断，所以超时只能做到"事后报告"，做不到"中途掐断"。
@mcp.tool() def run_case(t_end: float = 0.5, time_step: float = 20e-6) -> dict: """运行当前工程的电磁暂态仿真。 参数: t_end: 仿真总时长，单位秒，范围 0.01 到 10。 time_step: 仿真步长，单位秒，范围 1e-7 到 1e-3。 输电线路常规取 20e-6 到 50e-6，电缆建议 5e-6 到 10e-6。 返回: {"ok": true, "t_end": ..., "time_step": ..., "steps": ..., "wall_time_s": ..., "channels": [...]} """ proj = _STATE["project"] if proj is None: return {"ok": False, "reason": "尚未加载工程"} if not (0.01 <= t_end <= 10): return {"ok": False, "reason": "t_end 超出合理范围 0.01~10 秒"} if not (1e-7 <= time_step <= 1e-3): return {"ok": False, "reason": "time_step 超出合理范围 1e-7~1e-3 秒"} if time_step >= t_end / 10: return {"ok": False, "reason": "步长过大，仿真点数不足 10 个，无意义"} tree = proj.parameters() try: tree["Simulation.time_step"] = time_step tree["Simulation.t_end"] = t_end except KeyError: return {"ok": False, "reason": "工程缺少仿真控制参数，请检查模型"} t0 = time.time() try: run = proj.run() except Exception as e: return {"ok": False, "reason": f"仿真执行失败: {e}"} wall = time.time() - t0 _STATE["last_run"] = run _STATE["channels"] = {} return { "ok": True, "t_end": t_end, "time_step": time_step, "steps": int(round(t_end / time_step)), "wall_time_s": round(wall, 2), "channels": list(run.outputs().keys()), }返回值里带steps和wall_time_s不是摆设。模型看到 25000 个步点跑了 12 秒，下次再要加步数的时候就会自己掂量一下；看到某个工程跑了 6 分钟，就会主动问用户要不要换个策略。这种"让模型感知代价"的设计，比在工具描述里写十遍"注意性能"都管用。
注意：不要在运行工具里顺手做"结果提取"。早期我把运行和读数合在一个工具里，结果是每次改一个小参数都要把全部通道数据搬一遍，传输开销大不说，模型上下文也迅速被数值塞满。拆开之后，模型只在真正需要数据的时候才调读取工具，效率高很多。
3.3 输出通道读取与数据落盘
读取工具的设计要点是"抽稀"和"按需"。一个 0.5 秒、20 微秒步长的仿真，每个通道有 25000 个点。六个通道就是 15 万个浮点数，直接塞进模型上下文，token 数会爆炸，而且模型也读不过来。实际做法是按等间隔抽稀到几百个点返回，同时把统计特征（最大值、最小值、RMS、峰值时刻）一并算好带回去。这样模型既能看趋势，又能拿到关键数字。
@mcp.tool() def read_channels(channel_names: list[str], max_points: int = 200) -> dict: """读取指定输出通道的波形数据。 参数: channel_names: 通道名列表，必须与 run_case 返回的 channels 完全一致。 max_points: 每个通道返回的最大点数，默认 200，范围 50 到 2000。 返回: {"ok": true, "t": [...], "series": {name: {"y": [...], "min": ..., "max": ..., "rms": ..., "peak_time": ...}}} """ run = _STATE["last_run"] if run is None: return {"ok": False, "reason": "尚未运行仿真，请先调用 run_case"} outputs = run.outputs() available = set(outputs.keys()) missing = [c for c in channel_names if c not in available] if missing: tail = [m.split(".")[-1] for m in missing] suggestions = {} for i, m in enumerate(missing): suggestions[m] = [c for c in available if tail[i] in c][:8] return {"ok": False, "reason": "通道不存在", "suggestions": suggestions} n = min(max(max_points, 50), 2000) result = {"ok": True, "t": [], "series": {}} t_full = np.asarray(outputs[channel_names[0]].time()) idx = np.linspace(0, len(t_full) - 1, n).astype(int) result["t"] = t_full[idx].round(6).tolist() for name in channel_names: y = np.asarray(outputs[name].data()) y_ds = y[idx] result["series"][name] = { "y": y_ds.round(4).tolist(), "min": round(float(np.min(y)), 4), "max": round(float(np.max(y)), 4), "rms": round(float(np.sqrt(np.mean(y ** 2))), 4), "peak_time": round(float(t_full[int(np.argmax(np.abs(y)))]), 6), } return resultpeak_time这个字段是我后来加上去的，加的理由很实际：模型看到最大值，经常接着追问"什么时候出现的"，与其让它再调一次工具算，不如提前算好。这种"预计算常用派生量"的思路在工具设计里很值得推广，能大幅减少来回调用次数。
3.4 工具描述的写法决定调用成功率
这一节可能是整篇文章里最不技术、但最要命的部分。MCP 工具的名字和描述是模型唯一的"使用说明书"，写得含糊不清，模型就只能靠猜，猜错了你还要怪模型笨。
先说命名。工具名要用动词开头、语义单一，open_case、set_parameters、run_case、read_channels这种就很好，一看就知道干什么。反面例子是do_simulation、process这种名字，模型根本不知道这个工具是加载工程还是运行仿真。名字里也不要出现缩写，sp这种除了你自己没人看得懂。
再说描述。每个工具的描述我都坚持三段式：第一段说清楚这个工具干什么、适用于什么场景；第二段列参数，每个参数都要写单位、范围、约束；第三段写返回值的结构，以及常见的失败原因。参数说明里"单位"和"范围"这两条尤其关键，模型最容易犯的错误就是把毫秒当秒、把千欧当欧。在描述里明确写"单位秒"，比在代码里做一百次校验都管用，因为模型在生成参数的时候就会看到这句话。
@mcp.tool() def open_case(project_path: str) -> str: """加载一个 PSCAD 工程文件（.pscx），作为后续所有操作的目标。 适用场景：开始任何仿真工作之前必须先调用本工具。同一个服务进程 同时只持有一个工程，重复调用会替换掉之前加载的工程。 参数: project_path: 工程文件绝对路径，必须以 .pscx 结尾。 不接受相对路径，不接受 .pscx_ 之类的备份文件。 返回: 成功时返回工程摘要字符串，包含顶层元件数量和参数条目总数。 失败时返回以 'ERROR:' 开头的说明，常见原因有： - 文件不存在 - 文件被其他进程占用（图形界面正在打开该工程） - PSCAD 许可证不可用 """有一点特别值得提：工具描述里要主动"劝退"错误用法。比如在run_case的描述里写一句"修改参数后必须重新调用本工具，之前的结果才会更新"，就能避免模型以为改了参数波形会自动变。这种"防呆提示"写起来啰嗦，但能省下大量排查时间。
4. 一次完整实操：从一句话需求到波形
4.1 需求拆解与仿真参数计算
假设用户丢过来的需求是这样一句话：把 A 相接地故障的过渡电阻从 0.1 欧扫到 10 欧，看看母线电压还能不能撑住，步长 20 微秒，仿真 0.5 秒。
这句话里其实藏着好几个需要专业判断的地方，模型不知道，得靠人（或者预先写好的系统提示词）补上。第一，步长 20 微秒合不合理。对于一条百公里级的架空线路，行波往返一次的时间大约是 2×100000/3×10⁸ ≈ 667 微秒，对应的主振荡频率在 1.5 千赫兹附近。要保证一个周期内至少有 20 个采样点，步长上限就是 1/(20×1500) ≈ 33 微秒。20 微秒落在这个范围内，同时留了余量给故障瞬间的高频分量，是合理的选择。如果用户说的是电缆线路，波速降到 1.5×10⁸ 米每秒左右，往返时间翻倍到 1.3 毫秒，主频降到 750 赫兹，步长反而可以放宽，但电缆的电容效应会带来更高频的暂态，所以实践中还是建议 5 到 10 微秒。
第二，仿真时长 0.5 秒够不够。常规做法是故障前留 0.1 秒建立稳态，故障后观察 0.3 到 0.4 秒，看暂态衰减和稳态恢复情况。0.5 秒扣掉故障前的 0.1 秒，剩 0.4 秒观察窗口，对于工频量来说有 20 个周期，足够算出稳定的 RMS。如果要观察低频振荡或者保护动作，那得拉到 2 秒以上。
第三，过渡电阻扫 0.1 到 10 欧这个范围是不是合理。对于 220 千伏系统，金属性故障（电阻接近 0）时故障电流最大，随着电阻增大电流迅速下降。10 欧在 220 千伏下已经属于高阻故障的范畴，电压跌落会明显变浅。这个范围覆盖了从"严重"到"轻微"的整个梯度，选得不错。但如果用户研究的是 10 千伏配电网，10 欧的电阻根本不算高阻，得扫到几百欧才有意义。这类量纲判断必须由懂行的人把关。
第四，什么样的电阻组合才算"扫"。0.1 到 10 欧取几个点？我的经验是取对数间隔，比如 0.1、0.3、1、3、10 五个点，比线性取点更能反映故障严重程度的变化规律。取五个点而不是十个点，是因为每个工况的仿真时间大约十几秒，五个点一分钟能跑完，十个点要两三分钟，而且结果曲线的"形状"五个点已经能看清了。
把这些判断写进系统提示词，或者直接写进工具的默认参数里，模型接到那句自然语言需求之后就能自动补全成一次正确的调用。这一步不顺，后面全白搭。
4.2 批量参数扫描的实现
有了原子工具，批量扫描有两种做法。第一种是让模型自己循环：调一次set_parameters改电阻，调一次run_case跑仿真，调一次read_channels取数据，重复五次。这种做法直观，模型全程可见每一步，出问题好定位。缺点是每一步都要在模型和服务端之间来回一次，五轮下来调用次数不少，而且模型要在上下文里累积五组结果，对长上下文能力有要求。
第二种是在服务端封一个专门的扫描工具，一次调用跑完整个序列。这种做法效率高、上下文干净，但灵活性差，每次换扫描维度（从扫电阻变成扫相角）都得改代码。我的做法是两者都保留：日常探索用模型循环，确定要反复跑的固定研究用服务端扫描。
@mcp.tool() def sweep_transition_resistance( values: list[float], fault_phase: str = "A", t_end: float = 0.5, time_step: float = 20e-6, monitor_channel: str = "Bus1.V1", ) -> dict: """扫描单相接地故障的过渡电阻，返回每个电阻值下的监测通道统计量。 参数: values: 过渡电阻值列表，单位欧姆，例如 [0.1, 0.3, 1, 3, 10]。 fault_phase: 故障相别，取值 'A' / 'B' / 'C'。 t_end: 每次仿真的时长，单位秒。 time_step: 仿真步长，单位秒。 monitor_channel: 用于统计的监测通道名。 返回: {"ok": true, "rows": [{"Rf": ..., "min": ..., "max": ..., "rms_steady": ..., "dip_pu": ...}, ...]} """ proj = _STATE["project"] if proj is None: return {"ok": False, "reason": "尚未加载工程"} tree = proj.parameters() rf_path = f"Fault.Rf_{fault_phase}" if rf_path not in tree: return {"ok": False, "reason": f"找不到参数 {rf_path}"} rows = [] for rf in values: tree[rf_path] = float(rf) tree["Simulation.time_step"] = float(time_step) tree["Simulation.t_end"] = float(t_end) run = proj.run() y = np.asarray(run.outputs()[monitor_channel].data()) t = np.asarray(run.outputs()[monitor_channel].time()) # 用故障后 0.25~0.45 秒的窗口算稳态 RMS，避开暂态过程 mask = (t > 0.25) & (t < 0.45) rms_steady = float(np.sqrt(np.mean(y[mask] ** 2))) if mask.any() else float("nan") rows.append({ "Rf": float(rf), "min": round(float(np.min(y)), 4), "max": round(float(np.max(y)), 4), "rms_steady": round(rms_steady, 4), }) return {"ok": True, "rows": rows}这里有个实现细节值得展开：为什么用 0.25 到 0.45 秒这个窗口算稳态 RMS，而不是全程算？因为故障发生瞬间有直流分量和高频振荡，直接用全程 RMS 会被暂态过程拉偏，不同电阻值之间的比较就失真了。故障发生在 0.1 秒，留 0.15 秒给暂态衰减，从 0.25 秒开始取两个工频周期的数据，算出来的 RMS 才是真正的稳态值。这种"取窗口"的门道在人工操作时靠经验，在自动化时必须显式写成代码，否则模型不会知道这里面还有讲究。
4.3 结果回读与自动化判读
跑完扫描，拿到的是一张表，五个电阻值对应五组统计量。这时候模型要做的事情就不只是"把数报出来"，而是结合需求判断"电压还能不能撑住"。撑不撑得住，得有个判据。常见的判据是跌落后电压低于 0.8 标幺算不达标，或者跌落后能在一个周波内恢复到 0.9 标幺以上算合格。
这些判据模型自己是不知道的，必须由提示词或者工具的默认参数提供。我通常会在系统提示里写清楚："本题中'撑住'定义为故障切除后 0.2 秒内监测通道电压 RMS 恢复到 0.9 标幺以上"。有了这个定义，模型就能把统计量翻译成结论，而不是干巴巴地报数字。
还有一个实用技巧是让工具直接返回"建议的可视化数据"。比如在扫描工具里顺手生成一张折线图，把路径返回给客户端，用户就能在对话里直接看到电阻-电压曲线，不用再手动导出数据去画图。这个功能说大不大，但对使用体验的提升很明显，尤其是在跟非技术同事沟通结果的时候。
5. 踩坑记录与常见问题速查
5.1 仿真不收敛与步长选择的坑
电磁暂态仿真里最常见、也最让人抓狂的问题就是不收敛。报错信息通常很含糊，什么"求解失败""时间步推进受阻"之类，光看报错根本不知道从哪儿下手。我自己踩过的坑里，绝大多数都跟步长和模型的时间常数不匹配有关。
PSCAD 里有很多元件内部带时间常数，比如控制系统的积分器、测量环节的滤波器、避雷器的非线性特性。这些时间常数如果比仿真步长还小，数值积分的稳定性就会出问题。一个典型的场景是加了 PLL 的新能源并网模型，PLL 的锁相环带宽通常在几十赫兹到几百赫兹，对应时间常数在毫秒级，看着比步长大得多，但控制内部的采样环节和限幅环节会把有效时间常数压到几十微秒，步长设 50 微秒就会让某些环节"跳过"状态变化，导致数值振荡。
排查思路很朴素：把步长减半再跑一遍。如果减半就收敛了，那就是步长问题；如果减半还是不收敛，那就是模型本身的参数或者拓扑有毛病。这一招简单粗暴但极其有效，我几乎每次遇到不收敛都会先试这一下。
还有一个坑是线路模型的分段数。贝格隆模型和频率相关模型都要求线路被分成若干段，每段的传播时间必须大于步长。如果一条短线被分了很多段，每段传播时间小于步长，就会报错。解决办法要么是减少分段数，要么是减小步长。这两者其实是矛盾的，实践中得权衡：短线本来就不需要那么多分段，直接改成集中参数模型往往更省事。
注意：不要为了"更精确"就盲目把步长设得特别小。步长从 20 微秒减到 5 微秒，仿真点数变成四倍，运行时间也变成四倍，而精度提升往往看不出来。步长选择的标准是"能分辨你关心的最快过程"，不是"越小越好"。
5.2 通道名匹配失败的排查
通道名对不上，是自动化场景里另一类高频问题。人工操作时你在图上勾选输出，运行完在曲线窗口里自然能看到，不会关心通道的"全名"是什么。但自动化必须用全名去取值，名字差一个字符就取不到。
常见的失败原因有几个。一是大小写，Bus1.V1和bus1.v1在 PSCAD 里是两个不同的通道。二是分隔符，有些工程里通道名用的是冒号而不是点号。三是元件重命名，画布上把元件改了个名字，输出通道名跟着变，历史代码就失效了。四是最隐蔽的一种：工程里定义了输出通道，但没有在仿真控制里勾选"记录输出"，运行时根本不产生数据。
我的处理办法是在read_channels工具里做两件事。第一，通道不存在时返回候选列表，按后缀匹配排序，把V1、V1_rms、V1_abc这些都列出来，模型一看就知道该选哪个。第二，专门做一个list_channels工具，只列通道名不取数据，成本很低，可以随时调用。有了这两个机制，通道名问题基本不会阻塞流程，顶多多花一两次调用。
5.3 大模型乱调工具与幻觉参数
这个坑不涉及仿真技术，但同样能把流程搞崩。表现是模型调用工具时传了工程里不存在的参数名，或者把单位搞错、把数量级搞错。比如你要它设过渡电阻 1 欧，它给你设成 1000 欧，理由是"千欧更常见"。
防这个的思路分两层。第一层是工具层面的硬校验，参数不存在、超范围、类型不对，一律拒绝，返回信息里带候选和范围。第二层是提示词层面的软引导，在系统提示里写清楚系统的电压等级、基准值、常用量纲，让模型在生成参数之前有个参照。举个例子，提示词里写"本系统为 220 千伏，母线电压通道单位为千伏，标幺基准 179.6 千伏"，模型在解读数据时就不会把 179.6 当成"电压过高"。
还有个小技巧是给关键参数设"合理性区间"。在set_parameters里对已知的物理量做粗略的区间检查，比如电阻值在 0 到 1e6 之间、时间在 0 到 100 之间，超出的直接拒绝并要求确认。这种粗检查拦不住所有错误，但能拦住最离谱的那一类。
5.4 常见问题速查表
把上面这些整理成一张表，方便随时对照。
| 现象 | 最可能原因 | 排查动作 | 解决方式 |
|---|---|---|---|
| 仿真报求解失败 | 步长大于模型内部时间常数 | 步长减半重跑 | 减小步长或简化控制环节 |
| 仿真报线路分段错误 | 分段传播时间小于步长 | 查看线路段数与长度 | 减少分段或改集中参数模型 |
| 通道读取返回不存在 | 名称拼写、大小写、分隔符 | 调 list_channels 看全量 | 用候选列表纠正名称 |
| 通道存在但数据为空 | 未勾选记录输出 | 检查仿真控制的输出配置 | 在工程中补齐输出配置 |
| 参数写入失败 | 路径错误或类型不符 | 查看返回的 suggestions | 按候选路径重试 |
| 模型给出离谱参数值 | 单位或量纲理解错误 | 检查工具入参 | 系统提示补量纲说明 |
| 运行时间异常长 | 仿真时长或步数过大 | 看返回的 steps 和 wall_time | 降低点数或缩短时长 |
| 许可证冲突 | 其他进程占用席位 | 检查是否有图形界面开着 | 关闭其他实例或排队 |
6. 工程化打磨：性能、一致性与可复现
6.1 批量任务的并发与资源占用
单机跑仿真的瓶颈很少在 CPU 上——PSCAD 的求解器是单线程的，一个工程跑起来基本只占一个核。真正的瓶颈是许可证数量和内存。一台 32G 内存的机器，同时开四个 PSCAD 实例跑中等规模的工程是可以的，每个实例占 4 到 6G；但如果工程里包含大量的线路模型和详细的控制系统，单个实例就能吃到 10G 以上，这时候并发两三个就到头了。
我现在的做法是在服务端加一个简单的任务队列，模型发起批量任务时把每个工况打包成一个任务丢进队列，由固定数量的工作进程消费。工作进程数默认设成min(许可证数 - 1, 物理核数 // 2)，给桌面操作留一个许可证余量。这样既能吃满资源，又不会因为抢许可证把同事的图形界面卡掉。
队列还有一个好处是可以做失败重试。有些工况因为数值振荡偶尔会失败，重跑一次往往就过了。当然重试次数要限制，默认两次，超过就标记为失败并记录，不要无限重试把队列堵死。
6.2 结果一致性校验
自动化跑出来的结果，最怕的是"看起来对但实际不对"。人工操作时你会下意识地核对一下波形形状，自动化时这个环节容易缺失。我的办法是给关键通道加一道"物理合理性"检查。
比如监测的是母线电压，那它的标幺值应该在 0 到 1.5 之间，超出这个范围要么是故障太严重导致数值问题，要么是单位设置错了。再比如故障电流，峰值应该跟系统短路容量在同一量级，差一个数量级肯定有问题。这些检查写成一个sanity_check函数，每次运行完自动跑一遍，不通过就在返回值里带上警告，模型看到警告会主动提示用户复核。
另一个校验手段是"同工况重跑"。对同一个参数组合连跑两次，比较两次的峰值和 RMS，差异应该为零（PSCAD 是确定性求解器）。如果差异不为零，说明有随机因素混进来了，比如某个元件用了随机初值，或者两次运行之间工程状态没清理干净。这个检查在调试阶段很有用，能揪出不少隐蔽的状态残留问题。
6.3 一些实际体会
这套东西跑了大半年，最大的感受是：大模型在这个流程里的角色更像一个"懂业务的操作员"，而不是"专家"。它擅长的是把模糊需求翻译成一系列确定动作、把结果整理成人能看懂的结论、在出错时尝试合理的替代方案；它不擅长的是判断"这个步长选得对不对""这个故障电阻范围合不合理"这类需要领域经验的事情。所以系统的设计重心应该放在"把领域经验固化进工具和提示词"，而不是指望模型临场发挥。
另一个体会是，工具的数量要克制。我一开始恨不得把 PSCAD 的每个功能都包成工具，结果模型面对二三十个工具反而不知道该用哪个，调用成功率明显下降。后来砍到六个核心工具，每个都写得足够详细，成功率反而上去了。工具少了，模型的选择空间小，出错的机会也少，这个道理跟给人写操作手册是一样的。
最后一个体会是关于"可复现"的。凡是自动化跑出来的结果，一定要把当时的参数快照、PSCAD 版本、步长、仿真时长全部记下来，最好是连同工程文件一起归档。因为过两个月回头看一张表，你根本想不起来当时用的什么条件，而模型是不会替你记住这些的，它每次对话都是新的开始。归档这件事看着繁琐，但真到了要复现某个异常结果的时候，你会感谢当时的自己。
