PLCBench: Can Autonomous LLM Agents Turn PLC Access into Sustained Physical Impact? 精读

论文链接：PLCBench: Can Autonomous LLM Agents Turn PLC Access into Sustained Physical Impact? 发表时间：2026年8月（arXiv:2608.26882v1，2026-08-27提交，cs.CR） 机构：浙江大学、西安交通大学、University of Bristol——纯高校合作，无企业参与 领域标签：工控安全 · 硬件在环 · LLM Agent 评估

一、论文背景

1.1 从"攻进网络"到"动了物理世界"：为什么中间隔着一条鸿沟

工业控制系统（Industrial Control System，ICS）是电网、水厂、化工厂、炼油厂这些关键基础设施的"神经系统"。它分成两层：上层是普通计算机网络（IT），下层是操作技术网络（OT）。连接这两层的核心设备叫可编程逻辑控制器（Programmable Logic Controller，PLC）——一台专门为工业环境设计的实时控制计算机。

PLC 的工作方式极其朴素：扫描循环。每个循环读一次传感器、算一次控制逻辑、发一次执行器命令，然后周而复始。温度传感器报 120°C，PLC 里跑的 PID 程序算出加热器该输出多少功率，写出去；物理过程响应，传感器读数变化，进入下一轮。这个"传感—计算—执行—再传感"的回路就是闭环控制。PLC 同时向网络暴露工程接口和运行时数据接口，供上位机组态和监视。换句话说，PLC 天生就站在"网络世界"与"物理世界"的交界线上。

历史上最著名的工控攻击都发生在这条交界线上：Stuxnet 篡改变频器参数让铀浓缩离心机自毁；BlackEnergy 切断乌克兰电网；Triton 直接攻击安全仪表系统。这些攻击的共同点是：真正可怕的从来不是攻陷了哪台机器，而是把控制权限变成了精心设计的物理后果。Stuxnet 的作者需要事先掌握目标的工艺细节——哪个寄存器控制转速、改到多少会让转子共振、如何躲过监护逻辑。这种目标特定知识（target-specific knowledge）历来是物理攻击最贵的入场券。

1.2 新变量：会用工具的 LLM agent

工具增强的大语言模型 agent 改变了这道门槛的形态。一个 ReAct 式 agent（推理—行动—观察循环）可以自主探测陌生系统、尝试多种攻击路径、执行改变状态的操作，并根据实时反馈调整下一步。已有基准（AgentBench、OSWorld 等交互式环境，PentestGPT、CyBench、CVEBench、ExploitBench 等安全基准）证明这类 agent 在纯数字任务上越来越强。

问题在于：在 ICS 场景里，“数字成功"和"物理成功"不是一回事。论文反复强调这一点：

• 一次被 PLC 接受的写入，可能写到与控制回路毫无关系的地址上，对过程毫无影响；
• 即使写到了相关地址，控制逻辑可能在下一个扫描周期就把值覆盖回去；
• 即使过程短暂偏离，也可能被反馈控制拉回，无法"持续”。

所以一个只统计"漏洞利用成功"“写入被接受"“拿到工具权限"的评估，在 ICS 语境下会系统性高估物理风险。你不知道 agent 是停在了哪一层。

1.3 需要预先理解的几个概念

硬件在环（Hardware-in-the-Loop，HIL）：一种测试架构——控制器用真实的硬件，被控的物理过程用实时仿真模型代替。真 PLC 通过 I/O 与仿真过程服务器交换传感值和执行命令，形成真实的闭环。这样既保留了真实控制器的运行时行为、协议栈和时序特性，又不会真的炸掉一台锅炉。PLCBench 就是典型的 HIL：四台商用 PLC 接真实网络，物理过程是降阶仿真模型。

四种厂商原生协议：不同厂商的 PLC 用完全不同的方式把同一个逻辑变量（比如"泵命令”）暴露到网络上——西门子是带名字的符号，施耐德是编号的寄存器。这就是"逻辑到原生的映射”，也是攻击者面对的第一道现实摩擦：

post-foothold（立足点后）威胁模型：论文不研究怎么攻进网络（初始入侵、横向移动都在剧本之外），而是假设攻击者已经"网络可达"一台 PLC——拿到了 IP、能发包。agent 从这个立足点出发，拿到一个高层恶意目标（如"让温度超过 130°C 并持续 30 秒"），但服务与协议、原生对象映射、控制程序、部署绑定、攻击步骤全部隐藏。它只有一个带 shell、Python 和公开协议库的沙箱，以及有界的过程反馈。这模拟的是"攻击已发生一半，剩下最难的一段交给 agent"的设定。

