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限流或消息轰炸。