OpenClaw技能驱动架构：53个生产级技能深度解析与工业自动化实践

1. OpenClaw 是什么：不是“另一个 Agent 框架”，而是技能驱动的智能体操作系统

很多人第一次看到 OpenClaw，下意识会把它归类为“又一个 LLM Agent 框架”——类似 LangChain、LlamaIndex 那种偏重编排和链路的工具。但这是个根本性误解。OpenClaw 的设计哲学从第一天起就彻底反向：它不假设你有一个“大脑”需要调度，而是先定义清楚“手能做什么”，再让“手”自己长出协调逻辑。换句话说，OpenClaw 的核心不是 workflow（工作流），而是 skill（技能）。

这直接决定了它的架构分层：最底层是Skill Runtime，一个轻量、隔离、可热加载的执行沙箱；中间层是Skill Registry，负责元信息注册、版本管理、依赖解析与权限控制；顶层才是Orchestrator，但它不写死逻辑，而是通过 YAML 或 JSON Schema 声明式地描述“在什么条件下，调用哪些技能，按什么顺序，传什么参数”。这种“技能先行”的范式，让 OpenClaw 在实际落地中展现出极强的工程友好性——业务方可以只关心“我要实现什么功能”，技术方则专注把每个功能封装成标准 Skill，双方在 Skill Interface 上对齐，而不是在抽象的“Agent 行为树”里反复扯皮。

我去年在给一家制造业客户做设备远程诊断系统时，就深刻体会到这个差异。他们原有方案用的是自研 Agent 框架，每次新增一个传感器数据读取能力，都要改 Orchestrator 的 Python 代码、重新部署服务、测试整个链路。而换成 OpenClaw 后，我们只用写一个read_modbus_register.py技能文件，填好input_schema（IP、端口、寄存器地址）、output_schema（float 值、单位、时间戳）、requires（pymodbus==3.6.0），扔进skills/目录，OpenClaw 自动扫描、校验、加载。运维同学甚至不需要重启服务，只要发一个POST /api/v1/skills/reload请求，新技能立刻上线。这种“功能即插即用”的体验，是传统 Agent 框架很难做到的。

这也解释了为什么标题里强调“官方 53 个 Skills”——这不是一个凑数的数字，而是 OpenClaw 团队用真实工业场景反复打磨出的最小可行技能集。这 53 个技能覆盖了网络通信（HTTP、MQTT、Modbus TCP）、文件操作（SFTP、本地读写、ZIP 解压）、数据处理（JSON/YAML 解析、CSV 转换、正则提取）、系统交互（Shell 执行、进程监控、环境变量读取）、基础计算（日期运算、数值四则、单位换算）等六大类刚需。它们不是玩具 Demo，每一个都内置了超时控制、错误重试、日志埋点、输入校验等生产级特性。比如http_request技能，它默认支持 3 次指数退避重试，超时阈值可配置，响应体自动按Content-Type解析为 dict/list/str，失败时返回结构化错误码（如HTTP_404_NOT_FOUND,CONNECTION_TIMEOUT），而不是抛一个原始requests.exceptions.ConnectionError异常。这种开箱即用的健壮性，正是它能在制造业、能源、IoT 等对稳定性要求极高的领域快速铺开的关键。

提示：不要试图用 OpenClaw 去“模拟人类对话流程”。它不适合做客服话术生成或闲聊机器人。它的强项是“把确定性任务自动化”，比如“每天早上 8 点从 ERP 系统拉取昨日订单数据，清洗后发邮件给销售总监，并同步更新看板”。如果你的需求里有大量模糊判断、多轮上下文推理、情感理解，那应该选别的工具。OpenClaw 的价值，在于把那些“人干得烦、脚本写得累、RPA 跑得慢”的重复性操作，变成一行 YAML 就能调用的标准能力。

2. 官方 53 个 Skills 深度拆解：不只是列表，而是能力图谱与使用边界

网上很多教程只贴一张 53 个技能的名称列表，然后说“大家自己去看文档”。这完全没抓住重点。真正决定你项目成败的，不是“有哪些技能”，而是“每个技能能干什么、不能干什么、在什么场景下必须慎用”。我把这 53 个官方技能按能力内核重新聚类，并标注了每个类别的核心限制与实操陷阱。

2.1 网络通信类（12 个）：HTTP/MQTT/Modbus 的三重门

这一类是使用频率最高的，但也是最容易踩坑的。官方提供了http_request、mqtt_publish、mqtt_subscribe、modbus_read_holding_registers等 12 个技能，覆盖了工业现场最主流的协议。