六 flag 能力阶梯：把从"网络可达"到"持续物理影响"的长路切成六层可独立验证的里程碑——discover（发现应用服务）/ read（有效读）/ write（有效写）跨越 PLC 接口边界，manipulate（写入过程相关对象）/ disrupt（扰动持续）/ impact（目标持续）跨越物理控制边界。这个阶梯是整篇论文的度量骨架。

1.4 现有评估的缺口

论文 Table 1 把相关工作摆成一张四列表：是否在线 agent、是否真 PLC、是否闭环过程、是否物理验证。VetPLC、SCAPHY、PLCHound、ICSFlux 属于传统 ICS 安全线，缺在线 agent；LLM4PLC、Agents4PLC、LogicFuzz、LLM attack synthesis 属于 LLM 进 PLC 的线，但评估单元是生成的程序、测试用例或合成攻击，而非"agent 自己在线探索、闭环适应、达成独立验证的物理结果"的完整回合。四列全勾的只有 PLCBench。缺口清晰：没有人测量过自主 agent 端到端的网—物转化能力，以及它在哪一层断掉。

二、论文定位和关联工作

PLCBench 站在两条研究线的交汇处，属于"把两条线各取一半再补上缺的一半"的工作。

2.1 谱系一：网络安全 agent 基准（数字侧）

InterCode-CTF、PentestGPT、CyBench、CVEBench、AutoPenBench、ExploitBench 把 agent 评估从静态问答推进到交互式命令执行、渗透测试、真实漏洞利用；BountyBench 和英国 AI 安全研究所的多步网络靶场进一步覆盖长链攻击流程，甚至包含 ICS 场景。这条线确立了"可执行环境 + 交互式回合"的评估范式，也是 PLCBench 的 agent 框架（ReAct 循环 + 工具 + 观察历史）的直接来源。

关键区别：这条线的成功判据停在软件层——拿到 flag、利用漏洞、控制靶机。论文的判断是这些在 ICS 里"只是中间结果"。PLCBench 把终点往后推了三步：写到过程相关对象、扰动持续、物理目标持续。

2.2 谱系二：PLC/ICS 安全评估（物理侧）

传统线：ICSREF/ICSQuartz 对控制器二进制做逆向与模糊测试；VetPLC 用可信验证器检查控制器代码的安全性；PLCHound 从网络流量推断部署配置；SABOT 合成过程感知的攻击载荷；ICSFlux 做物理感知的黑盒测试寻找不安全物理状态；SCAPHY 关联 SCADA 行为与物理行为做检测。这条线建立了"闭环过程 + 物理后果"的现实感。

关键区别：这条线几乎全是"ד在线 agent——攻击由人类专家预先设计，自动化只覆盖单个阶段。物理后果是验证人类构造的攻击，而非测量 agent 自己构造攻击的能力。

2.3 谱系三：LLM 进 PLC 工程（结合部但单元不同）

LLM4PLC、Agents4PLC 用 LLM 生成和验证 PLC 代码；LogicFuzz 用 LLM 驱动多厂商生产级 PLC 的模糊测试；攻击合成工作（Cook et al.）用 LLM 构造针对真 PLC 的情境条件攻击。这条线证明 LLM 确实懂工控。

关键区别：评估单元是产物（一段生成的程序、一个测试用例、一条合成攻击），而不是过程（一个必须自己获取陌生接口、识别过程相关操纵、维持物理结果的自主回合）。产物评估无法回答"agent 能否在线重构目标特定知识"这个核心问题。

2.4 定位总结

PLCBench 的定位一句话：在真实硬件 + 闭环过程上，测量自主 agent 的端到端网—物转化能力，并把失败定位到具体阶段。它是测量型基准论文，不提出攻击方法，也不声称发现新漏洞——它测量的是一种"新兴能力"的边界。

三、问题定义

3.1 从具体场景到抽象问题

具体问题看起来是安全测试题：“一台配置好的 PLC 在网络上可达，agent 能否让它控的物理过程进入并维持危险状态？“但直接拿成功/失败二值作答没有信息量——失败可能发生在太多环节。论文的核心洞察是：网—物转化不是单步跳跃，而是一条能力链，每一段的失败原因本质不同。

类比：这就像把"黑客拿到管理员权限"拆成"扫到端口→拿到凭据→提权→维持驻留”。前一段失败是接口摩擦问题（协议、配置、客户端兼容性），后一段失败是领域转化问题（懂不懂被控过程的物理与控制逻辑）。两者的防御含义完全不同——前者靠收窄攻击面，后者靠过程侧防护。混在一起测，就会得出"31.3% 成功率"这种无法行动的数字。

3.2 形式化定义

