【实用】从 Excel 到 AI Agent:OpenClaw 小龙虾 + 口袋数据库实战
- 2026-03-27 16:00:42
哈喽，大家好，我又来了。见字如面，每篇锤炼！这是本公众号第212篇原创文章。
OpenClaw（下文也简称 “小龙虾”） 持续火爆，时不时有读者朋友在技术交流群会问我玩不玩，有没有玩。我当然也是一路关注小龙虾的动态。感慨 AI 发展真是迅猛，仿佛“奇点”已经到来。
最近，我和运维团队的同事们进行了一期关于“多维表格”（口袋数据库）的分享。我在介绍如何使用多维表格的 WebHook 功能将部分数据转换为 API 时，一些已经测试过小龙虾的小伙伴提出想法，是否可以将一些可控的、经过安全过滤的数据以 API 的形式提供给小龙虾使用，并尝试在运维交互场景中实现这些功能。我们立即进行了对接测试，结果非常顺利。这篇文章将记录这一过程。稍作梳理，分享于你。
一、口袋数据库分享记录
我先会整理一下本次“口袋数据库”多维表格的分享过程。
早前系列文章：口袋数据库
1.1 本质：哑资源管理
传统网络运维里，网络工程师管的大部分都是“热资源”。交换机、路由器、防火墙这些网络设备，只要打通 SSH/NetConf/RestFul 等，配置、状态、流量几乎都能通过自动化脚本批量采集、定时巡检。这部分的工具链、自动化方案、运维平台已经相当成熟。
但真正走进数据中心机房现场你会发现：很多场景刚好是反过来的。机柜、U 位、电源、布线、动环配套、机房进出、资产标签…… 这些设施哪怕通电、通网，但作为现场运维人员，你几乎没办法用自动化手段直接采集它们的真实状态。设备在不在、占没占 U 位、有没有标签、接线对不对、有没有闲置 ——只能靠人去现场看、去核对、去登记。
这就是数据中心里典型的“哑资源”运维。它不靠协议，不靠采集，主要靠强流程驱动 + 现场盘点复核。
1.2 痛点：Excel 扛不住，SQL 用不了
哑资源一多，问题立刻就暴露出来。
第一，数据量爆炸。设备、U 位、电源、布线、客户资源、配套设施…… ，随便上万行数据。传统 Excel 根本扛不住这么多关联数据，多几个人编辑就容易卡死、出错。
第二，人跟技术不匹配。想管好，理论上应该上数据库，用 SQL 查询、统计、分析。但数据中心现场，尤其是机房现场一线运维人员，绝大多数不会写 SQL 查询，更不会搭数据库。
结果就是：现场飘着无数个 Excel 文件，反复转发、反复修改、信息重复、版本混乱、谁也不敢保证手里这份是最新的。人力和精力等消耗巨大。
当然，大的网络运维团队会有很多生产支撑系统，解决一些特定痛点，我所讨论的更多是一线人员回到机房现场如何发挥自我能动性。
1.3 破局：我为何选择多维表格
我想，要解决这个问题，必须同时满足三个条件：
一线人员会用、愿意用； 能承载复杂资源关系，不像 Excel 那么脆弱； 能对接自动化，给后台留足扩展空间。
我尝试选择的方案是：多维表格。
它刚好踩中了所有痛点：
学习成本极低，像 Excel 但比 Excel 强。一线运维人员不需要培训，上手就能用：
增删改查，和 Excel 几乎一样； 支持字段类型：文本、日期、数字、单选、多选、成员、附件等； 支持表单录入、批量编辑、筛选排序。 从 Excel 切过来，几乎零成本。
自带数据库逻辑，不用写 SQL 也能管资源。多维表格本质上是可视化的轻量数据库。我们几乎不用懂库表设计、外键、关联查询，界面上点点就能实现：
资源之间关联（如设备 → 机柜 →U 位 → 电源）； 自动统计、去重、汇总； 多视图展示：表格、看板、画布、日历。
强大的仪表盘，一线人员也能做的前端页面。最关键的是仪表盘。以前想做数据大屏、资源概览，需要开发写前端、搭服务。用上多维表格，一线运维自己拖拖拽拽，就能做出：
资源使用率统计 机柜利用率 资产分布 告警 / 待办盘点 进出登记 / 工单跟进
总的来说，在确保安全合规的前提下，赋能一线运维，简单、直观、实用、灵活。机房一线的运维人员也开始具备数据库思维，按数据库范式进行操作。
1.4 进阶：把人工表格，变成自动化闭环
我常年探索网络自动化，拿到一个工具，第一反应永远是：能不能用程序接进去？
多维表格刚好提供了 WebHook 能力。它可以把我们在表格里做好的某一张表、某一个筛选视图、某一个查询结果，直接封装成 API 接口。
这就形成了完美的闭环：
对一线人员：无感使用
打开表格 → 登记、修改、查看 看仪表盘 → 了解现状 完全不用管后台逻辑
对自动化工程师：随意对接
Python/OpenClaw 调用 API 读取、写入、更新、删除数据 对接监控、对接工单、对接其他系统 把整个资源流程串成自动化流
前台是人在操作，后台是程序在流转。
有效信息就这样流转起来，让中间传话的人少下去，让真正干活的人多起来。
二、小龙虾对接口袋数据库
幸运的是，我所在的团队非常自律，尽管我自己还没有开始“挖池养虾”（搭建 / 使用 OpenClaw 环境），但我的同事们已尝试了多次。
在分享过程中，我提到可以将多维表格数据通过“视图”方式进行筛选呈现，并利用 WebHook 结合 API 的形式与自动化手段进行对接。
此时，同事们立刻反馈说，他们可以把这些筛选过部分数据（安全可控）交给 OpenClaw 机器人，让 Agent 自己规划和执行，以满足我们的实际需求。
测试场景
我们当场讨论了一个场景需求：多维表格“机房进出登记表”，当施工方人员登记进入机房时，系统自动通知对应专业接口人。
【实用】登记还在用Excel？AI多维表格方案，快速搭建机房进出支撑系统
以前存在的问题是：出入凭证的有效期通常为一段时间（例如一周），这使得接口人无法准确掌握施工方合作人员具体哪一天进入了机房。虽然这些需求可以通过传统开发方式实现，但显然需要安排时间表并产生一定的成本。
我即刻在进出机房登记的 WPS 多维表格中筛选出当天的进站信息，并创建了一个“视图”，然后将该视图封装成 API。
信息中包含以下字段：“进站人员”、“接口人”、“接口人邮箱”、“位置”、“任务”等。初步要实现的功能是：周期性识别，当某人（XXX）进站时，系统会自动将进站信息发送邮件给其对应的接口人（YYY）。
我把这份 API 给了“养虾”的小伙伴。
小伙伴联动小龙虾，表达了具体需求。
很快，我们就测通了。
整个过程只用了大约 10 到 20 分钟吧，我们在“三言两语”间就实现了一个实际需求。这种速度，在传统开发方式中，是无法想象的。
当然，之后我们还继续进行了交互迭代和优化。调测到差不多了，我们便将它封装成 Skill，变成了一个例行周期任务。
这套方法具有迁移性，由此及彼，我们又测试了工单催办、值班提醒等功能。如果冒进一点，Netmiko/Paramiko/Nornir 等联机操作也是可以尝试的。就这样，交互协作类的场景开发在“虾池”中迅速展开。
三、本文总结
哑资源管理，一直是运维里的脏活累活：
传统自动化采不到 Excel 管不住 数据库门槛高 文件乱、版本乱、数据乱
而“多维表格 + WebHook + Python/OpenClaw ”这套组合，刚好给出了一个低成本、可落地、能量产的方案：
前端像 Excel，人人可用 中间像数据库，关系清晰 后台开放 API，支持 Python/OpenClaw 直接接入，自动化能力完全打通。这也是我一直想做的——赋能一线运维，做一个能揣在手里、随时能用的口袋数据库。
本次，OpenClaw 小龙虾这样的切入应用方式有点出乎我的意料。这可能是源于在口袋数据库的分享过程中，一群自律的小伙伴们自然而然地朝着大体相同的方向进行探索。感谢这次交流，它确实促进了我们的进步。
我们只通过 API 输出经过视图过滤、安全可控的少量数据，而不是把全量库表交给 AI，在效率与安全之间做到平衡。
低成本、零代码、可自动化、能接 AI—— 这就是一线运维真正能用的「口袋数据库」。
在这里，我想顺便提一下。尽管网络上关于 OpenClaw 小龙虾的资料非常丰富，可能仍有一些读者对它不太了解。我在众多的资料中筛选出两份，一份适合初学者了解基本概念，另一份则适合已经有一定基础的朋友进阶学习。
附上从海南博鳌到三亚高铁上的车窗照片作为配图。列车穿行在海南的腹地，窗外是一幅流动的热带画卷。成片的椰林与槟榔树在阳光下舒展着浓绿的枝叶，远处黛色的山峦在薄雾中若隐若现。风掠过田埂，把金黄的草浪和青绿的椰影揉成一片。舒服。
今晚先分享这些，后续将继续梳理分享。
我知乎总目录 https://zhuanlan.zhihu.com/p/370526806 读者再创作目录 https://zhuanlan.zhihu.com/p/498090646
感谢阅读，欢迎关注点赞，转发分享。
觉得有帮助，特别认可，可打赏 1 元鼓励！
2026 年 3 月于广东汕头
