我让 OpenClaw 接管了 200个加油站的运维查询-夜雨聆风

我让 OpenClaw 接管了 200个加油站的运维查询

本文作者 nick6066751086 是阿里云天池”千模百炼”全球 AI 开发者系列锦标赛 —— OpenClaw 养虾挑战赛的参赛者。本篇作品展示了如何通过阿里云轻量应用服务器 × OpenClaw 搭建加油站运维查询接管工具。

一、背景：为什么做这个？

受够了”作为 AI 语言模型…”

在遇到 OpenClaw 之前，我和大多数人一样，对 AI 的印象还停留在：

问它写个 SQL，它给你一堆语法正确的废话；
问它查数据，它说”我没有访问数据库的能力”；
让它干活，它说”建议您联系专业开发人员”。

直到我发现了 OpenClaw —— 这个被称作”24 小时待命贾维斯”的神器。

加油站的真实痛点

我负责管理一个连锁加油站系统，包含：

200 个站点，分布在多个区域；
每天 30000+ 笔交易，数据量持续增长；
复杂的表结构，oilvouch_station 表有 75 个字段；
频繁的查询需求：日报、周报、异常检测、流量分析。

传统方式的门槛：

管理员需要记住表名是 oilvouch_station 不是 station；
站点编号在 nodeno 字段不是 station_id；
时间字段叫 opetime 不是 created_at；
金额要自己计算 liter × price。

OpenClaw 方式：

用户："看一下今天各站点的数据"OilAgent: [自动理解意图] → [生成并执行 SQL] → [返回格式化结果]

核心思路：把 SQL 的复杂性藏在 Agent 后面，让用户用自然语言对话。

二、部署过程（30 分钟上手）

环境配置

核心步骤

安装过程非常直接，关键是理解 OpenClaw 的架构：

Gateway —— Agent 的”大脑”，负责调度任务和调用技能；
Skills —— 扩展能力的”手脚”，每个技能完成特定任务；
MEMORY.md —— 长期记忆，让 Agent 越用越懂业务。

三、技能设计思路：OilQuery

核心目标

OilQuery 的设计目标只有一个：让不会 SQL 的人也能查数据库。

三大设计原则

1. 防御性执行

AI自己写的 SQL 可能有问题，Agent 需要在执行前自动修正：

移除反引号（Markdown 格式残留）；
双引号转单引号（MySQL 兼容）；
自动添加LIMIT防止全表扫描；
SQLite 方言转 MySQL 语法；
等等一系列问题。

效果：AI写SELECT * FROM table，实际执行SELECT * FROM table LIMIT 30。

2. 数据类型安全

MySQL 返回的DECIMAL和DATETIME类型无法直接序列化为 JSON，会导致 Agent 输出失败。

解决方案：自定义 JSON 编码器，在返回前统一转换：

DECIMAL(12,2) → float
DATETIME → ISO 8601 字符串

3. 结果保护

第一次测试时，一个没加LIMIT的查询返回了 7 万行数据，直接撑爆了输出。

保护措施：

单字段超过 500 字符自动截断；
结果超过 30 行只保留前 30 行；
在warnings中告知用户数据被截断，这样下一次的小龙虾会更加聪明。

四、实战演示

说明：以下案例均基于真实业务数据，截图展示了 OilAgent 的完整执行过程。

场景 1：最新交易查询

用户提问：

查一下最新一笔加油数据

OilClaw 结果：

场景 2：今日站点排名

用户提问：

看一下今天各站点的数据，按交易量排名

OilClaw 结果：

场景 3：近 7 天趋势分析

用户提问：

查一下最近 7 天的交易趋势

OilClaw 结果：

五、踩坑记录

坑 1：表结构探查

问题：第一次查询用了id字段，报错Unknown column 'id'。

原因：oilvouch_station表没有id列，主键是复合键(groupno, nodeno, macno, vouchno, ttc)。

解决思路：

在 SKILL.md 中明确写入”先探查表结构再执行业务查询”的流程，强制 Agent 第一步必须调用INFORMATION_SCHEMA确认字段。

经验：永远不要假设表结构，尤其是遗留系统。

坑 2：数据库连接超时

问题：查询经常超时，返回(pymysql.err.OperationalError)。

原因：

网络延迟（数据库在远程服务器）；
连接池配置不当；
查询语句缺少LIMIT。

解决思路：

SQLAlchemy 添加pool_pre_ping=True和连接超时；
强制所有SELECT语句添加LIMIT 30。

坑 3：JSON 序列化失败

问题：TypeError: Object of type Decimal is not JSON serializable。

原因：MySQL 的DECIMAL和DATETIME类型无法直接被json.dumps处理。

解决思路：自定义 JSON 编码器，在返回前统一转换类型。

六、技术架构

整体架构

用户 (自然语言)    ↓OpenClaw (Agent 核心)    ↓OilQuery (技能)    ↓execute_sql.py (SQL 执行引擎)    ↓MySQL (业务数据)

关键设计：

无状态执行：每次 SQL 执行独立，不依赖会话；
权限隔离：数据库账号只有 SELECT 权限，防止误删；
结果缓存：相同查询不重复执行（由 OpenClaw 自动处理）。

七、总结

养虾心得

OpenClaw 给我的三个惊喜：

真正的自主执行

不是”建议你怎么做”，而是”直接帮你做”；
有 Shell 权限，有文件系统访问，有数据库连接；
是一个真正的”数字员工”，不是”聊天机器人”。

技能扩展的灵活性

一个SKILL.md + 一个 Python 脚本 = 新能力；
无需重新训练模型，无需复杂配置；
社区技能可以直接复用。

记忆的持久化

MEMORY.md让 Agent 有长期记忆；

每次对话都在积累经验；
越用越聪明，越用越懂业务。

对 AI 的思考

AI 的终局不是聊天，是执行。

当我们把 AI 从对话框里放出来，给它权限、给它工具、给它场景，它展现出的生产力是惊人的。

OpenClaw 代表的是一种新范式：

不再是”AI 建议…”；
而是”AI 已执行…”。

致谢

感谢阿里云天池提供这个展示平台；
感谢 OpenClaw 社区的开源贡献；
感谢龙虾宴的诱惑（是的我是为了吃来的🦞）。

想要亲自上手搭建 Agent？

一键部署 Hermes & OpenClaw 传送门：

https://www.aliyun.com/activity/ecs/clawdbot?utm_content=g_1000409940

更多优秀作品场景化展示，将陆续发布，敬请期待。

/END/