一次城市内涝或管网评估，常常从整理 GIS 图层开始：划分汇水区、准备降雨资料、配置参数、组装管网、运行模型，再检查结果和写报告。环节多并不意味着可以把判断全部交给聊天框。真正需要自动化的是可重复的操作，真正需要留下的是每一步的证据。

开源项目 Agentic SWMM Workflow 尝试把自然语言的任务协调接到 EPA SWMM 的确定性执行上。项目把 QGIS 预处理、模型生成、SWMM 运行、质量检查、溯源记录、校准和情景支持串成工作流；它明确把人类建模人员保留在控制位置。这个边界很重要：Agent 可以拆解和调用步骤，不能替代对数据、假设和结果的工程判断。

先分清谁在“说”，谁在“算”

EPA 的 SWMM 是面向雨水、合流制和卫生污水排水系统的模型软件，可做单次事件或长期连续的径流量与水质模拟。官方资料说明，它能够表示降雨、蒸发、下渗、地表径流、管渠水力等过程，并提供运动波或完整动力波等水力计算选项。这里的求解器输出应当来自固定的输入文件与可复跑命令，而不是语言模型的一段解释。

Agentic SWMM 的思路是把自然语言请求翻译成受约束的工作步骤，同时保留 model.inp、SWMM 报告与二进制输出、命令记录、QA 摘要、图表和溯源文件。项目 README 将它定位为“验证优先”的框架，并说明模型执行保持可检查、可通过命令行运行。对使用者而言，最有价值的不是“模型回答了什么”，而是能否沿着产物追到：用了哪份降雨数据、哪个管网版本、什么参数和哪次运行。

一个可落地的工作分工

以一次片区暴雨排水评估为例，先由人工定义分析范围、设计暴雨或实测降雨的适用性、管网资料来源和结果用途。然后让工作流处理重复性任务：核查输入是否齐全、生成或整理 SWMM 输入、调用求解器、汇总峰值流量与积水相关指标、输出图表与审计记录。

每个阶段都应有明确的停止条件。资料缺失、坐标或单位不一致、降雨时段不覆盖目标事件、模型没有校准时，系统应把这些问题作为未通过项，而不是补写一个看似完整的结论。项目给出的案例也强调，当目标时段实际无有效降雨时，应报告该限制，不能交付没有依据的数值。这个原则适用于任何 Agent 驱动的工程计算。

把 QA 设计成可复跑的门槛

项目描述的运行产物包括输入文件、.rpt 与 .out 输出、清单和命令轨迹、QA 汇总、峰值流量解析结果以及试验溯源记录。它还把 GIS、气候、建模、运行、绘图、校准、不确定性和审计拆成可复用模块。这样的拆分不等于自动获得可信结果，但方便团队把检查写成明确门槛。

建议把以下检查固化在每次运行前后：

  1. 记录模型边界、数据版本、坐标系、单位和降雨时间范围，并让审阅者确认其适用性。
  2. 保存输入文件及生成方式；重新运行时比较输入差异，不能只保存一张结果截图。
  3. 读取 SWMM 报告中的警告和连续性误差，明确哪些阈值会阻断出图或报告。
  4. 将峰值流量、节点溢流等摘要重新从原始输出解析，并与报告中的数值交叉核对。
  5. 对没有校准或验证的模型，在标题、图例和结论中标注用途边界；情景对比不能被包装成预测精度证明。
  6. 把命令、环境版本、数据来源和审计说明一同归档，使另一位工程师能复跑和追问。

自然语言入口不等于降低治理要求

项目支持通过自身运行时或外部 Agent 运行时协调技能和 MCP 接口，也提供 Docker 与 Python 包等安装路径。这有助于把繁琐步骤串起来，却不会自动解决数据授权、参数选择、校准样本不足或责任归属。尤其是从 GIS 数据自动合成基础网络时，生成的网络可以是后续分析的起点，但不应在未校准、未核验的情况下直接作为工程设计依据。

EPA 也将 SWMM 用于规划、设计和决策支持等场景。这正说明输入和假设需要与业务情境相匹配：同一套模型可以用于方案比较，却不必然适合宣称某次降雨的精确预测。把 Agent 放在可审计流程中，反而能让这种差别更清楚。

结论

Agentic SWMM 的可取之处，是用自然语言协调工作而不遮住求解、QA 和溯源产物。团队应先建立可复跑的输入、质量门槛和人工审阅，再让 Agent 节省重复操作。能复查的模型流程，才有资格成为决策材料。

资料来源