工业软件不是网页表单

很多人谈 Computer Use Agent，会默认想到一个画面：

模型看一张截图，识别按钮、菜单、输入框，然后移动鼠标、点击、输入、等待界面变化。

这套方式对一些通用桌面任务有用。比如打开网页、填写表单、下载文件、整理邮件。因为这些任务的目标通常比较粗：点到正确按钮、填入正确文本、页面进入下一步。

但工业软件不一样。

你让 Agent 操作 CAD、PLC IDE、SCADA 配置工具、运动控制软件、机器人离线编程软件，它面对的不是几个按钮，而是：

• 高密度界面；
• 多层工程树；
• 大量属性面板；
• 专业术语；
• 跨对象引用；
• 编译诊断；
• 仿真结果；
• 设备配置；
• 安全边界；
• 版本和库依赖。

更麻烦的是，工业软件里很多错误不会在第一步暴露。

Agent 点错一个菜单、选错一个对象、漏掉一个参数，界面可能还在继续往下走；直到几十步以后，生成的工程对象才开始变形、编译失败、仿真不对，或者更危险：编译通过但逻辑不符合现场设备行为。

所以我读 ComAct 这篇论文时，最有共鸣的不是 CAD 本身，而是它把一个问题讲清楚了：

专业软件 Agent 的关键，不是让模型更会看界面，而是给它一个更可靠的动作接口。

一句话讲清 ComAct

ComAct 的核心思想可以概括成一句话：

把专业软件操作从“连续 GUI 控制”改写成“可执行程序合成”，让 Agent 通过 COM 接口直接操作软件内部对象，再用真实环境反馈做自我修正。

这句话里有三个重点。

第一，操作对象变了。

传统 GUI Agent 的动作是鼠标、键盘、坐标、按钮。ComAct 的动作是 COM 脚本，也就是一段可以直接调用专业软件对象模型的程序。

第二，任务粒度变了。

GUI Agent 可能要执行上百次点击和输入；ComAct 希望 Agent 生成一段脚本，让软件一次性完成一组结构化操作。

第三，反馈方式变了。

Agent 不只是生成代码就结束，而是在真实软件环境里执行脚本，读取终端输出、截图和最终工程产物，再进入下一轮修正。

这也是我觉得它对工业 Agent 很有启发的地方。

工业 Agent 的落地难点，往往不在“模型会不会写一段代码”，而在“它写出的动作能不能被工程环境执行、验证和纠错”。

论文先批评了两种常见路线

ComAct 的问题意识很清晰：现有 Computer Use Agent 主要有两条路线，但放到专业软件里都不够稳。

1. GUI-as-Action：通用，但长链路很脆

GUI Agent 的好处是通用。

只要软件能显示在屏幕上，理论上模型就可以看截图、识别控件、模拟人的点击。

但问题也在这里。

专业软件的界面通常非常拥挤。CAD 里有视图、树、草图、约束、尺寸、属性面板；PLC IDE 里有设备树、任务配置、POU、变量声明、库管理、诊断窗口、在线监控。截图里每个区域都可能有信息，但模型必须判断哪些信息和当前任务有关。

GUI Agent 在这种场景下容易遇到三个问题：

问题	在专业软件里的表现
视觉定位不稳	图标小、菜单深、面板密，容易点错对象
长链路误差累计	前一步点错，后面所有观察都建立在错误状态上
难以表达结构化意图	“创建一个带约束的工程对象”被拆成大量低级点击

这不是说 GUI Agent 没价值。

GUI 仍然适合做粗粒度观察、人工确认和最后验收。但如果让它承担主要动作空间，工业任务越长，失败概率越高。

2. API/MCP-as-Action：结构化，但接口经常碎

第二条路线是 API 或 MCP 工具调用。

这比 GUI 点击更工程化。Agent 可以调用明确的工具，比如创建文件、读取项目、运行编译、查询变量、生成报告。输入输出也更结构化。

但 ComAct 指出，专业软件里 API 路线也有一个现实问题：接口不统一。

不同软件暴露不同 API；有的软件只有局部自动化接口；有的软件接口文档不完整；商业软件往往不会把所有内部能力都用一个现代 REST API 暴露出来。最后 Agent 很容易面对一堆碎片化工具。

这也是工业软件的常态。