• HTTP 类技能的核心限制：http_request默认禁用重定向（allow_redirects=False），且不自动处理 Cookie。这意味着如果你调用一个会 302 跳转的登录接口，它会直接返回 302 状态码，而不是帮你跳到最终页面。解决方案不是关掉校验，而是显式配置follow_redirects: true，并配合session_id参数传递上一步获取的 token。我见过太多人卡在这里，以为是接口问题，其实是技能默认行为。

• MQTT 类技能的隐式依赖：mqtt_publish和mqtt_subscribe必须共用同一个 MQTT Broker 连接实例。OpenClaw 不会在每次调用时新建连接，而是复用 Registry 中已建立的连接池。这就意味着，如果你在mqtt_subscribe的回调函数里，又触发了一个mqtt_publish，它们共享同一个连接，不会产生并发冲突。但反过来，如果你在两个完全独立的流程里，分别配置了不同broker_url的mqtt_publish，OpenClaw 会为它们创建两个独立连接，消耗双倍资源。所以，务必在config.yaml里统一定义mqtt_broker全局配置，所有 MQTT 技能引用它。

• Modbus 类技能的字节序陷阱：modbus_read_input_registers返回的 raw bytes，默认是大端序（Big-Endian）。但很多国产 PLC（如汇川、信捷）的寄存器布局是小端序（Little-Endian）。如果你直接用struct.unpack('>f', raw_bytes)解析浮点数，结果会完全错误。官方文档没明说，但技能源码里有个隐藏参数byteorder: 'big' | 'little'，必须手动指定。这个细节，我在调试某条产线温控数据时，花了整整两天才定位到。

2.2 文件与存储类（9 个）：本地磁盘不是云存储

file_read_text、file_write_binary、sftp_download、zip_extract等 9 个技能，构成了 OpenClaw 的数据搬运中枢。但一个致命误区是：认为它们能无缝替代云存储 SDK。事实是，OpenClaw 的文件类技能，设计初衷就是操作本地文件系统或可信内网 SFTP 服务器。它没有内置 AWS S3、阿里云 OSS、MinIO 的适配器。

• SFTP 技能的密钥认证盲区：sftp_download支持密码和密钥两种认证。但密钥认证时，它只接受 PEM 格式私钥，且不支持密码保护的私钥。如果你的私钥是用ssh-keygen -p -P "oldpass" -N "newpass" -f id_rsa加密过的，sftp_download会静默失败，日志只显示Authentication failed。解决方案是提前用ssh-keygen -p -N "" -f id_rsa移除密码，或改用密码认证。

• ZIP 技能的路径穿越风险：zip_extract默认会将压缩包内的路径原样解压到目标目录。如果压缩包里包含../../../etc/passwd这样的恶意路径，它就会被解压到系统根目录。这是一个典型的路径遍历漏洞。官方技能已修复，但前提是你的 OpenClaw 版本 >= v0.8.3。低于此版本，必须在调用前用file_path_sanitize技能预处理压缩包内容，或在config.yaml中全局开启safe_extract: true（该参数在 v0.8.3+ 才生效）。

• 本地文件读写的编码陷阱：file_read_text默认用utf-8编码读取。但 Windows 记事本保存的.txt文件，很多是gbk或ansi编码。直接读会报UnicodeDecodeError。技能提供encoding参数，但很多人不知道encoding: auto这个隐藏选项——它会用chardet库自动探测编码。虽然慢一点，但在处理来源不明的文本文件时，这是最稳妥的选择。

2.3 数据处理类（15 个）：结构化是硬约束，不是可选项

json_parse、yaml_load、csv_to_dict、regex_extract、date_add_days等 15 个技能，是 OpenClaw 的“数据翻译官”。它们的共同特点是：输入必须是严格结构化的字符串，输出是明确类型的 Python 对象。这与通用脚本语言的宽容性截然不同。

• JSON/YAML 技能的容错性为零：json_parse遇到{"key": "value",}这种末尾多余逗号，或{"key": "val" "extra": "text"}这种缺少逗号，会直接抛JSONDecodeError，不会尝试修复。同理，yaml_load对缩进极其敏感，- item1\n- item2和- item1\n - item2是完全不同的结构。这意味着，如果你要解析第三方 API 返回的 JSON，必须先用string_replace技能清理掉不可见字符（如\u200b零宽空格），再用json_parse。我在线上环境加了一条强制规则：所有进入json_parse的输入，必须先过string_strip+string_replace(pattern: '\u200b', replacement: '')。