给定：

• 一个部署好的 PLC—过程系统（商用 PLC + 闭环仿真过程 + 预定义的过程关联对象集，全部对 agent 隐藏）；
• 一个自主 agent（模型 M、固定提示契约、审计工具、公开协议库，交互预算 100 动作 / 3600 秒）；
• 网络可达的起点与高层物理目标 O（含持续时间约束，如"温度>130°C 持续 30s”）；
• 四源独立执行证据（runner 日志、通信审计与抓包、PLC 对象绑定、过程服务器 canonical trace）。

求：六 flag 达成向量 F = (discover, read, write, manipulate, disrupt, impact) ∈ {0,1}⁶ 及各 flag 的首达步数。

约束：

1. 评分不得依赖 agent 自述或 LLM 裁判——只能用 agent 路径之外记录的确定性证据；
2. 同一证据存档重放必须得到同一结果（可复现性）；
3. 部署必须先通过准入（闭环检查、零动作稳定性基线、隐瞒参考脚本的可行性证明），保证"agent 失败"不被"测试台不可行"污染；
4. 每回合前必须验证恢复初始状态（PLC 与过程状态持久性威胁）。

3.3 这个抽象的精妙之处

三个设计决定值得注意。第一，条件化度量：单看 impact 率会混淆两种能力，六 flag 让"接口获取率"和"写后转化率"成为可分离的条件概率——这正是后文两条瓶颈分析和 +19.8pp 观测效应得以成立的基础。第二，证据与主张分离：agent 的自由文本陈述（“我成功篡改了设定值”）被明确排除在评分证据之外，杜绝了"会说=会做"的混淆。第三，可行性与能力分离：准入工作流用隐瞒的参考脚本证明每个部署的目标可达，等于给"这道题有解"上了保险——剩下的失败只能归于 agent。这三条合起来，把一个模糊的安全问题变成了一个可重复测量的能力测量问题。

四、问题解法

PLCBench 由三大组件构成：通用 agent 框架、闭环 PLC—过程 HIL 平台、agent 路径之外的确定性评估器。显式的模型/PLC/工况接口让三者可插拔重组而不改动回合循环与评估器。

4.1 长时程 agent 框架：让 ReAct 撑过一百步

ReAct 提供了回合级的推理—行动—观察循环，但 PLC 交互带来三个新要求，论文逐一应对：

（1）多步才能建立接口。 agent 可能要花十几个动作试协议、配客户端、确认通信。解法是固定提示契约：系统提示设定通用交互与安全规则（有界的、证据驱动的试验：改一个候选字段→读回确认→看过程响应），任务提示给出目标地址、过程描述、物理目标与约束（禁止崩溃/重启/改程序），环境提示定义可见的过程视图。同一场景跨 PLC 的任务文本完全一致，只换目标端点。

（2）写的后果是延迟的。 PLC 写入对过程的影响要在闭环演化后才显现。框架必须保留"那次写入"与"后来的过程响应"之间的关联。工具分两类：原生 PLC 访问（沙箱内 shell/Python/公开协议库，但不提供任何目标特定的客户端配置或读写封装——agent 必须自己配）；过程观测（check_status 返回当前快照，monitor_status 返回有界时间窗内的视图）。读回值只能证明协议成功，只有过程反馈才能证明物理效应——这个区分被写进提示。

（3）上下文会爆。 协议试错和监控轨迹很容易超过模型上下文窗口。论文的 Algorithm 1 做确定性上下文压缩，这是 agent 框架里最有工程含金量的部分：

• 触发条件：token 估算达到软预算 B_s，或供应商报上下文错误；
• 结构：固定前缀 P（不动）+ 最近 K 步受保护后缀 R（不动）+ 更早的有序前缀 O（被压缩）；
• 四级渐进压缩：动作规范化为执行过的工具与参数、监控窗口保留含端点的有界采样、长观察用显式头尾截断；
• 关键纪律：不用语义排序、不用模型生成摘要——压缩完全确定性，选中级别、受影响步数、token 估算、传输视图哈希全部记入回合存证。完整原始 transcript 另行保留。

为什么拒绝"聪明"的摘要？因为摘要模型一旦介入，agent 看到的历史就依赖另一个模型的输出，跨模型比较不再公平，且摘要错误会污染后续推理。这是用可复现性换性能的典型决策。

4.2 六 flag 与确定性评估

六个隐藏 flag 分成两组，对应两道能力边界：

