水务、能源和交通系统常以运维记录、图纸说明、设备清单与空间资产台账描述现场。它们既不能被随意主动扫描，又需要支撑风险判断和合规审计。arXiv 论文《From Legacy Documentation to OSCAL》提出一条 MCP 约束的多智能体路径：把自然语言系统描述转换为可溯源知识图谱和 NIST OSCAL 审计产物。对承担关键基础设施 GIS 的团队，重点不在于让模型“读懂地图”，而在于让每个资产、版本、地点关系和威胁关联都能回到来源，并能被人工复核。

可核查事实

  • 论文于 2026 年 7 月 9 日提交至 arXiv，题为《From Legacy Documentation to OSCAL: An MCP-Based Agent Pipeline for Threat-Informed Continuous Compliance in Critical Infrastructure》。
  • 作者指出，关键基础设施的 operational technology 环境通常不能被主动扫描，但风险评估和合规管理仍需要系统反馈。
  • 该路径将自然语言系统描述转换为 source-verified knowledge graph 和 NIST OSCAL audit-ready artifacts。
  • 架构将 LLM-based reasoning 与对 authoritative threat-intelligence sources 的 deterministic knowledge retrieval 分离。
  • 论文以 water utility 的 evidence-based synthetic scenario 进行验证。
  • 该场景报告 0.90 CVE recall 和 perfect D3FEND recall。
  • 输出包含 schema-valid OSCAL System Security Plan 与 OSCAL Security Assessment Report。
  • 作者也说明错误未被消除：自然语言中的错误 asset extraction 会把真实但无关的 CVE 带入后续阶段。

这些事实来自论文摘要，场景结果不能直接外推为任意城市、能源网络或生产系统的合规结论。

核心机制

关键基础设施的 operational technology 环境通常不能被主动扫描，因此资料抽取必须保留“文件里如何说”和“现场是否如此”之间的边界。该方法把自然语言系统描述转换为 source-verified knowledge graph 和 NIST OSCAL audit-ready artifacts；对 GIS 团队而言，节点可以是泵站、阀门、控制器、通信链路、分区或机房，边必须带上资产编号、位置依据、版本、时间和原始文档定位。

架构将 LLM-based reasoning 与对 authoritative threat-intelligence sources 的 deterministic knowledge retrieval 分离。模型可协助把散文拆成候选实体和关系；确定性检索负责把候选与可追溯的 CVE、缓解措施或控制要求相连。不要让语言模型自行补全未在台账、图纸或权威情报中出现的设备型号、网络边界和版本。

GIS 场景

以水务 GIS 为例，资产系统中的泵房面、管网线和远程终端点常来自不同年代的资料。合规审查需要回答的不是“地图是否有图层”，而是某控制器是否确实位于该泵站、接入哪一段网络、文档何时更新、其软件版本的证据来自哪里。论文的 water utility evidence-based synthetic scenario 提供了一个可复现的思路：先建立资产和空间关系的候选表，再让每条风险关联带回文档页码、台账记录或权威检索结果。

对含敏感坐标的系统，审计产物应分级保存。OSCAL 中可引用抽象资产标识和控制关系，精确位置、网络拓扑和原始图纸留在受控系统；审阅者通过权限和引用键完成核验。这样既不会把空间细节复制进自由文本，也不会让“无法公开”成为无法审计的理由。

技术路径

先定义资产抽取合同：资产类型、唯一标识、空间几何或区域、数据源、文档页码、观测时间、版本、置信度和人工确认状态。每个候选必须允许三种结果：确认、否决或待补证；不能因模型给出了流畅描述就自动成为正式台账。

再把检索和推理拆开。论文输出 schema-valid OSCAL System Security Plan 与 OSCAL Security Assessment Report，说明结构化交付物可以在 schema 层先被验证。工程上应先验证 OSCAL schema、引用是否可解析、资产标识是否存在；然后才检查 CVE、控制项与空间资产之间是否具有正确版本、网络分区和时间条件。

最后设计人工复核队列。论文报告 0.90 CVE recall 和 perfect D3FEND recall，但同一论文也指出错误 asset extraction 会将真实却无关的 CVE 传入下游。应把低置信实体、位置冲突、缺版本记录和一对多风险映射排到人工队列，记录复核人、依据、修改和回退原因。

验证设计

验证至少分为四层。第一层以脱敏资料测实体抽取：设备名称、厂站、文档页码与空间关联是否正确。第二层测确定性检索：每个 CVE 或缓解项是否能回到权威来源，且版本条件没有被省略。第三层测 OSCAL：schema、引用、控制映射和审计报告能否解析。第四层测人工审核：抽样重建从风险条目到资产与原始资料的路径。

指标不能只用召回率。除 CVE recall 外，持续记录错误资产抽取率、真实但无关风险的比例、无法定位的资产数、来源失效率、人工驳回率和平均复核时间。空间资产发生迁移、替换或拆分时，也要比较旧几何、当前几何和文档版本，避免旧记录被错误投射到新设施。

风险边界

0.90 CVE recall 和 perfect D3FEND recall 是论文 water utility synthetic scenario 的结果，并不证明生产环境也能达到相同效果。自然语言资料可能过期、缺页或把相邻设施混为一谈；空间图层也可能含有简化几何、历史名称和受限位置。更严重的是，错误 asset extraction 可产生真实但无关的 CVE，这会消耗审计资源并干扰处置优先级。

因此，任何自动生成的合规产物都应保持草稿和证据链状态，不能直接替代现场核验、变更管理、访问控制或安全响应。对于关键设施，敏感网络与坐标资料应留在受控环境，外部模型和检索服务只接触经过审批的最小必要信息。

检查清单

  1. 每个资产、地点关系和版本是否都有原始资料定位与时间戳？
  2. 自然语言抽取结果是否允许确认、否决和待补证，而非自动入库？
  3. CVE 与缓解措施是否来自可追溯权威来源，并匹配具体版本和网络边界？
  4. OSCAL 的 schema、引用和控制映射是否独立验证？
  5. 是否单列真实但无关风险、位置冲突和版本缺失供人工审核？
  6. 敏感坐标、网络拓扑和原始图纸是否按权限分层保存？
  7. 是否能从任一审计结论回放到资产、空间证据和原始文档？

结论

把历史文档转成合规资料的价值，来自可验证的证据路径，而不是自动生成的篇幅。对关键基础设施 GIS，先固定资产与空间关系的来源，再分离模型推理、权威检索、OSCAL 验证和人工复核，才能让风险条目既可追溯，也不会越过生产系统的安全边界。

参考来源

  1. Muth、Margraf，《From Legacy Documentation to OSCAL: An MCP-Based Agent Pipeline for Threat-Informed Continuous Compliance in Critical Infrastructure》：https://arxiv.org/abs/2607.08288