场景举例: mysql数据库维护

早期方案1: prompt + webui

提供prompt提示词, 与 ai 交互后, 得到相关 sql, 然后手工执行;

优点: 稳健, 人工审核sql, 不暴露敏感信息;

缺点: 交互次数繁多, 每次都需要提供表结构等信息, 错误处理繁琐;

方案2: AI工具自动执行

如 openclaw, hermes, ClaudeCode 直接访问数据库, 主要通过 prompt 引导;

优点: 自动化程度高, 自动处理错误;

缺点: 风险高, 总担心误执行删库删表操作, 敏感信息泄漏;

方案3: AI工具+skills

提前在 skill 里面固定库表信息, 并固定常用业务操作语句或脚本, 并约束危险操作等;

优点:

• 自动化程度高
• 方便历史经验沉淀
• 团队共享方便

缺点

• skill 约束毕竟还是软约束, 还是存在风险
• 敏感信息

方案4: AI工具+MCP

即单独构建一个 mcp 程序, 由 ai 去调用接口来执行数据操作;

优点: 可以通过 mcp 工具内部进行约束和敏感信息脱敏

缺点: mcp 模式正在被淘汰，且交互控制和记忆不好处理

方案4: ai-agent

即单独开发一个 ai-agent, 由它来处理用户输入, 调模型接口, 操作数据库, 循环任务等；

类似 k8s的 operator 模式;

优点:

• 自动化程度高, 独立的调度器
• 灵活性更好
• 数据脱敏和权限控制可以在程序代码里面硬约束
• 历史可沉淀
• 状态管理和审计日志
• 可以对外暴露 API/CLI 供其他 AI 工具调用
• 扩展性好: 可以升级逻辑、加缓存、做性能优化，AI 侧无感知

缺点:

• 开发成本高
• 需要部署和运维一个额外的服务
• 业务变更后, 还需要同步升级agent程序
• 状态管理复杂

推荐方式

简单场景: 例如问个语法, 就直接 webui 或 ai 工具进行;

中等规模: Skill 内约束, 敏感操作二次确认; 或者只配置只读权限, 变更操作人工单独进行;

大规模: ai-agent 模式进行强约束; 而且有相关得日志便于审计;

附录

现在开发一个 ai-agent 也简单, 使用现成得框架, 如 LangGraph 也很方便;

我通过 ai 半个小时搞定一个 简易 agent;

技术栈:
python + LangGraph + pymysql + deepseek-v4-flash

主要流程

1. 获取输入
2. 内部工具获取指定表或相关表的表结构
3. 调用 llm 获取 ai 生成的 sql
4. 调用 llm 二次验证 sql
5. 执行 sql
6. 返回结果

错误处理

1. 如果 sql 验证失败, 则再次生成
2. 如果 sql 执行失败, 则将报错信息给到 ai, 再次生成->验证->执行;

验证和约束

1. 注意过滤 ‘delete drop update’ 等关键词, 需要二次验证;
2. LLM 生成的 SQL 有些是带 markdown 格式, 通过代码里面通过正则来清理
3. 工具的 docstring 描述要详细和清晰

输入图
输出图