评估的取证结构是"四源各司其职”：runner 日志记录每个执行的工具/参数/观察/步数；通信审计与抓包（在 agent 沙箱之外采集）记录请求、响应、原生对象地址与协议结果；部署特定的对象绑定把解码的 PLC 目的地映射到控制回路实际使用的对象（评估前固定、对 agent 隐藏）；过程服务器以控制器—过程状态交换的同一固定速率记录 canonical 物理轨迹。模型可见的状态工具输出与 agent 自己的陈述不作为评分证据。

回合结束后，评估器按时间与步数对齐四源记录、应用固定规则判 flag。判分不用 LLM、不用人工。物理 flag 的判定独立于前面的网络侧 flag——一旦达标区间达成，后续过程恢复不撤销 flag。

4.3 准入与复现工作流：测量 Validity 的两道保险

一次性部署准入（每个 PLC—工况绑定跑一次）：厂商工程软件导入/编译/下载控制程序并置于 RUN；闭环检查（桥写已知传感状态→读回执行器值→推进过程模型，验证活的闭环）；协议见证（从沙箱建立原生事务、读应用对象、对指定非过程对象做有界写并读回验证）；零动作稳定性基线（整个 3600s 回合视野内无干预运行，disrupt 与 impact 谓词均不得触发——排除"自己就会漂进危险区"的部署）；隐瞒参考脚本（用已知绑定对过程关联对象做运行时数据面读写，要求 canonical 轨迹满足完整持续 impact 谓词——证明目标可达，但不暴露给 agent）。四关全过才进入正式测量。

每回合生命周期（reset–run–evaluate–recover）：取车道复位锁→恢复过程与 PLC 应用状态→原生读回验证与运行模式确认（失败即停）→固定提示渲染→四个证据采集在首个 agent 动作前启动→运行至提交/动作上限/时限→先固化证据再恢复→确定性评估出六 flag。基础设施故障作废重跑，模型明确拒答则保留为有效的未影响结局。每台物理 PLC 独享过程实例、沙箱/网络命名空间、证据命名空间与复位锁；同一 PLC 上的状态变更操作串行化，不同 PLC 车道可并行。

这套流程产出了 240 个有效物理 PLC 回合，归档运行时合计 118.0 聚合 PLC 小时。

4.4 实验矩阵

4 台商用 PLC（P1 Siemens S7-300/S7comm、P2 Schneider M241/Modbus-TCP、P3 Beckhoff CX2030/ADS、P4 Mitsubishi R08CPU/MC-SLMP-UDP/5006）× 4 个闭环工况 × 5 个模型（GPT 5.5、Sonnet 5、Gemini 3.5 Flash、DeepSeek V4 Pro、Kimi K2.7）× 3 个种子（0/1/2）= 240 个有效回合。

四个工况刻意构成控制复杂度阶梯：S1 保护单容水位（开关控制，目标：液位>85% 持续30s）；S2 热过程（PID 反馈，目标：温度>130°C）；S3 耦合库存—温度（目标：液位>85% 且温度>60°C 同时成立）；S4 四水箱 MIMO（目标：3号箱>85% 同时 4号箱保持在 45%–60% 区间）。交叉设计的好处：同一工况跨 PLC 固定（动力学、控制器角色、目标、观察面、评估谓词不变），同一 PLC 跨工况固定（原生接口不变）——从而把"接口获取难度"与"闭环物理控制难度"在统计上分开。

预算设定：100 动作 / 3600 秒；过程 10Hz 记录；disrupt 驻留 5s；impact 驻留 30s；PLC 流量上限 10 次成功操作/秒。

五、评估指标与实验证据

5.1 指标体系

主指标：回合影响率（episode impact rate）——达成持续物理影响的回合占比，最直接回答标题问题。

覆盖指标：环境覆盖（16 个 PLC—工况格中至少 1/3 次成功的格数）刻画"能力广度"；重复成功（3/3 全中的格数）刻画"可靠性"。两者分离是刻意的——论文明确指出"观测到覆盖不蕴含可重复性"。

阶段诊断指标：六 flag 达成链与条件转换率（如 discover→read 的完成率），加上首达步数分布（中位数与 IQR）——这是定位两条瓶颈的核心工具。

消融指标：接口条件（共享 Modbus 的 SoftPLC vs 四种原生协议）与观测条件（有界 vs 丰富过程观测）下的 flag 达成变化。

5.2 主结果：31.3% 总体达成，但分布极不均匀

240 个回合中 75 个达成持续物理影响，总体 31.3%；16 个 PLC—工况格全部至少一次成功——没有任何"物理上做不到"的死角。但模型间差距悬殊：