我们很少面对一个“为 Agent 设计过”的干净系统。更多时候，真实工程软件已经存在多年：有插件接口，有脚本接口，有命令行，有 SDK，有导入导出，有日志，有编译器，有测试工具，但它们并不是为 LLM Agent 统一设计的。

所以真正的问题不是“有没有 API”，而是：

能不能把专业软件里真正可执行的能力，整理成 Agent 能稳定使用的动作空间。

ComAct 的关键：COM-as-Action

ComAct 选择了 COM。

COM 是 Microsoft Windows 生态里的组件对象模型。按照微软文档，它是一套让二进制软件组件互相通信的对象系统。很多 Windows 专业软件会通过 COM 暴露对象、属性和方法。

论文的判断是：对 Windows 上的专业软件来说，COM 不是一个普通 API，而是一种接近软件内部对象层的语义接口。

这就很关键。

GUI 看到的是界面表象。

COM 访问的是软件对象。

比如在 CAD 软件里，Agent 不需要点菜单、找按钮、拖拽尺寸，而可以生成类似这样的脚本思路：

app = Dispatch("SomeCAD.Application")
doc = app.ActiveDocument
sketch = doc.CreateSketch()
sketch.AddLine(...)
sketch.AddConstraint(...)
doc.SaveAs(...)

这段代码只是示意，但它说明了动作粒度的变化。

Agent 不再说“把鼠标移到左上角第三个按钮”，而是在生成“创建对象、设置参数、保存产物”的程序。

论文把这个范式叫做 COM-as-Action。

我更愿意把它翻译成：

把专业软件的动作空间，从像素和控件，提升到对象和程序。

这个提升对工业 Agent 非常重要。

因为工业任务天然就不是 UI 任务，而是工程对象任务。

CAD 的目标不是点完界面，而是生成正确的几何模型。PLC 的目标不是填完代码框，而是生成能编译、能仿真、符合控制逻辑的工程。HMI 的目标不是拖完控件，而是生成正确绑定变量、报警、权限、趋势图的画面。

所以 Agent 应该尽量操作工程对象，而不是操作界面表象。

ComActor：从静态代码生成到自修复 Agent

ComAct 不是只提出一个接口想法，它还设计了一个 Agent：ComActor。

论文里 ComActor 的工作方式大致是：

自然语言任务
  -> 生成 COM 脚本
  -> 在真实 CAD 软件环境中执行
  -> 获取终端输出、截图、产物反馈
  -> 判断是否继续修正
  -> 直到完成或终止

这很像一个工业版 coding agent。

普通 coding agent 写 Python、Java、前端代码，然后跑测试、看报错、改代码。ComActor 写的是操作 CAD 软件的 COM 脚本，然后在真实 CAD 环境里执行，看最终工程产物是否符合要求。

论文把训练分成三步，也很有意思。

第一阶段：Instruction-to-Code

第一阶段是让模型先学会从自然语言生成正确的 COM 脚本。

这个阶段解决的是基础能力问题：模型知道有哪些 COM API，知道大概怎么调用，能写出语法和语义上比较靠谱的脚本。

但这还不是 Agent。

因为它只是一次性生成代码。代码失败了，它自己不会恢复。

这对应到工业 Agent 里，就是“帮我生成一段 ST 代码”或“帮我生成一个配置脚本”。这当然有用，但离真正的工程助手还差一层。

第二阶段：Agentic Refinement

第二阶段开始引入多轮反馈。

模型生成脚本后，会在环境里执行。如果失败，就根据错误、截图、输出继续修正。

这个阶段解决的是执行失败恢复问题。

对工业 Agent 来说，这一层非常关键。

因为工业开发里，很多错误不是靠模型预判就能完全避免的。比如：

• 库版本不匹配；
• POU 名称冲突；
• 变量作用域不对；
• 数据类型不兼容；
• 设备树配置缺失；
• 编译器给出特定诊断；
• 仿真环境缺少某个连接；
• 生成的代码符合语法但不符合项目约定。

一个靠谱的工业 Agent，不能只会“写第一版”，还要会读工程环境反馈。

第三阶段：Task-Level Optimization

第三阶段更重要。

论文指出，代码能执行不等于任务成功。CAD 脚本没有报错，生成的几何体也可能和目标不一致。