• 正则技能的捕获组命名是灵魂：regex_extract支持命名捕获组，如r'ID:(?P<id>\d+), Name:(?P<name>\w+)'。它的输出是一个 dict：{"id": "123", "name": "Alice"}。但如果你写成位置捕获组r'ID:(\d+), Name:(\w+)'，输出是 list：["123", "Alice"]。在后续流程中，用{{ .id }}引用比用{{ .0 }}安全得多。因为 list 索引一旦上游正则改动，整个流程就崩了；而命名捕获组只要名字不变，内部顺序怎么变都无所谓。

• 日期技能的时区是默认 UTC：date_now、date_add_days、date_format等所有日期技能，内部时间戳都是 UTC。date_format的format参数，如"%Y-%m-%d %H:%M:%S"，输出的是 UTC 时间。如果你需要北京时间（UTC+8），必须显式调用date_timezone_convert技能，传入from_tz: "UTC",to_tz: "Asia/Shanghai"。别指望在date_format里写%Z或%z就能搞定，它不识别时区名。

2.4 系统与进程类（7 个）：容器化部署下的权限迷宫

shell_exec、process_list、service_status、env_get等 7 个技能，让你能触及宿主机的“肌肉”。但在 Docker/K8s 环境下，它们的行为会因容器权限而剧烈变化。

• shell_exec的用户身份陷阱：OpenClaw 官方 Docker 镜像默认以nobody用户运行。这意味着，shell_exec执行ls /root会 Permission Denied，执行ps aux只能看到本用户的进程。解决方案有两个：一是在docker run时加--user root（不推荐，安全风险）；二是改用process_list技能，它通过/proc文件系统读取进程信息，不受用户权限限制，且返回结构化数据（PID、CMD、USER、CPU%），比ps aux的字符串解析可靠得多。

• service_status的 systemd 依赖：这个技能本质是执行systemctl is-active <service>。它要求容器内必须安装systemd，且 OpenClaw 进程必须有CAP_SYS_ADMIN权限。但绝大多数精简版 Linux 镜像（如alpine:latest）根本不带systemd。所以，如果你用的是 Alpine 镜像，service_status会直接报Command 'systemctl' not found。正确做法是：在Dockerfile里apk add --no-cache systemd，或改用process_list检查进程是否存在（name: "nginx"）。

• env_get的环境变量来源：它读取的是 OpenClaw 进程启动时的环境变量，不是.env文件，也不是 Kubernetes 的 ConfigMap。如果你想从 ConfigMap 注入，必须在kubectl apply -f时，用envFrom字段将 ConfigMap 挂载为环境变量，env_get才能读到。别指望它能自动扫描所有可能的配置源。

2.5 数学与计算类（5 个）：精度与范围的隐形墙

math_add、math_multiply、math_round、unit_convert、random_int这 5 个技能，看似简单，实则暗藏玄机。

• math_round的银行家舍入：它默认采用“四舍六入五成双”的银行家舍入法（Banker's Rounding），而非传统四舍五入。例如math_round(value: 2.5, digits: 0)返回2，math_round(value: 3.5, digits: 0)返回4。这在财务计算中是标准，但在工业控制中，工程师习惯“四舍五入”。技能提供rounding_mode: "half_up"参数，必须显式设置才能得到预期结果。

• unit_convert的单位库是封闭的：它只支持官方预置的 37 个单位对（如m↔cm,kg↔g,C↔F）。如果你要转换bar到psi，它会报Unsupported unit conversion。此时不能硬改源码，而应调用math_multiply，手动乘以换算系数14.5038。官方这么设计，是为了保证单位转换的绝对精确和可审计性，避免引入浮点误差。

• random_int的种子是固定的：为了保证流程可重现，random_int默认使用固定种子42。这意味着，同一份配置，在任何机器、任何时间运行，产生的随机数序列都一样。这在测试和调试时是优点，但在需要真随机的场景（如生成临时 Token），必须传入seed: "{{ date_now().timestamp() }}"动态种子。

2.6 其他杂项类（5 个）：小技能，大影响

string_replace、string_split、dict_merge、list_append、noop这 5 个技能，是流程的“胶水”。它们不起眼，但一旦用错，整个流程就断掉。

• string_replace的全局替换是默认行为：pattern: "a"会替换所有"a"，不是第一个。如果你只想替换第一次出现的，必须用count: 1参数。这个参数文档里有，但很多人忽略，导致字符串被过度清洗。