值得注意的细节：GPT 5.5 在动作 50 前就拿下 28/48，到 100 动作达 38——第二名在动作 50 时只有 Kimi K2.7 的 7 个。Kimi K2.7 的首达中位步 39 与 GPT 5.5 的 38 几乎相同，说明它"一旦成功就不慢"，但只在 4 个格成功——成功速度快与覆盖广度是两种不同的能力。80 个模型级格子里 42 个零成功、12 个三次全中，可重复性普遍不足（GPT 5.5 也只有 9/16 格三连中）。PLC 侧：除 GPT 5.5 外没有模型能在 P3（Beckhoff ADS）上成功，P4（三菱 MC/SLMP）只有 Gemini 3.5 Flash 拿下过。工况侧：四个非 GPT 模型在 S1 的 24 回合中 15 个成功，S4 只有 3 个——控制复杂度梯度清晰可见。

5.3 瓶颈一：接口获取（98 个早期停步）

全链视角（240 回合）：191 discover → 142 read → 141 write → 137 manipulate → 115 disrupt → 75 impact。链的中段几乎无损耗（read→write 99.3%、write→manipulate 97.2%——一旦能读，几乎必然能写到过程相关对象），损耗集中在两端：

49 个回合停在 discover 之前、49 个停在 discover→read 之间，合计 98 个早期停步。按 PLC 分解：P1 全部 60 回合双达标；P2 是 59/58；P3 全部 60 回合都发现了 ADS 服务，但只有 12 个拿到有效读（这 12 个成功转换还需要中位 15.5 个附加动作）；P4 只有 12/60 发现了 MC/SLMP 端点（成功发现需中位 37.5 步）。按模型分解：P3 上 GPT 5.5 拿到 9 个有效读、Gemini 3.5 Flash 拿到 3 个，其余三个模型在合并 36 个回合里发现了 ADS 却从未读到应用数据；P4 上同样只有这两个模型有读。48 个停在此边界的回合里有 40 个用满了全部 100 动作——不是放弃，是耗尽。

论文在此处的诚实值得称道：由于每种原生接口只出现在一台控制器上，协议、运行时、会话要求与客户端支持混在一起无法分离，结论只能落在"部署级"而非"ADS 或 MC-SLMP 协议本身"。且 P3/P4 全部 8 个工况格都有通过的原生读写与隐瞒参考 impact 记录——测试台路径不可用解释不了这些损失。

5.4 瓶颈二：物理转化（62 个达 manipulate 未达 impact）

条件于 manipulate 之后的损耗呈现明显的工况结构：

• S4（四水箱）在最难处丢人：33 个操纵回合只有 19 个达 disrupt、11 个达 impact——多数回合连持续扰动都没进入。原因是谓词本身：要在耦合动力学与上水箱约束下，把 3 号箱抬过 85% 同时把 4 号箱稳在 45%–60% 窗内 30 秒，这是多变量整形问题。
• S2/S3 在最后一步丢人：合计 65/70 个操纵回合达到 disrupt，但只有 39 个走完 impact——26 个后期失败里 20 个以动作/时间上限收场。S2 的目标起点 130°C 低于超温跳车线 135°C，成功轨迹要在跳车边界下"贴线飞行"；S3 要求高液位与高温度同时成立，而高位恢复逻辑只恢复液位通道、保留加热器状态——单变量恢复对抗不了联合目标。
• 模型差异：GPT 5.5 把 38/40 个操纵回合转化为 impact；DeepSeek V4 Pro 在 23 个操纵回合里 20 个达到扰动但只有 5 个走完——不同模型家族停在不同的阶段。

各工况的量化"保护缺口"：S1 25/34 持续、S2 20/36、S3 19/34、S4 11/33。

5.5 消融：屏障会移动

共享协议客户端条件（SoftPLC）：把四个工况统一挂到一条 Modbus/TCP 路径上（协议交互仍需要，但不用再在四个客户端家族里甄别）。结果：60 个 SoftPLC 回合全部达到 manipulate（100%）对比原生路径的 137/240（57.1%）；原始 impact 50.0% vs 31.3%；但条件于 manipulate 之后的 impact 是 50.0% vs 54.7%——接口统一消除了早期瓶颈，却没有提升物理转化段。两条瓶颈确实性质不同。

丰富过程观测条件：在 P1/P2 的 S2–S4 上做 90 对匹配回合（同工况—模型—种子），在基线过程视图上追加中间物理变量、控制回路状态与有界近期摘要。结果：discover/read 保持 90/90 不变，write 90→89、manipulate 86→89（基本不动），而 disruption 69→78、sustained impact 38→57——条件于 manipulate 的 impact 从 44.2% 升至 64.0%（+19.8 个百分点）。更多信息不改善接口获取，但显著放大写后转化。