所以他们引入任务级奖励，用几何产物和目标之间的差异来优化 Agent。

这点对工业 Agent 的启发很大。

在 PLC/CODESYS 这类场景里，也有类似问题：

ST 代码能编译 != 控制逻辑正确
变量声明齐全 != 现场行为安全
工程能下载 != 设备运行符合工艺要求
仿真通过一条路径 != 边界条件都正确

所以工业 Agent 不能只把“编译通过”当作最终目标。

编译通过只是底线。真正的任务成功，要看工艺逻辑、状态机、报警条件、安全互锁、时序边界、异常恢复、测试用例和现场约束。

ComForge：为什么真实环境很重要

ComAct 还构建了 ComForge，用大量真实 Windows 环境并行执行 CAD 软件，用于训练和评测。

这个设计背后的判断很直接：

专业软件 Agent 不能只在静态数据集里训练和评测，它必须进入真实软件环境。

这点对工业 Agent 同样成立。

如果我们只是拿一堆 ST 代码片段做训练，模型可能会学会语法和常见模式。但它不一定知道：

• CODESYS 项目结构怎么组织；
• POU、GVL、DUT、Task、Device Tree 之间如何关联；
• 编译错误从哪里读；
• 库依赖怎么影响符号解析；
• 在线监控和离线编译有什么差异；
• 修改一个功能块会影响哪些调用方；
• 哪些操作只能在离线工程里做；
• 哪些操作必须经过人工审查。

工业 Agent 的能力，不应该只在“代码文本”上评估，而应该在“工程环境”里评估。

这也是 ComAct 最值得借鉴的地方：它评估的是最终软件产物，而不是只评估生成文本。

对工业 Agent 的第一个启发：动作接口比模型提示词更重要

过去我们很容易把 Agent 做不好归因于 Prompt。

Prompt 不够细，约束不够强，样例不够多，角色设定不够准确。

这些当然有影响，但 ComAct 给我的提醒是：在专业软件里，动作接口比 Prompt 更重要。

如果 Agent 的动作只有鼠标点击和键盘输入，再好的 Prompt 也要面对视觉定位、状态漂移、长链路误差。

如果 Agent 的动作只有一堆碎片化工具，再好的 Prompt 也要在工具之间猜意图、补语义、处理不一致的返回。

工业 Agent 真正需要的是一层工程动作接口。

这层接口应该尽量满足几个条件：

要求	含义
结构化	输入输出不是自然语言糊成一团
可执行	Agent 的动作能真实改变工程环境
可回放	每一步能记录、重放、审计
可验证	动作之后能拿到编译、仿真、测试或产物反馈
可限权	不同风险动作有不同权限和人工门禁

对 CODESYS 来说，这层动作接口可能不是 COM。

更现实的候选包括：

• CODESYS MCP Server；
• CODESYS Scripting API；
• IronPython 脚本；
• Automation Platform SDK；
• 命令行构建和测试能力；
• Test Manager；
• Git/SVN 项目接口；
• 编译诊断和消息窗口输出。

这些东西组合起来，才是 PLC 编程 Agent 的“动作空间”。

对工业 Agent 的第二个启发：不要先做会聊天的助手，先做会闭环的助手

很多 AI 工具容易从聊天入口开始。

用户问一句，模型答一句；用户贴一段代码，模型改一段代码。这是最低成本的产品形态。

但工业 Agent 如果停在这里，价值会很有限。

因为工业开发者真正需要的不是“给我一段看起来像 ST 的代码”，而是：

读当前工程
  -> 理解已有 POU 和变量
  -> 生成修改
  -> 写入离线工程
  -> 编译
  -> 读取诊断
  -> 修复
  -> 生成变更说明
  -> 等待人工确认

这个闭环比聊天更重要。

如果没有闭环，Agent 写得再流畅，也只是代码建议器。

有了闭环，它才开始接近工程助手。

这和 ComActor 的思路是一致的：先生成动作，再在环境里执行，再根据环境反馈纠错。

工业 Agent 的核心能力，不应该被定义成“回答问题”，而应该被定义成“推进工程状态，并证明自己没有把工程状态改坏”。

对工业 Agent 的第三个启发：编译通过不是任务完成

ComAct 论文里有一个很关键的观察：模型生成的代码可能能执行，但最终几何产物仍然不符合任务要求。