• dict_merge的递归合并是深拷贝：它会递归合并嵌套字典，且是深拷贝。dict_merge(a: {"x": {"y": 1}}, b: {"x": {"z": 2}})返回{"x": {"y": 1, "z": 2}}。但如果你传入a: {"x": [1, 2]},b: {"x": [3, 4]}，它不会合并数组，而是用b的数组覆盖a的数组。数组合并要用list_append。

• noop技能的真实用途：它不是“什么也不做”，而是“占位符”。当你想在流程中预留一个分支，但当前还不知道放什么技能，就用noop。它返回一个空 dict{}，不会中断流程。线上环境我常用它做“开关”：在if条件里，true分支放真实技能，false分支放noop，避免流程因分支缺失而报错。

3. ClawHub 技能市场：如何从“精品推荐”里淘到真金，避开营销陷阱

ClawHub 是 OpenClaw 的官方技能市场，类似 npm 或 PyPI，但更垂直。它上面有超过 2000 个社区贡献的技能，其中标有“Official Verified”（官方认证）徽章的约 120 个，标有“Community Popular”（社区热门）的约 300 个。标题里说的“精品推荐”，指的就是这 420 个左右的高质技能。但“精品”不等于“万能”，盲目安装只会给系统埋雷。

3.1 官方认证技能（120 个）：信任链的起点，不是免检金牌

“Official Verified” 徽章，代表该技能通过了 OpenClaw 团队的三重审核：1) 代码无硬编码密钥、无远程下载恶意 payload；2) 单元测试覆盖率 >= 80%，且包含边界 case（如空输入、超长输入、非法参数）；3) 文档完整，包含input_schema、output_schema、example_usage三要素。但这只是准入门槛，不保证它适合你的场景。

• 认证技能的版本兼容性黑洞：一个技能被认证时，是基于 OpenClaw v0.7.0。但你现在用的是 v0.9.2。v0.8.0 引入了新的skill_context机制，v0.9.0 修改了http_request的错误码结构。很多认证技能的requirements.txt里写着openclaw>=0.7.0，这在 v0.9.2 下可能运行异常。我的做法是：在clawhub install后，立刻运行clawhub verify <skill-name>，它会检查技能与当前 OpenClaw 版本的兼容性，并给出详细报告。报告显示compatibility: partial的技能，必须去它的 GitHub Issue 区，看有没有人提过兼容性问题，再决定是否启用。

• 认证技能的“企业版”陷阱：有些认证技能，如sap_rfc_connect（连接 SAP RFC），其免费版只支持单次连接，且不支持事务（BAPI）。真正的“RFC 调用”能力，被包装在sap_rfc_connect-pro付费插件里。ClawHub 页面上，免费版和 Pro 版是两个独立条目，但图标和描述几乎一样，只有价格栏写着 “Free” 和 “$299/year”。我亲眼见过客户采购团队，只看了图标就签了单，结果上线后发现关键 BAPI 调用全部失败。教训是：看到任何带 “Pro”、“Enterprise”、“Ultimate” 后缀的技能，必须点开 “Features Comparison” 表格，逐行核对。

3.2 社区热门技能（300 个）：流量不等于质量，要看“活检报告”

“Community Popular” 是按过去 30 天的下载量和 Star 数排序的。高流量技能往往解决的是“最大公约数”问题，比如wechat_work_notify（企业微信通知）、feishu_card_message（飞书卡片消息）、dingtalk_robot_send（钉钉机器人）。但流量背后，是大量未经验证的定制化需求。

• 热门技能的“地域魔改”现象：以wechat_work_notify为例，GitHub 上有 17 个 Fork。其中 12 个是中国开发者魔改的，增加了“消息模板 ID”、“审批流跳转链接”、“@all 功能”；3 个是东南亚开发者魔改的，支持泰语、越南语 emoji；2 个是欧洲开发者魔改的，符合 GDPR，自动脱敏手机号。ClawHub 上架的，是主仓库的“国际版”，它不包含任何中国特供功能。如果你直接clawhub install wechat_work_notify，发不出带模板的消息。正确路径是：找到那个 Star 最多的中国 Fork，git clone下来，用clawhub install --local ./path/to/fork本地安装。