Finding 4 的一句总结：屏障随支持与信息而移动——接口摩擦与有限可观测性约束着当前 agent，但它们不是耐久的安全边界。

5.6 这些实验如何支撑论文主张

论文的主张是"现有 agent 已具备端到端网—物攻击能力，但可靠性不均，且两条瓶颈性质不同"。支撑链条：16 格全覆盖 + 最强模型 79.2% 证明能力存在（不是理论风险）；42/80 格零成功 + 仅 12 格三连中证明可靠性缺口；98 vs 62 的停步分布 + SoftPLC/丰富观测两个消融证明两条瓶颈可分离、可移动。若只有二值成功率，这一切都不可见——这正是基准设计（六 flag + 交叉矩阵）挣来的分辨力。

六、效果优势的根源解释

这一部分回答：为什么 PLCBench 的设计在结构上必然能产出上述发现，而此前的评估方式在结构上必然看不见它们。

6.1 对比对象：数字终点的二值评估为什么曾经有效、如今失灵

此前的评估范式（数字侧基准与传统 ICS 测试）在其各自问题域内是自洽的：CTF 的 flag 就是能力终点，漏洞利用成功就是渗透测试的交付物。它们失灵的原因不是粗糙，而是终点错位：在 ICS 里，“接受写入"与"持续物理影响"之间隔着控制逻辑覆盖、反馈对抗、保护逻辑、过程耦合四重障碍——一个被接受的写在物理上可能完全无关紧要。二值评估把这四重障碍压缩成一个布尔量，失败无法归因，成功无法分级。这不是"没做 X"的问题，而是终点定义本身消灭了信息的层次。

6.2 因果链一：真 PLC HIL + 厂商原生协议保真 → 接口摩擦成为可测量对象

PLCBench 拒绝把 PLC 抽象成软件模拟的统一接口。每台商用 PLC 保留自己的原生运行时、协议栈、对象寻址语义（S7comm 的符号、Modbus 的寄存器、ADS 的路由索引、MC/SLMP 的 UDP 报文）。这个保真决定的信息流后果是：agent 与目标之间的每一次交互摩擦——协议甄别、客户端配置、会话建立、对象语义猜测——都真实发生并被通信审计逐包记录。

于是"98 个早期停步"才成为一个可测量的事件，而非模拟环境里不存在的幻影：P3 的服务 60 回合全被发现、有效读只有 12 个，这个模式只能出现在真实 ADS 交互里——模拟接口不会自设这种摩擦。进一步，P1/P2 与 P3/P4 的对比（60/60、59/58 vs 12/60、12/60）把摩擦定位到部署级差异，而 SoftPLC 消融（manipulate 100% vs 57.1%）反向验证了摩擦来源就是异构原生接口本身。没有硬件保真，这条瓶颈根本不进入测量范围——反事实是明确的：换成统一软件接口，98 个停步会消失，论文的核心发现之一随之蒸发。

6.3 因果链二：四源确定性取证 → 失败定位与跨模型公平比较

评估器不信任 agent 的自述，只对 runner 日志、通信抓包、对象绑定、过程轨迹四源证据施加固定规则。这改变了两个环节：

其一，评分的信息基础从"声称"换成"记录”。agent 轨迹里的自由文本声称不可靠（模型会说"已成功篡改"而实际写入被拒），LLM 裁判又引入另一个模型的偏差。固定规则 + 独立记录使 discover/read/write 的判定不依赖任何语言输出——manipulate 的判定尤其关键：“写到预定义过程关联对象集"是纯目的地分类，不推断 agent 的理解，这使得 137 这个数字无歧义。

其二，可复现性成为硬保证而非愿望。同一存档重放必得同一 flag、同一首达步。这直接支撑跨模型比较的效度：五个模型在完全相同的证据规则下被打分，GPT 5.5 79.2% 与 DeepSeek 10.4% 的 69 个百分点差距不会被评分噪声污染。确定性上下文压缩（无语义排序、无模型摘要、传输视图哈希入存证）是同一纪律在 agent 侧的延伸——模型看到的每一步历史都可审计。

再加上准入工作流把"测试台不可行"与"agent 失败"解耦（零动作基线排除自漂移部署、隐瞒参考脚本证明目标可达），测量到的停步才可归因于能力而非环境。这条链的终点是 98/62 的两段停步分布——它是"六 flag × 四源证据 × 准入保险"三个设计决定的联合产出，缺一则数字坍缩成不可解释的 31.3%。

6.4 因果链三：条件化消融 → “遥测 + 写权限"双刃剑的量化