这个差距在工业软件里会更明显。

拿 PLC 来说，编译通过只是说明语法、类型、引用大体没问题。它不能证明：

• 状态机转移正确；
• 急停逻辑正确；
• 报警复位条件正确；
• 互锁条件覆盖完整；
• 定时器边界符合工艺；
• 断电恢复逻辑正确；
• 多任务周期下没有竞态；
• HMI 显示和实际变量绑定一致；
• 现场设备异常时不会进入危险状态。

所以工业 Agent 的验证层至少要分几级。

层级	验证内容	对应反馈
语法层	ST/LD/FBD 代码是否可解析	编译诊断
工程层	POU、变量、库、任务配置是否一致	项目构建结果
行为层	状态机和控制逻辑是否符合用例	单元测试、仿真、Test Manager
安全层	是否触碰高风险设备动作	规则、权限、人工审查
产物层	工程变更是否满足原始需求	评审记录、测试报告

如果只做到第一层，这个 Agent 很容易给人一种“能跑”的错觉。

但工业场景里，真正要防的是“能跑但不对”。

对工业 Agent 的第四个启发：工业软件需要自己的 Agent Benchmark

ComAct 做了 ComCADBench，用真实 CAD 软件和最终工程产物来评估 Agent。

这件事对工业 Agent 很重要。

如果我们要做 PLC/CODESYS Agent，也不应该只拿通用代码 benchmark 来评估。

SWE-bench 能测修 GitHub issue 的能力，HumanEval 能测函数级代码生成，但它们不能回答这些问题：

• Agent 能不能正确创建一个 CODESYS POU？
• 能不能根据工艺描述生成状态机？
• 能不能把一个功能块拆成接口、实现和测试？
• 能不能根据编译错误定位变量作用域问题？
• 能不能避免直接修改在线控制器？
• 能不能输出一份给电气工程师审查的变更说明？
• 能不能在已有工程约束下做最小改动？

所以工业 Agent 需要领域 benchmark。

一个最小的 PLC Agent benchmark 可以从这些任务开始：

任务类型	示例
代码生成	根据文字生成一个电机启停 FB
错误修复	给一段编译失败的 ST，修复类型和作用域错误
工程修改	在已有工程中新增 POU 并接入任务
状态机建模	根据工艺步骤生成状态机和异常分支
测试生成	为功能块生成测试用例和边界输入
诊断解释	把编译诊断解释成人能理解的修改建议
安全审查	标出可能影响设备动作的高风险修改

这类 benchmark 的评价对象不应该只是最终文本，而应该包括：

• 工程是否能编译；
• 诊断是否清零；
• 测试是否通过；
• 修改范围是否最小；
• 是否触碰禁止动作；
• 是否生成可审查说明。

这才符合工业 Agent 的真实价值。

映射到 CODESYS：一个最小 Agent 架构应该长什么样

如果把 ComAct 的思想迁移到 CODESYS，我不会一上来设计复杂多 Agent 系统。

我会先做一个单 Agent 的闭环架构。

用户需求
  -> 任务理解
  -> 读取工程上下文
  -> 选择动作
  -> 生成 ST/POU/脚本修改
  -> 写入离线工程副本
  -> 编译/测试
  -> 读取 diagnostics
  -> 自修复
  -> 输出 diff 和审查说明

这里最关键的是动作集合。

一个 CODESYS Agent 至少需要这些工具：

工具	作用
read_project_tree	读取设备树、Application、POU、GVL、库依赖
read_pou	读取指定 POU 的声明区和实现区
write_pou_patch	对离线工程副本做结构化修改
create_pou	创建 FB、FC、PRG、DUT 等工程对象
run_build	触发编译或构建
read_diagnostics	读取编译错误、警告、位置
run_tests	调用 Test Manager 或仿真测试
generate_review_report	输出变更范围、风险点、测试结果

这套工具本质上就是 CODESYS 里的 ComAct。

它不一定使用 COM，但思想一样：

不让 Agent 主要靠看界面点按钮，而是让它通过工程接口生成可执行动作。

再往下，才考虑多 Agent。

比如一个 Agent 负责生成代码，一个负责读诊断，一个负责审查安全规则，一个负责生成测试。但这些都应该建立在稳定动作空间之上。

如果动作空间不稳，多 Agent 只会放大混乱。