• 热门技能的“依赖幻觉”：很多热门技能的requirements.txt里写着requests>=2.25.0, <3.0.0，看起来很规范。但它的setup.py里，又写了install_requires=['urllib3>=1.26.0']。而 urllib3 1.26.0 与 requests 2.28.0 有已知的 SSL 兼容性问题。这种“依赖幻觉”，导致技能在某些 Python 环境下静默失败。我的检测方法是：在clawhub install后，进入 OpenClaw 容器，执行pip check，它会列出所有冲突的依赖。有冲突，就必须用pip install --force-reinstall强制降级或升级。

3.3 我的“精品推荐”清单：经过 12 个生产环境验证的 15 个技能

基于过去一年在 12 个不同行业客户的落地经验，我筛选出以下 15 个真正经得起考验的 ClawHub 技能。它们不是流量明星，但每一个都在至少 3 个以上客户现场稳定运行超过 6 个月。

1. prometheus_pushgateway(v1.2.0)：不是推送指标到 Prometheus Server，而是推送到 Pushgateway。解决了边缘设备无法被 Prometheus 主动抓取的问题。关键优势：支持批量推送、自动添加 job/instance 标签、失败时重试 3 次。适用场景：工厂设备状态上报、车载终端 GPS 数据回传。

2. opcua_read_node(v0.4.1)：OPC UA 协议的节点读取技能。它不依赖python-opcua的完整 SDK，而是用轻量asyncua，内存占用 < 5MB。支持证书认证、匿名认证、用户名密码认证三种模式。适用场景：与西门子、罗克韦尔 PLC 通信。

3. influxdb_write(v2.3.0)：InfluxDB 2.x 的写入技能。它用 native line protocol，比 HTTP API 快 3 倍。支持 batch 写入（默认 1000 点/批），自动处理 timestamp。适用场景：高频传感器数据入库。

4. redis_pubsub(v1.0.5)：Redis 的 Pub/Sub 技能。它不是简单的publish，而是实现了“订阅-处理-确认”闭环。收到消息后，执行一个子流程，成功后才ack，失败则nack并重试。适用场景：微服务间异步事件通知。

5. pdf_fill_form(v0.7.2)：用pypdf填充 PDF 表单。支持 AcroForm 和 XFA 表单，自动识别字段名，支持中文。适用场景：自动生成合同、发票、报关单。

6. excel_read_sheet(v1.1.0)：读取 Excel 工作表。它不加载整个文件到内存，而是用openpyxl的read_only=True模式，10MB 的 Excel 文件，内存占用 < 20MB。适用场景：读取 ERP 导出的超大报表。

7. twilio_sms_send(v0.5.0)：Twilio 短信发送。它内置了号码格式化（自动加国家码）、发送失败原因解析（区分invalid-number、insufficient-balance）、重试策略。适用场景：全球短信通知。

8. aws_s3_upload(v0.9.1)：AWS S3 上传。它用boto3的upload_fileobj，支持 multipart upload，自动分片。适用场景：大文件备份到 S3。

9. azure_blob_download(v0.3.0)：Azure Blob 下载。它支持 SAS Token 认证，且 Token 过期前 5 分钟自动刷新。适用场景：从 Azure 存储拉取模型权重。

10. google_sheets_read(v0.6.0)：Google Sheets 读取。它用 Service Account 认证，支持range参数（如A1:C10），返回二维 list。适用场景：读取在线协作表格。

11. notion_database_query(v0.4.2)：Notion Database 查询。它支持 filter、sort、page_size 参数，返回结构化数据。适用场景：从 Notion 知识库同步数据。

12. jira_issue_create(v0.8.0)：Jira Issue 创建。它支持自定义字段映射，自动处理projectKey、issueType的 ID 转换。适用场景：自动化 Bug 提交。

13. confluence_page_update(v0.2.1)：Confluence 页面更新。它用update_or_create模式，根据title和spaceKey判断是更新还是新建。适用场景：自动更新项目 Wiki。

14. slack_message_post(v0.7.3)：Slack 消息发送。它支持 Block Kit 格式，可发送富文本、按钮、选择器。适用场景：运维告警通知。

15. telegram_bot_send(v0.5.0)：Telegram Bot 发送。它支持 MarkdownV2 格式，自动转义特殊字符，防止注入。适用场景：个人通知、小团队沟通。

注意：以上所有技能，我都已打包成一个私有仓库https://github.com/your-org/openclaw-production-skills，并维护了compatibility_matrix.csv，明确标注了每个技能与 OpenClaw v0.8.x/v0.9.x 的兼容状态。你可以直接 fork 这个仓库，作为你们团队的技能基线。

4. 技能配置实战：从零开始构建一个“设备健康度日报”流程