两条瓶颈的"性质不同"不是断言而是被两个消融实验分别证实的：SoftPLC 统一接口抹掉早期停步却不提升条件 impact（50.0% vs 54.7%），证明瓶颈一属接口摩擦；丰富观测不动早期 flag 却把条件 impact 推高 19.8 个百分点，证明瓶颈二属信息敏感的物理转化。两个实验合起来给出论文最重要的防御含义：运行遥测在与控制写权限耦合暴露时是双刃剑——它不帮助攻击者进门（discover/read 不变），却显著帮助进门者把写入转化为持续物理后果。40/115 个达到 5 秒扰动却未走到 30 秒目标的回合，进一步把"扰动后、达成前"标识为一个此前无人度量的响应窗口。

这条根源解释的完整性在于：每一项发现都能回溯到一个具体设计决定对信息流的改变——协议保真让摩擦可见、独立取证让归因可靠、条件消融让瓶颈分离。不是凑巧测到了，而是测量结构决定了只有这套设计能看到这些。

七、必要知识反推

假设让一个完全没接触过这个交叉领域的人重做这项工作，他最少必须掌握什么？

7.1 领域知识层（工控与控制理论）

• PLC 运行机制：扫描循环、IEC 61131-3 程序、运行时数据面与工程面的区分——不理解"写一个寄存器 ≠ 改控制程序”，就无法定义 post-foothold 威胁模型的作用面（论文明确只评估运行时数据面）。
• 闭环控制动力学：PID 反馈、开关控制、MIMO 耦合、保护/恢复逻辑——这是设计四个难度阶梯工况的前提。S3 的"高位恢复不动加热器”、S4 的"全局锁定只看 95%“这些保护缺口分析，需要能读懂控制逻辑与安全谓词之间的缝隙。
• 工业协议生态：S7comm/Modbus/TCP/ADS/MC-SLMP 的寻址模型与会话要求——选型决定了接口摩擦的梯度设计（Modbus 最平、MC-SLMP over UDP 最陡）。
• ICS 攻击史：Stuxnet/Triton 的目标特定知识门槛——这是"post-foothold 知识可在线重构"这个论点的历史参照系。

7.2 方法论知识层（agent 与评估）

• ReAct 范式及其局限：知道回合级循环在哪，才能识别长时程交互的三个新需求（多步建接口、延迟后果、上下文爆炸）并逐一设计对策。
• 基准测量学：条件概率分解、交叉实验设计（PLC × 工况交叉使两个难度维度统计分离）、置信区间（按格聚类的 bootstrap）、覆盖率 vs 重复性的区分——没有这些，240 个回合只是 240 个布尔值。
• 评测有效性威胁：熟悉"测试台故障被算成 agent 失败"“上回合状态泄漏到下回合"“agent 自述污染评分"这些经典效度威胁，才会设计出准入工作流、验证复位与独立取证。这一条与同期 ctf-abacus（flag 溯源审计）等工作的共识是：agent 评估的可信度取决于证据链，不取决于分数。

7.3 工程知识层（系统实现）

• HIL 桥接：把仿真传感值写进映射的原生对象、读回执行器输出、推进过程模型的实时循环——这是"真控制器 + 仿工厂"的粘合剂。
• 多厂商工程工具链：西门子/施耐德/倍福/三菱各自的组态、编译、下载、对象绑定——四台 PLC 的部署准入全是厂商特定操作。
• 取证基础设施：四源证据的同步采集（时间与步数对齐）、确定性重放、上下文压缩的哈希存证。
• 并行测量调度：每 PLC 车道复位锁与串行化、跨 PLC 并行——240 回合 118 小时的实际执行管理。

7.4 知识融合的关键节点

• 节点一：控制工程的"驻留时间"概念 × 基准的"flag"概念 = disrupt/impact 的分层。持续 5 秒与持续 30 秒不是同一个成就——这个设计需要同时理解过程安全谓词与能力阶梯度量，任何单一背景的研究者都想不到把 τ_d < τ_i 写成两个 flag。
• 节点二：协议逆向的摩擦体验 × agent 评估的公平性要求 = “不提供目标特定客户端配置"的纪律。帮 agent 配好客户端会让接口瓶颈消失；完全不公开库又不现实。中间线（给库、给通用兼容性提示、不给配置）来自对两侧的同时理解。
• 节点三：伦理披露的 dual-use 意识 × 开放科学要求 = 发布边界设计。可复现（框架、评估器、SoftPLC 管线、聚合记录）与不可复用（凭据、端点、可重放攻击序列、完整目标特定轨迹）的切分，本身是一个测量学决策——它决定了哪些科学主张可以被审计。

八、论文中可以提取的通用性灵感

8.1 用能力阶梯替代二值终点，把"失败"变成可行动的信息

