【实用】从 Excel 到 AI Agent：OpenClaw 小龙虾 + 口袋数据库实战

哈喽，大家好，我又来了。见字如面，每篇锤炼！

OpenClaw（下文也简称 “小龙虾”） 持续火爆，时不时有读者朋友在技术交流群会问我玩不玩，有没有玩。我当然也是一路关注小龙虾的动态。感慨 AI 发展真是迅猛，仿佛“奇点”已经到来。

最近，我和运维团队的同事们进行了一期关于“多维表格”（口袋数据库）的分享。我在介绍如何使用多维表格的 WebHook 功能将部分数据转换为 API 时，一些已经测试过小龙虾的小伙伴提出想法，是否可以将一些可控的、经过安全过滤的数据以 API 的形式提供给小龙虾使用，并尝试在运维交互场景中实现这些功能。我们立即进行了对接测试，结果非常顺利。这篇文章将记录这一过程。稍作梳理，分享于你。

• 【网工手艺】专栏入口（总目录）
• 《网络工程师的 AI 之路》勘误及优化全纪录
• 《网络工程师的 Python 之路》勘误及优化全纪录
• 读者再次创作梳理及友情链接（分支目录，专注实战，欢迎投稿）

我先会整理一下本次“口袋数据库”多维表格的分享过程。

早前系列文章：口袋数据库

传统网络运维里，网络工程师管的大部分都是“热资源”。交换机、路由器、防火墙这些网络设备，只要打通 SSH/NetConf/RestFul 等，配置、状态、流量几乎都能通过自动化脚本批量采集、定时巡检。这部分的工具链、自动化方案、运维平台已经相当成熟。

但真正走进数据中心机房现场你会发现：很多场景刚好是反过来的。机柜、U 位、电源、布线、动环配套、机房进出、资产标签…… 这些设施哪怕通电、通网，但作为现场运维人员，你几乎没办法用自动化手段直接采集它们的真实状态。设备在不在、占没占 U 位、有没有标签、接线对不对、有没有闲置 ——只能靠人去现场看、去核对、去登记。

这就是数据中心里典型的“哑资源”运维。它不靠协议，不靠采集，主要靠强流程驱动 + 现场盘点复核。

哑资源一多，问题立刻就暴露出来。

第一，数据量爆炸。设备、U 位、电源、布线、客户资源、配套设施…… ，随便上万行数据。传统 Excel 根本扛不住这么多关联数据，多几个人编辑就容易卡死、出错。

第二，人跟技术不匹配。想管好，理论上应该上数据库，用 SQL 查询、统计、分析。但数据中心现场，尤其是机房现场一线运维人员，绝大多数不会写 SQL 查询，更不会搭数据库。

结果就是：现场飘着无数个 Excel 文件，反复转发、反复修改、信息重复、版本混乱、谁也不敢保证手里这份是最新的。人力和精力等消耗巨大。

当然，大的网络运维团队会有很多生产支撑系统，解决一些特定痛点，我所讨论的更多是一线人员回到机房现场如何发挥自我能动性。

我想，要解决这个问题，必须同时满足三个条件：

• 一线人员会用、愿意用；
• 能承载复杂资源关系，不像 Excel 那么脆弱；
• 能对接自动化，给后台留足扩展空间。

我尝试选择的方案是：多维表格。

它刚好踩中了所有痛点：

1. 学习成本极低，像 Excel 但比 Excel 强。一线运维人员不需要培训，上手就能用：

• 增删改查，和 Excel 几乎一样；
• 支持字段类型：文本、日期、数字、单选、多选、成员、附件等；
• 支持表单录入、批量编辑、筛选排序。 从 Excel 切过来，几乎零成本。
• 自带数据库逻辑，不用写 SQL 也能管资源。多维表格本质上是可视化的轻量数据库。我们几乎不用懂库表设计、外键、关联查询，界面上点点就能实现：
• 资源之间关联（如设备 → 机柜 →U 位 → 电源）；
• 自动统计、去重、汇总；
• 多视图展示：表格、看板、画布、日历。
• 强大的仪表盘，一线人员也能做的前端页面。最关键的是仪表盘。以前想做数据大屏、资源概览，需要开发写前端、搭服务。用上多维表格，一线运维自己拖拖拽拽，就能做出：
• 资源使用率统计
• 机柜利用率
• 资产分布
• 告警 / 待办盘点
• 进出登记 / 工单跟进

总的来说，在确保安全合规的前提下，赋能一线运维，简单、直观、实用、灵活。机房一线的运维人员也开始具备数据库思维，按数据库范式进行操作。

我常年探索网络自动化，拿到一个工具，第一反应永远是：能不能用程序接进去？

多维表格刚好提供了 WebHook 能力。它可以把我们在表格里做好的某一张表、某一个筛选视图、某一个查询结果，直接封装成 API 接口。

这就形成了完美的闭环：

