最近有个朋友找我吐槽说团队里管着几十套PolarDB实例日常光是做慢SQL排查、参数巡检、容量评估就要占掉一个DBA大半天的精力而且很多操作都是重复劳动。他问我能不能搞一套企业内部的AI Agent把这些活儿自动跑起来。聊了一圈下来我决定直接基于OpenClaw生态来做二次开发结合PolarDB Agent Express这套数据库Agent开发包把Skills开发和Flow编排彻底打通。这篇文章就是我这次实践的一次完整复盘。我会从整体设计思路讲起覆盖环境部署、Skill开发、Flow编排的完整路径最后再把我踩过的坑和排查方法整理成速查表。无论你是刚接触AI Agent开发不久还是已经在用Claude Code、n8n之类的工具这篇文章都能给你一套可以直接参考的企业级落地思路。1. 整体设计与思路拆解1.1 为什么选择OpenClaw而不是从零造轮子AI Agent开发看起来门槛不高但真正要做到企业可用要解决的事情其实非常多Agent怎么接收消息、怎么管理上下文记忆、怎么调用外部工具、怎么按流程执行多步任务、怎么响应超时和异常。这些如果全从零开始写光是把消息通道、工具协议、对话状态管理串起来就要折腾很久而且很容易在边缘情况里翻车。OpenClaw的优势在于它把这些基础能力都沉淀成了现成的运行时。它天然支持Skills机制可以像插件一样往Agent身上挂载能力支持MCP协议接入外部工具还内置了消息通道和记忆管理。这些能力组合起来基本就是一套“Agent专用的操作系统”。我更看重的是它可以私有化部署不做云上强制回传数据能留在企业内网对于数据库操作这类敏感场景这是刚需。相比之下Claude Code更偏开发辅助场景n8n则侧重于自动化工作流两者都不完全覆盖“Agent自主决策流程编排工具调用”这个组合需求。OpenClaw恰好把这几块都占了所以我没有犹豫直接定了它作为底座。1.2 PolarDB Agent Express在整套方案里的角色PolarDB Agent Express并不是一个独立的对话机器人而是一套面向PolarDB数据库场景的Agent开发包。它做的事情很明确把数据库领域的常用操作比如实例状态查询、慢SQL提取、Explain分析、参数诊断、备份状态检查等封装成标准化的Skill和Flow模板。换句话说如果你在OpenClaw里裸写一个数据库Agent你需要自己琢磨怎么封装SQL执行器、怎么定义慢SQL的判断规则、怎么把诊断结果格式化成报告。而用了PolarDB Agent Express这些前置资产都已经在那里了你要做的是理解它的封装方式然后在上面做定制开发让它符合自己团队的具体流程。这就好比你要开一家餐厅OpenClaw是厨房水电和炉灶这些基础设施PolarDB Agent Express是已经配好的半成品菜和标准菜谱你要做的不是从种菜开始而是根据顾客口味调整配方、设计出餐流程。1.3 Skills Flow的组合逻辑单点能力和业务流程各司其职Skills解决的是“Agent能做什么”Flow解决的是“Agent应该怎么按步骤做完一件事”。如果把Agent比作一个员工Skills是他掌握的技能点Flow是公司的标准作业流程。技能再多如果不知道什么时候该用哪个、做完一步之后下一步干什么这个员工依然干不好活。我在这次实践中体会很深的一点是不要试图把逻辑全部写进一个Skill里。Skill应该保持单一职责比如“查询慢SQL”“提取某条SQL的执行计划”“生成参数诊断建议”一个Skill就干一件事。真正让Agent智能的是Flow把多步Skill串起来配合条件分支和异常处理。这样每个Skill都可以独立测试、独立复用Flow出问题了也只是改流程定义不伤及底层逻辑。2. 环境准备与基础部署2.1 部署形态选择企业内网优先考虑Linux服务OpenClaw支持多种运行环境包括常规Linux服务器、Mac本机、Windows下的WSL2甚至安卓Termux上也能原生运行。但企业场景下我强烈建议直接放在一台Linux服务器或容器环境里跑原因很简单稳定性。Agent不是一次性脚本它要7x24小时在线响应。放在笔记本电脑上一合盖就断放在Windows上自动更新可能把环境搞挂WSL2虽然能用但网络代理和文件系统性能都比较折腾。如果只是个人开发测试Mac或者WSL2都没问题。但这次项目要给团队用我直接开了一台2C4G的云服务器系统用的Ubuntu 22.04然后用systemd把Agent跑成后台服务这样重启服务器也能自动拉起。2.2 OpenClaw部署三步走安装、配置文件、启动验证OpenClaw的安装方式其实非常轻量不需要依赖一堆编译工具链。它主要通过脚本安装安装完成后会在用户目录生成配置目录和可执行文件。我这次的实际安装过程可以整理成三个步骤。第一步是执行安装脚本这个过程会检测当前系统环境。如果你的机器装过nvm、node等环境通常不会有什么问题如果是纯新的服务器建议先把基础依赖装好。这里要提醒一下安装过程中如果遇到网络下载慢可以考虑配置镜像源否则容易卡在拉取依赖包的环节。第二步是初始化配置目录。安装完成后第一次启动前需要看一眼默认生成的配置文件里面包含Agent名称、监听地址、消息通道开关等基础选项。对于企业内网部署建议把监听地址绑定在内网IP不要默认暴露到公网。第三步是启动并验证。OpenClaw启动后会在终端输出一个邀请二维码和一段本地链接。首次使用要扫码或打开链接完成绑定绑定完成后Agent就能接收来自绑定账号的消息了。验证是否运行正常最简单的方式是给Agent发一条问候消息看它能不能正常回复。这里要特别说明一下WSL2的问题。我看到很多人在网上问 “OpenClaw could not safely verify the WSL2 environment”如果你用WSL2做开发遇到这个提示不要慌它只表示OpenClaw无法确认WSL2的内核版本或系统环境是否符合预期通常是因为WSL2内核版本太老或者没有启用systemd。解决办法是升级WSL2内核并在.wslconfig里启用systemd这个后面我会在问题章节详细展开。2.3 PolarDB Agent Express初始化安装和加载PolarDB Agent Express是作为OpenClaw的扩展包形式存在的。初始化过程主要分材料准备、安装扩展和确认加载三步。材料准备上你需要确认你的PolarDB实例连接信息包括主机地址、端口、数据库账号和密码。为了安全起见我在服务器上用环境变量存储这些信息而不是直接写进Skill代码里。OpenClaw本身也支持环境变量的读取这样后续代码里只需要引用环境变量名敏感信息就不会被硬编码。安装扩展这一步PolarDB Agent Express通常是以目录形式释放到OpenClaw的skills或plugins目录下的。按官方给的包结构放到指定目录后重启OpenClaw服务让它扫描并加载新增的Skill。加载成功后Agent的知识库里就多出了这批数据库操作能力。确认加载的方法是查看OpenClaw的启动日志日志里会列出扫描到的Skill名称和数量。如果发现某个Skill没有被识别优先检查目录权限和清单文件格式。这一步走通了环境就备齐了后面全是开发工作。3. Skills开发实战3.1 理解Skill机制LLM眼里的一本操作手册OpenClaw的Skill机制本质上是一种“提示词可执行代码”的组合。每个Skill都有一个描述文件这个文件的作用是告诉大模型“我是什么技能、什么时候该调用我、调用我需要哪些参数”。而Skill真正干活的部分是一个可执行脚本或者命令大模型只负责在合适的时机把参数拼出来、触发脚本然后读取脚本的输出结果。你可以把这个机制想象成一本操作手册大模型是操作员Skill描述文件是目录页脚本是手册里对应的那页详细步骤。操作员不会每一步都亲自动手但需要知道什么时候翻到哪一页并且能把工具递到正确的人手里。理解这个机制之后你就会明白一个关键点Skill描述文件写得清不清楚直接影响Agent会不会正确调用它。描述写得含糊Agent可能在无关场景里乱调用参数不明确Agent可能给你传一个格式错误的参数。所以不要觉得实现脚本写完就结束了描述文件才是真正要下功夫打磨的地方。3.2 从零开发一个慢SQL巡检Skill我这次做的第一个自研Skill是慢SQL巡检这是数据库运维里最高频的场景。目标很简单给定一个PolarDB实例ID自动拉取最近15分钟的慢SQL列表按执行次数和平均耗时排序输出一份精简报表。先看一下Skill描述文件的结构。以YAML格式为例需要包含Skill名称、用途描述、入参定义、输出格式几个核心字段name: polar_agent_express_slow_sql_scan description: zh: 巡检指定PolarDB实例的慢SQL情况默认拉取最近15分钟的慢SQL按执行次数倒序输出前十条并附平均耗时。 en: Scan slow SQL of a given PolarDB instance, fetch last 15 minutes, sort by execution count desc, output top 10. parameters: instance_id: type: string description: PolarDB实例ID required: true window_minutes: type: integer description: 巡检时间窗口单位分钟默认15 required: false output: type: text description: 表格形式的慢SQL统计包含执行次数、平均耗时、SQL摘要这个描述文件里最关键的地方是description要写清楚“什么时候该用这个Skill”。我把“巡检”“慢SQL”“PolarDB”这些触发关键词都放进了中文描述里这样当企业微信或钉钉群里有人说“帮我看看慢SQL”大模型就能立刻联想到这个Skill。接下来是实现脚本。这里我用了Python因为PolarDB有成熟的Python SDK。脚本的核心逻辑不复杂接收instance_id和window_minutes参数通过SDK查询PolarDB的慢SQL明细接口然后做聚合统计最后控制台输出一个对齐好的文本表格。由于不是每个团队都统一用一套数据库管理API我这里用伪代码展示核心结构import os, sys, argparse # 读取数据库连接配置避免硬编码敏感信息 HOST os.getenv(PolarDB_HOST) PORT os.getenv(PolarDB_PORT) USER os.getenv(PolarDB_USER) PASSWORD os.getenv(PolarDB_PASSWORD) def fetch_slow_sql(instance_id, window_minutes): # 调用PolarDB开放API或直连information_schema实现 # 返回格式[{exec_count, avg_latency, sql_text}, ...] pass def format_report(rows): lines [| 执行次数 | 平均耗时(ms) | SQL摘要 |, | --- | --- | --- |] for row in rows[:10]: summary row[sql_text][:80].replace(|, \\|) lines.append(f| {row[exec_count]} | {row[avg_latency]:.1f} | {summary} |) return \n.join(lines) def main(): parser argparse.ArgumentParser() parser.add_argument(--instance_id, requiredTrue) parser.add_argument(--window_minutes, typeint, default15) args parser.parse_args() rows fetch_slow_sql(args.instance_id, args.window_minutes) print(format_report(rows)) if __name__ __main__: main()写完脚本之后把它和描述文件一起放到OpenClaw的Skill目录下重启服务或者执行热加载命令Skill就能被识别了。3.3 参数设计与输入输出规范决定Agent调用成功率Skill参数设计这一块我吃过亏多说几句。刚开始我设计Skill时参数写得很随意比如“查询慢SQL”直接用自然语言描述参数结果Agent在调用时经常把多余的话也拼进去导致脚本解析失败。后来我总结出三条规范按这个来基本不会再出问题。第一参数类型必须明确。只要是数字就标成integer不要用string。Agent在理解参数类型之后就会把聊天内容里的数字正确提取出来不会给你传一个“十五”这样的中文。第二时间窗口这类参数要提供默认值。Agent不是每次都会把所有参数问齐如果你的Skill逻辑允许尽量给每个可选参数一个合理的默认值比如默认15分钟、默认取前10条。这样即使Agent漏传参数Skill也能正常执行。第三输出格式要靠近纯文本或者Markdown表格不要输出复杂JSON对象。大模型读Markdown表格的能力很强读完就能把内容组织成回复而JSON输出虽然在程序里好用但大模型读起来不够直观容易在转述时丢掉字段。我后来把所有查询类Skill的出参都统一成了Markdown表格Agent的回复质量明显提升。3.4 通过MCP暴露只读查询之外的管控能力虽然PolarDB Agent Express预置了不少查询类工具但企业Agent不能只做查询有时候还需要执行一些变更操作比如开启SQL洞察、调整参数、触发备份等。这些管控能力我通过MCP协议接入了OpenClaw。MCPModel Context Protocol是一个标准化工具接入协议相当于给Agent加了一套统一的USB接口。不管你的工具是用Python写的、Go写的还是直接调REST API只要封装成MCP ServerOpenClaw就能通过标准协议调用。我写了一个轻量的MCP Server把PolarDB的实例启停、参数修改、备份触发这几个操作封装成独立工具并在工具描述里明确标注了“高危操作”。这里要特别提醒一点查询类Skill可以放心交给Agent自主调用但管控类工具必须加审批环节。我的做法是在MCP工具里设计了一种类“确认后执行”的模式Agent调用工具时先返回一个待执行确认的提示等高权限用户确认后才真正发起变更。这个设计在后面的Flow编排里也会进一步用到。4. Flow编排实战4.1 为什么单Skill不够用以异常巡检为例如果只是单一查询单Skill就够用了。但真实的数据库运维场景往往是多步骤的。比如一次完整的巡检不应该只查慢SQL它应该是这样的链路先确认实例正常运行再采集慢SQL接着检查关键参数是否异常最后判断整体风险等级生成巡检结论。每一步之间有前后依赖某些步骤的结果还会影响后续步骤走哪个分支。这就是Flow存在的意义。Flow把多个Skill按业务逻辑编排成一个完整流程Agent按照Flow的定义一步步执行而不是每次都由大模型临场发挥、自由决策。大模型自由发挥适合聊天但企业流程要的是确定性Flow就是用来约束确定性的。4.2 设计一个可落地的PolarDB巡检Flow我这次设计了一个三级巡检Flow覆盖了从采集到结论生成的完整链路。它的核心流程描述如下。流程启动后第一步是执行实例健康检查Skill确认目标实例的CPU、内存、连接数状态。如果实例本身已经异常直接跳到人工处理分支不再继续采集数据。如果实例正常进入第二步执行慢SQL扫描Skill拉取时间窗口内的慢SQL记录。拿到记录后进入规则判断节点如果慢SQL数量超过阈值自动触发SQL诊断Skill提取问题SQL的执行计划生成优化建议如果未超过阈值直接走常规分支。最后所有结果汇聚到一个报告生成Skill输出完整的巡检结论。这个Flow我建议用YAML格式定义因为它对运维同学更友好也方便在Git里做版本管理。核心结构大致长这样flow_id: polar_db_inspection_flow name: PolarDB例行巡检流程 triggers: - command: 巡检 - schedule: 0 9 * * * steps: - id: check_instance_health skill: polar_agent_express_instance_health on_success: next: scan_slow_sql on_failure: next: human_intervention - id: scan_slow_sql skill: polar_agent_express_slow_sql_scan output: slow_sql_list next: judge_slow_sql_count - id: judge_slow_sql_count type: condition expression: {slow_sql_list.length} 50 on_true: diagnose_problem_sql on_false: generate_report - id: diagnose_problem_sql skill: polar_agent_express_explain_analyze next: generate_report - id: generate_report skill: polar_agent_express_inspection_report - id: human_intervention type: notify operator: dba_oncall这里面的trigger定义很关键它决定了Flow怎么被启动。我配了两个触发方式一个是指令触发群里只要有人发“巡检”两个字Agent就会启动这个Flow另一个是定时触发每天早上9点自动跑一遍例行巡检。定时巡检这个能力在实际运维中非常实用相当于给团队配上了一个每天早上自动打卡上班的巡检机器人。4.3 Flow中的分支、循环与状态管理Flow编排不是把Skill顺序调用那么简单真实业务里还涉及条件分支、循环处理和跨步骤状态传递。条件分支上面已经用到了就是那个判断慢SQL数量的节点。OpenClaw的Flow引擎允许在步骤之间插入condition类型的节点通过表达式判断上一步的输出结果再决定走哪个分支。这里我建议表达式尽量简单不要写太复杂的逻辑复杂判断放到Skill脚本内部处理Flow只做清晰的分流。循环处理在批量场景下很常见。比如你有多个PolarDB实例要巡检不可能给每个实例写一个专属Flow。正确做法是Flow里配置一个实例清单然后用循环节点逐个执行巡检流程。我这次就配置了生产环境和测试环境两个实例组环境不同巡检参数也不同但Flow定义是同一套。状态管理方面Flow执行过程中产生的中间结果需要跨步骤传递。OpenClaw的Flow引擎提供了步骤输出缓存能力后置步骤可以通过变量引用的方式读取前置步骤的结果。我的习惯是每个步骤的输出都提供一个稳定ID比如check_instance_health输出实例状态对象后续步骤用{check_instance_health.status}就能访问。这就像流水线上的传送带每道工序在完成品上贴一个标签下一道工序认标签就能拿到自己需要的零件。4.4 错误处理与人工兜底企业Agent不能只报喜不报忧Flow跑得再顺也一定会遇到异常。数据库场景里网络抖动、权限失效、慢SQL查询超时都是家常便饭。所以我在Flow设计里特别安排了错误处理和人工兜底机制。错误处理分三层。第一层是Skill执行失败时自动重试通常重试一到两次间隔几秒适用于瞬时网络问题第二层是重试仍失败时走on_failure分支切换到降级操作比如拿不到某条实时指标就用静态配置数据顶上第三层是直接跳转到人工处理节点发通知给值班DBA让真人介入。人工兜底这个设计我认为是企业在用AI Agent时最容易忽略的一环。很多人觉得Agent越自动越好但在数据库这类高危场景里完全自动化的风险太大。我这次的做法是只读巡检全自动运行有变更风险的步骤一律进入“待确认”状态由Agent生成变更说明后推送给DBADBA在群里回复确认Agent再执行下一步。这样既有自动化效率又保留了人工审批的环节团队里的DBA也能接受这套方案。5. 常见问题与排查技巧实录这套方案上线之后我维护了一段时间前前后后遇到过不少问题。这里挑几个典型问题整理成速查表后面再展开说排查思路。现象可能原因解决方案OpenClaw提示无法确认WSL2环境could not safely verify the WSL2 environmentWSL2内核版本过旧或未启用systemd升级WSL2内核在.wslconfig中启用systemd重开终端Agent能发消息但收到消息后不回复消息回调地址配置异常或接收通道未完成绑定校验检查消息推送配置重新扫描绑定二维码完成校验Skill已放入目录但Agent始终不调用描述文件格式有误或描述内容未包含关键触发词检查YAML语法在描述中补充明确的触发场景说明Agent调用Skill时报参数错误参数类型定义不明确或Agent提取参数时混入无关文本严格指定参数类型给可选参数提供默认值Flow执行到condition节点后不继续表达式变量名与前置步骤输出ID不一致检查变量引用是否和步骤输出ID完全匹配数据库凭据出现在日志里配置项直接在Skill代码或参数中传递明文改为环境变量注入关闭敏感日志输出5.1 WSL2环境验证失败这个报错在开发阶段困扰了我一阵子。虽然在已选择Linux服务器后不需面对但我一开始在Windows上做验证时确实碰到过。根本原因是OpenClaw启动时会对WSL2做一次安全检查确保它能正常调用WSL里的命令和环境。如果你的WSL2内核版本太旧或者发行版系统没有启用systemd检查就会失败。解决办法是先打开PowerShell执行wsl --update更新WSL然后在用户目录下找到.wslconfig文件加上systemdtrue保存后执行wsl --shutdown重启WSL环境。重新进入WSL终端后再启动OpenClaw这个问题就能消除。5.2 Skill加载了但Agent就是不调用这种问题通常有三个原因。一个是描述文件里没有包含与用户需求匹配的触发词大模型感知不到这个Skill与当前问题的相关性另一个是描述文件YAML格式有误导致Skill解析失败虽然目录里有文件但Agent根本没加载进来还有一个是描述里的参数说明不完整Agent即使识别到需要调用也无法提取到完整的参数信息。我的排查顺序是先看启动日志确认Skill有没有加载成功再检查描述文件的YAML格式最后结合日志里Agent的思考过程看它有没有把这个问题和Skill关联起来。如果是触发词不够就在描述里增加更多同义表达。5.3 定时任务到点不执行排查发现是时区问题。服务器的默认时区如果不是Asia/Shanghai而Flow里配置的是9点执行实际触发时间会和你预期的差好几个小时。这个很隐蔽日志里又看不到明显报错。解决办法是在启动OpenClaw之前先统一服务器的时区设置。5.4 消息通道收发不对等网上也看到有人反馈“OpenClaw能发消息但微信发消息没回复”很有代表性。这个问题多半是消息通道回调地址没有正确配置。Agent主动发消息走的是出站通道而接收用户消息走的是入站回调两者是独立的。如果只配了出站没配上入站回调Agent就成了“只能打电话不能接电话”表现为消息发得出去但收不回来。解决方法是检查回调地址是否正确且公网可访问同时在应用管理后台完成回调校验。6. 全流程复盘与个人实践体会这次基于OpenClaw生态搭建PolarDB Agent Express的全过程走下来我最想强调的一点是企业级AI Agent的核心不在于模型能力有多强而在于结构化程度有多高。模型负责理解和生成语言但真正保证稳定输出的是精心设计的Skill和严格编排的Flow。你把每一个操作边界划清楚把每一条异常路径都设计好Agent才值得被放进生产环境而不是只能待在测试环境里陪你玩。另外一个体会是数据库这种运维场景安全始终是第一位的。AI能帮你省时间但它不能替你承担事故责任。所以我的建议是凡是涉及变更的权限不要全部交给Agent自由发挥适当保留人工审批节点这不是效率的退步而是企业落地的必要成本。团队里的DBA对这套系统信任度高了后续推广其他Agent场景才会顺利。这个实践后续还可以继续扩展。比如把OpenClaw接入n8n让它和更广泛的自动化工作流联动也可以结合多模态能力让Agent在巡检报告中自动生成趋势图表。我目前已经在规划的方向是把PolarDB实例的元数据同步到Flow的状态管理里让Agent在做容量评估时有更丰富的数据支撑。如果你也在做类似的企业Agent实践建议选一个具体的高频场景先跑通全链路不要一开始就铺太大面先把慢SQL巡检这类最成熟的需求落地再慢慢把更多操作纳入Agent的Skill体系里。