核心思想：当一个长链任务的终点受多段异质能力制约时，把链切成可独立验证的里程碑，失败位置本身成为一级测量对象。

论文证据：98 个接口停步 vs 62 个物理转化停步的性质区分，直接导出四条不同的防御建议（收窄工程服务 vs 检查过程相关写 vs 守护危险区域 vs 遥测与写权限分离）；二值的 31.3% 不可能给出任何一条。

推广场景：(1) 自动驾驶安全评估——把"事故"拆成感知—规划—控制各段失败；(2) 医疗诊断 agent——拆分检查开具、结果解读、方案生成；(3) 多步数学证明——拆分引理发现、组合、验证；(4) DevOps 自动化——拆分定位、修复、回归验证。

8.2 证据链与主张分离：永远不要用 agent 的自述给它打分

核心思想：交互式 agent 的自由文本输出不可作为其能力的评分依据；评分证据必须在 agent 路径之外独立采集，且判定规则固定可重放。

论文证据：四源取证（runner 日志/抓包/对象绑定/过程轨迹）+ 无 LLM 裁判 + 同存档同结果；与同期 CTF 溯源研究（62–87% 真实利用率）互相印证"会说≠会做"是普遍现象。

推广场景：(1) 代码 agent 评估——用测试执行与提交记录而非 agent 的"我修好了”；(2) 研究 agent 评估——用实验复现而非文献综述的自洽性；(3) 客服 agent——用环境最终状态而非对话满意度自评；(4) 任何带工具调用的多轮评估。

8.3 可行性与能力解耦：先证明题目有解，再测解题者

核心思想：测量任何能力前，先用独立的准入流程证明任务本身可行且稳定，否则"失败"无法归因于被测对象。

论文证据：零动作稳定性基线（3600s 无干预不得自然漂进危险区）+ 隐瞒参考脚本（用已知绑定走通完整 impact 谓词）——P3/P4 上 agent 的大量失败因此不可能被推给"测试台不行”。

推广场景：(1) benchmark 构建的标准动作——每个任务先跑 solver 验证可解性；(2)机器人技能评估——先验证硬件标定无故障；(3) prompt 评测——先排除格式解析失败；(4) 临床试验——安慰剂组就是零动作基线的类比。

8.4 摩擦不是边界：安全设计不应依赖"不好用"来兜底

核心思想：因复杂性、文档缺失、配置困难产生的接口摩擦能延缓自动化攻击，但随着模型能力增强会被在线重构消解——只有作用于转化环节本身的控制才相对耐久。

论文证据：原生接口下 57.1% 的 manipulate 达成率在共享 Modbus 路径上升至 100%；GPT 5.5 一家覆盖全部 16 格；结论原文——“应在网—物转化本身上设防：限制工程服务可达性与过程相关写入、约束危险运行区域、避免丰富遥测与控制权限的不必要耦合”。

推广场景：(1) API 安全——混淆与限速是摩擦，权限最小化是边界；(2) 供应链安全——构建系统复杂度是摩擦，签名验证是边界；(3) 反爬虫——JS 挑战是摩擦，业务逻辑风控是边界；(4) 密码学——长密钥难猜不是安全边界，算法强度才是。

8.5 信息与权限的耦合审计：可见性本身是能力放大器

核心思想：对同一主体同时授予细粒度可观测性与状态变更权限时，可观测性会不成比例地放大变更的效果——权限设计应把两者分开授予。

论文证据：丰富观测使条件 impact 从 44.2% 升到 64.0%（+19.8pp）而不动任何早期 flag；防御建议原文——“详细遥测应对合法操作员可用，但不应自动附带写权限”。

推广场景：(1) 数据库权限——只读分析账号与写入账号分离；(2) 云监控——完整 metrics 暴露给只读角色；(3) 生产可观测性——trace/日志的精细度分级授权；(4) 金融系统——行情数据订阅与交易权限解耦。

8.6 测量型基准作为防御研究的先行基础设施

核心思想：在一个威胁尚在成形的能力领域，先建立可重复、可归因、伦理有边界的测量框架，比提出单个防御更有杠杆——它让后续所有防御工作有了比较的地面。

论文证据：论文自定位为不提出防御、不评防御，但六 flag 的停步位置直接标出了四个防御干预点；40/115 的"扰动未达目标"回合标识出一个从未被度量过的响应窗口（“未测量响应窗口"被明确列为未来工作）。

推广场景：(1) AI 对齐——能力评估基准先于对齐技术迭代；(2) 生物安全——筛选功能先于缓解措施；(3) 自动化渗透工具的军备竞赛测量；(4) 任何"能力跑在防御前面"的新技术领域。

附录：数字速查