ops-framework

核心用法

ops-framework 是专为 OpenClaw 设计的运维监控技能，采用"外挂脚本"架构实现长任务的零Token管理。核心组件包括 ops-monitor.py 本地监控脚本和声明式的 ops-jobs.json 任务配置。用户通过定义任务类型（long_running_read/one_shot_read/one_shot_write）、风险等级（read_only/write_local/write_external）及执行策略，即可实现任务的自动调度、状态检测、断点续跑和Telegram告警通知。

脚本设计为高频调用模式（通过launchd/systemd/cron触发），内部根据策略自主决策是否上报，避免AI模型持续消耗Token监控进度。状态检测依赖标准化JSON输出契约，支持进程ID、进度对象、停滞检测键等字段，实现精准的任务生命周期管理。

显著优点

成本优化突出：0-token设计理念切中AI运维痛点，将长任务执行与监控彻底剥离模型上下文，显著降低持续运行成本。安全架构保守：默认阻断one_shot_write任务，autoResume默认为false，形成"默认拒绝"的安全基线。工程实现严谨：原子文件写入、严格JSON Schema验证、路径规范化处理、超时控制等细节体现生产级考量。零依赖部署：仅使用Python 3.10+标准库，彻底消除供应链攻击风险，部署即插即用。生态整合自然：优先使用openclaw message send，无缝回退至Telegram HTTP API，适配OpenClaw原生工作流。

潜在缺点与局限性

配置门槛存在：需要用户理解kind/risk/policy三层抽象模型，并正确编写符合状态契约的脚本，学习曲线较陡。命令执行风险：核心功能依赖subprocess.run()执行用户配置命令，虽使用列表传参避免shell注入，但若用户主动配置shell命令仍存在风险敞口。权限管控外包：配置文件安全依赖操作系统权限，框架自身未实施权限检查或命令白名单机制。审计能力缺失：无内置审计日志记录配置变更与命令执行历史，事后追溯困难。状态文件单点：所有状态集中存储于单一JSON文件，高并发场景下存在竞态条件风险（尽管原子写入可缓解）。

适合的目标群体

OpenClaw重度用户：需要长时间运行数据同步、资产盘点、健康巡检等任务，且希望将AI Token消耗控制在触发式交互场景。运维自动化工程师：具备脚本编写能力，追求"配置即代码"的声明式任务管理，熟悉systemd/cron等调度工具。安全敏感型团队：对第三方依赖持谨慎态度，偏好标准库-only方案，重视默认安全策略而非事后补救。个人开发者与小型团队：无需复杂分布式调度系统，追求轻量级、单主机部署的监控解决方案。

使用风险

配置注入风险：攻击者若获得~/.openclaw/net/目录写权限，可通过篡改ops-jobs.json注入恶意命令。建议配置文件权限设为600并纳入版本控制。状态欺骗风险：ops-monitor.json被篡改可能导致监控盲区，虽不影响实际执行权限，但会延误异常发现。Token泄露风险：Telegram bot token存储于openclaw.json，需确保该文件不被意外提交或读取。命令注入误用：用户为便利可能在配置中使用shell=True或管道命令，破坏安全设计意图，需严格代码审查。调度过载风险：高频tick调用若未正确配置静默策略，可能导致Telegram API限流或消息轰炸。

核心用法

Ops Framework 是一套面向 OpenClaw 生态的零Token长任务运维框架，采用「外挂脚本」模式替代模型持续监听，显著降低长任务场景下的 token 消耗。

双组件架构：

• ops-monitor.py：纯本地 Python 脚本，负责任务状态轮询、卡住检测、Telegram 通知推送
• ops-jobs.json：声明式任务配置，定义任务类型（长时只读/一次性只读/一次性写入）、风险等级、执行策略

三大任务模式：

| 类型 | 自动执行 | 风险要求 | 关键特性 |

|------|---------|---------|---------|

| `long_running_read` | ✅ 条件触发 | `read_only` + `autoResume=true` | 断点续跑、进度追踪、卡死检测 |

| `one_shot_read` | ✅ 可显式/队列触发 | `read_only` 限定 | 静默执行，仅异常时告警 |

| `one_shot_write` | ❌ **完全阻断** | 任意 | 需显式审批 + 强制链式只读验证任务 |

状态契约：长任务需输出 JSON 格式状态（running, completed, progressKey 等），框架据此判断续跑时机与停滞告警。

显著优点

1. 零Token设计哲学：长任务脱离模型上下文，脚本级自主运行，仅关键节点（进度/异常）回推通知
2. 安全分层清晰：写操作「默认拒绝」而非「默认允许」，配合审批+验证双保险，符合生产环境安全基线
3. 依赖极简：纯 Python 3.10+ 标准库，零第三方包，供应链攻击面趋近于零
4. 声明式配置：任务策略、风险等级、通知频率全部外置，版本化可审计
5. 渐进式集成：支持 openclaw message send 原生通道与 Telegram HTTP API 双 fallback，降级 graceful

潜在局限

1. 平台绑定较深：路径结构、环境变量 (OPENCLAW_HOME)、配置文件 (openclaw.json) 均假设 OpenClaw 生态，跨平台迁移需适配
2. Telegram 单通道：当前仅内置 Telegram Bot 通知，企业微信/钉钉/Slack 等需自行扩展
3. 无内置可视化：状态查看依赖 CLI (ops-monitor.py status) 或 Telegram 文本推送，无 Web Dashboard
4. Python 版本硬性要求：3.10+ 的类型注解语法排除旧系统（如 Ubuntu 20.04 默认 Python 3.8）
5. subprocess 执行模型：任务命令通过 subprocess.run 唤起，虽有限制但仍存在配置不慎导致的命令风险

适合人群

• OpenClaw 重度用户：需要将大模型与长时运维任务解耦，避免上下文窗口被进度查询占满
• 中小团队 SRE：无预算购买商业 job scheduler，需轻量级自托管方案
• 合规敏感场景：写操作必须留痕、审批、验证的审计要求环境
• 极简主义者：拒绝 Kubernetes/Apache Airflow 等重型编排，追求「一个脚本 + 一个 JSON」的优雅

常规风险

| 风险项 | 等级 | 说明 |

|--------|------|------|

| Telegram Bot Token 泄露 | 中 | 存储于 `openclaw.json`，需确保文件权限 600 |

| 配置误用导致命令执行 | 中 | `subprocess.run` 执行用户配置命令，需遵循最小权限原则配置 job |

| 长任务状态契约破坏 | 低 | 自定义脚本未按 JSON 格式输出状态，导致续跑/告警逻辑失效 |

| 网络可达性 | 低 | Telegram API 依赖外网，需考虑防火墙/代理配置 (`HTTPS_PROXY`) |

| 状态文件损坏 | 低 | `ops-monitor.json` 为自动生成的本地状态，异常退出可能导致进度丢失 |

> 认证结论：安全等级 A（70分），来源可信度 T3（个人/社区项目），代码结构清晰、安全设计合理，满足企业级使用基础要求。