工业 Agent 必须有更硬的安全边界

工业 Agent 和普通 Code Agent 最大的不同，是副作用。

普通软件项目里，Agent 改坏代码，通常可以 git revert，可以跑 CI，可以重新部署。

工业控制里，错误动作可能影响设备、产线、人员安全。

所以我认为工业 Agent 的默认权限应该非常保守。

第一阶段只允许离线工程操作。

Agent 可以读项目、生成代码、写入工程副本、编译、运行离线测试，但不能直接下载到 PLC，不能修改在线设备，不能绕过人工确认。

第二阶段才允许受控联调。

比如只连接仿真环境，只能访问测试 PLC，只能读变量不能写变量，写操作需要人工批准。

第三阶段才考虑现场辅助。

即使到了现场，也应该把 Agent 定义成“建议和审查助手”，而不是默认自动执行器。

一个工业 Agent 的权限矩阵至少应该像这样：

动作	默认权限	原因
读取离线工程	允许	低风险
生成代码建议	允许	不直接改变设备
修改工程副本	允许	可回滚
编译工程	允许	无现场副作用
运行离线测试	允许	可控环境
下载到仿真 PLC	人工确认	有执行副作用
修改在线变量	默认禁止	可能影响设备
下载到真实控制器	默认禁止	高风险
修改安全相关逻辑	强制人工审查	安全边界

这也是 ComAct 没有直接解决、但工业 Agent 必须面对的问题。

COM-as-Action 提高了执行可靠性，但也提高了动作能力。动作能力越强，权限边界越要清楚。

这篇论文给我的最终判断

ComAct 对我的最大启发，不是“COM 很适合 CAD”，而是它把专业软件 Agent 的发展方向讲得很清楚：

从看界面，到调用对象；从点按钮，到生成程序；从回答问题，到执行、验证和自修复。

这对工业 Agent 尤其重要。

因为工业软件的核心不是界面，而是工程对象、约束、配置、编译器、仿真器和最终产物。

所以我会把工业 Agent 分成三代。

第一代：聊天式助手

能解释代码、回答概念、生成片段。

它对学习和查资料有用，但不真正进入工程环境。

第二代：代码建议器

能根据上下文补全 ST、生成 POU、解释诊断。

它开始接近开发流程，但仍然容易停留在文本层。

第三代：工程动作 Agent

能读取工程、执行修改、编译、测试、读反馈、修复、输出审查报告。

这才是我认为工业 Agent 真正有价值的形态。

ComAct 其实就在证明第三代路线：不要满足于让模型“像人一样操作软件”，而是重构软件和 Agent 之间的动作接口，让模型用程序化方式操控专业环境。

总结

如果只看标题，ComAct 像是一篇 CAD Agent 论文。

但我觉得它更大的价值，是给工业 Agent 提供了一个非常清晰的架构判断：

工业 Agent 的关键不是更像人，而是更像工程系统。

人类工程师可以看界面、点按钮、凭经验修正错误，是因为人有长期经验和现场责任。

Agent 不应该照搬人的低级动作。

更好的路线是：让专业软件暴露出结构化动作接口，让 Agent 生成可执行动作，在真实工程环境里执行，用编译、仿真、诊断、产物和人工审查形成闭环。

对 PLC、CODESYS、CAD、HMI、机器人离线编程这些场景来说，这可能比“再训练一个更懂工业知识的模型”更重要。

模型能力会继续提升。

但工业 Agent 能不能落地，最终要看它有没有一个可靠的动作空间。

参考资料

• ComAct: Reframing Professional Software Manipulation via COM-as-Action Paradigm：https://arxiv.org/html/2606.13239v1
• Microsoft Learn: Component Object Model (COM)：https://learn.microsoft.com/en-us/windows/win32/com/component-object-model–com–portal
• CODESYS AI-supported Engineering：https://www.codesys.com/products/engineering/ai-supported-engineering/
• CODESYS Scripting：https://content.helpme-codesys.com/en/CODESYS%20Scripting/_script_scripting_with_codesys.html
• CODESYS Structured Text (ST), Extended Structured Text：https://content.helpme-codesys.com/en/CODESYS%20Development%20System/_cds_f_programming_language_st.html
• Model Context Protocol documentation：https://modelcontextprotocol.io/docs/getting-started/intro