对一线人员：无感使用

• 打开表格 → 登记、修改、查看
• 看仪表盘 → 了解现状
• 完全不用管后台逻辑

对自动化工程师：随意对接

• Python/OpenClaw 调用 API
• 读取、写入、更新、删除数据
• 对接监控、对接工单、对接其他系统
• 把整个资源流程串成自动化流

前台是人在操作，后台是程序在流转。

有效信息就这样流转起来，让中间传话的人少下去，让真正干活的人多起来。

幸运的是，我所在的团队非常自律，尽管我自己还没有开始“挖池养虾”（搭建 / 使用 OpenClaw 环境），但我的同事们已尝试了多次。

在分享过程中，我提到可以将多维表格数据通过“视图”方式进行筛选呈现，并利用 WebHook 结合 API 的形式与自动化手段进行对接。

此时，同事们立刻反馈说，他们可以把这些筛选过部分数据（安全可控）交给 OpenClaw 机器人，让 Agent 自己规划和执行，以满足我们的实际需求。

我们当场讨论了一个场景需求：多维表格“机房进出登记表”，当施工方人员登记进入机房时，系统自动通知对应专业接口人。

【实用】登记还在用Excel？AI多维表格方案，快速搭建机房进出支撑系统

以前存在的问题是：出入凭证的有效期通常为一段时间（例如一周），这使得接口人无法准确掌握施工方合作人员具体哪一天进入了机房。虽然这些需求可以通过传统开发方式实现，但显然需要安排时间表并产生一定的成本。

我即刻在进出机房登记的 WPS 多维表格中筛选出当天的进站信息，并创建了一个“视图”，然后将该视图封装成 API。

信息中包含以下字段：“进站人员”、“接口人”、“接口人邮箱”、“位置”、“任务”等。初步要实现的功能是：周期性识别，当某人（XXX）进站时，系统会自动将进站信息发送邮件给其对应的接口人（YYY）。

我把这份 API 给了“养虾”的小伙伴。

小伙伴联动小龙虾，表达了具体需求。

很快，我们就测通了。

整个过程只用了大约 10 到 20 分钟吧，我们在“三言两语”间就实现了一个实际需求。这种速度，在传统开发方式中，是无法想象的。

当然，之后我们还继续进行了交互迭代和优化。调测到差不多了，我们便将它封装成 Skill，变成了一个例行周期任务。

openclaw 龙虾

这套方法具有迁移性，由此及彼，我们又测试了工单催办、值班提醒等功能。就这样，交互协作类的场景开发在“虾池”中迅速展开。

哑资源管理，一直是运维里的脏活累活：

• 传统自动化采不到
• Excel 管不住
• 数据库门槛高
• 文件乱、版本乱、数据乱

而“多维表格 + WebHook + Python/OpenClaw ”这套组合，刚好给出了一个低成本、可落地、能量产的方案：

• 前端像 Excel，人人可用
• 中间像数据库，关系清晰
• 后台开放 API，支持 Python/OpenClaw 直接接入，自动化能力完全打通。这也是我一直想做的——赋能一线运维，做一个能揣在手里、随时能用的口袋数据库。

本次，OpenClaw 小龙虾这样的切入应用方式有点出乎我的意料。这可能是源于在口袋数据库的分享过程中，一群自律的小伙伴们自然而然地朝着大体相同的方向进行探索。感谢这次交流，它确实促进了我们的进步。

【发布】自学自驱学习体系

【思考】关于网络工程师Python进阶

我们只通过 API 输出经过视图过滤、安全可控的少量数据，而不是把全量库表交给 AI，在效率与安全之间做到平衡。

低成本、零代码、可自动化、能接 AI—— 这就是一线运维真正能用的「口袋数据库」。

在这里，我想顺便提一下。尽管网络上关于 OpenClaw 小龙虾的资料非常丰富，可能仍有一些读者对它不太了解。我在众多的资料中筛选出两份，一份适合初学者了解基本概念，另一份则适合已经有一定基础的朋友进阶学习。

大白话拆解 OpenClaw：像组装高达一样拼好虾

（可能全网最全/长的）2万字Openclaw保姆教程

附上从海南博鳌到三亚高铁上的车窗照片作为配图。列车穿行在海南的腹地，窗外是一幅流动的热带画卷。成片的椰林与槟榔树在阳光下舒展着浓绿的枝叶，远处黛色的山峦在薄雾中若隐若现。风掠过田埂，把金黄的草浪和青绿的椰影揉成一片。舒服。

今晚先分享这些，后续将继续梳理分享。

祝贺！你终于看完了！

我全开源写作，不设任何付费阅读内容，内容有疑问随时交流，文章反复打磨！

欢迎关注点赞收藏评论交流，如果觉得特别认可，可挑一篇最喜欢的打赏 1元 支持。感谢！

发布2026年03月于广东汕头

更新2026年03月于广东汕头