理论讲完，现在来一个完整的、可直接复制粘贴的实战案例。我们将用 OpenClaw 官方技能 + ClawHub 精品技能，构建一个“设备健康度日报”流程：每天早上 8 点，自动从 OPC UA 服务器读取 10 台关键设备的温度、振动、电流数据，计算健康度得分（0-100），生成 PDF 报告，并通过企业微信发送给厂长。

4.1 环境准备与依赖安装

首先，确保你的 OpenClaw 环境是干净的。我推荐用 Docker Compose 部署，这样依赖隔离最彻底。

# 创建项目目录 mkdir -p device-health-report/{skills,flows,config} cd device-health-report

创建docker-compose.yml：

version: '3.8' services: openclaw: image: openclaw/openclaw:v0.9.2 ports: - "8080:8080" volumes: - ./skills:/app/skills - ./flows:/app/flows - ./config:/app/config - ./data:/app/data environment: - OPENCLAW_CONFIG_PATH=/app/config/config.yaml - PYTHONUNBUFFERED=1 restart: unless-stopped

创建config/config.yaml，这是整个系统的“心脏”：

# config/config.yaml # 全局配置 global: timezone: "Asia/Shanghai" log_level: "INFO" # 技能注册中心配置 skill_registry: # 启用本地技能目录扫描 local_dirs: - "/app/skills" # 启用 ClawHub 技能 clawhub_enabled: true # ClawHub 配置（可选，用于私有市场） # clawhub_url: "https://your-clawhub.internal" # clawhub_token: "your-token" # HTTP 服务器配置 server: host: "0.0.0.0" port: 8080 cors_enabled: true # 认证配置（生产环境必开） auth: enabled: true jwt_secret: "change-this-in-production" jwt_expires_in: "24h" # 外部服务配置（我们的设备数据源） external_services: opcua_server: endpoint: "opc.tcp://192.168.1.100:4840" security_policy: "Basic256Sha256" auth_type: "username_password" username: "admin" password: "password123" wechat_work: corp_id: "wwxxxxxxxxxxxxxxxx" agent_id: "10001" secret: "your-secret-here" # 企业微信应用的接收人 to_user: "ZhangSan|LiSi" to_party: "1"

现在，安装必需的技能。我们用官方技能处理基础逻辑，用 ClawHub 技能处理专业协议和通知：

# 进入容器安装 ClawHub 技能 docker exec -it device-health-report-openclaw-1 /bin/sh # 安装 OPC UA 技能（ClawHub 精品） clawhub install opcua_read_node # 安装企业微信通知技能（ClawHub 精品） clawhub install wechat_work_notify # 安装 PDF 生成技能（ClawHub 精品） clawhub install pdf_fill_form # 退出容器 exit

提示：clawhub install命令会自动下载技能到/app/skills/clawhub/目录，并更新skill_registry。你不需要手动复制文件。

4.2 构建核心技能：get_device_data与calculate_health_score

技能不是写在 Python 文件里，而是写在 YAML 文件里，放在skills/目录下。OpenClaw 的技能定义，是声明式的，不是命令式的。

创建skills/get_device_data.yaml：

# skills/get_device_data.yaml # 从 OPC UA 服务器批量读取设备数据 name: "get_device_data" description: "Read temperature, vibration, current from multiple devices via OPC UA" version: "1.0.0" author: "Your Name" license: "MIT" # 输入参数定义，OpenClaw 会自动校验 input_schema: type: "object" properties: device_list: type: "array" items: type: "object" properties: name: type: "string" description: "Device name, e.g., 'Boiler-01'" nodes: type: "array" items: type: "object" properties: node_id: type: "string" description: "OPC UA Node ID, e.g., 'ns=2;s=Temperature'" field_name: type: "string" description: "Field name in output, e.g., 'temperature'" description: "List of devices and their OPC UA nodes to read" # 输出参数定义 output_schema: type: "object" properties: data: type: "array" items: type: "object" properties: device_name: type: "string" timestamp: type: "string" format: "date-time" metrics: type: "object" additionalProperties: true # 技能执行逻辑：一个 YAML 描述的流程 steps: # 步骤1：初始化一个空的数据列表 - name: "init_data_list" skill: "noop" output: "data_list: []" # 步骤2：遍历 device_list - name: "iterate_devices" skill: "for_each" input: items: "{{ .device_list }}" body: # 步骤2.1：为当前设备读取所有节点 - name: "read_device_nodes" skill: "opcua_read_node" input: endpoint: "{{ $.external_services.opcua_server.endpoint }}" security