第二个验证场景是 SQL 分析。我输入分析 SELECT * FROM kes_mcp_demo.orders WHERE phone‘13800000001’ 的执行计划给 SELECT * FROM kes_mcp_demo.orders WHERE phone‘13800000001’ 推荐索引imageimageimage这里引入 MCP 的优势很明显。执行计划必须来自数据库不能让模型凭经验编。模型可以解释计划但计划本身要真实。索引建议也是一样只给草稿和判断不自动建索引。索引不是越多越好它会影响写入也会占空间还可能和已有索引重复。所以这里我希望 Agent 做的是初筛告诉我为什么建议、建议建在哪些列、上线前要复核什么。最后是否执行还是人工判断。我也会在这一段里强调索引建议不是最终结论。真正上线前还要看数据量、查询频率、写入压力和已有索引情况。Agent 可以帮我把方向找出来但不能替我做生产决策。这样写也更符合数据库工具的安全边界。健康检查和运维诊断#第三个验证场景是运维。相比查表和查数据我其实更关心这部分因为它更能体现 Agent 的连续排查能力。帮我看看数据库健康吗看下有没有慢 SQL当前数据库有没有锁等待定位谁阻塞谁刚才是不是有认证失败或者 FATALimageimageimageimage健康检查可以作为入口。如果连接正常但慢 SQL 很多就继续看 Top SQL如果发现锁等待就继续定位阻塞链如果只是权限不足也要明确告诉用户是工具采集受限而不是数据库本身有问题。锁等待这里我没有让 Agent 做危险动作。它可以告诉我谁阻塞了谁、相关 SQL 是什么、等待了多久但不会直接终止会话。终止会话这种操作必须人工判断因为有些阻塞可能是正常批处理有些可能是业务事务还没提交。健康检查、慢 SQL、锁等待这三个场景串起来以后就比较像一个小型运维助手了。它不是一次性解决所有问题但可以把第一轮排查的材料准备好。以前这些材料要自己去多个系统视图里找现在可以用一句话触发至少能节省不少定位时间。问题复盘#这次改造里有几个坑比较典型。第一个是 skills 太多。刚开始我把每个能力都拆成独立入口结果打开菜单以后像命令清单完全不像聊天助手。后来我把它收敛成 /database、/ops、/docs、/mcp、/report 这些场景入口体验才顺一点。第二个是 mcp 关键词误判。kes_mcp_demo.orders 这种名字很正常但如果路由只看 mcp就会误判成 MCP 状态检查。最开始我只是调整关键词判断顺序后来发现这还是不够最后改成 LLM 结构化意图识别再由本地 registry 映射到具体 skill 和 tool。第三个是自然语言查询只给 SQL 没执行。用户问“查一下 orders 前 5 条”Agent 却说“你可以执行下面这段 SQL”这就很不对。后来我改成由意图识别阶段生成 readonly_sql工具层再做只读校验。能执行的直接执行不能确定的再追问。第四个是模型返回的 JSON 不稳定。真实模型有时会把 object_type 返回成数组把 conditions 返回成字符串如果解析太严格就会直接降级成 /chat。后来我在 IntentEntity 里做了容错同时加了二次分类。像“直接看下表不就得了”这种口语输入第一次可能判不准第二次会要求模型从最接近的安全工具里选。尤其是自然语言查询只给 SQL、以及模型说要调用工具但 evidence log 里没有工具证据这两个问题实际体验非常差。用户明明想让工具帮忙查结果工具只是教用户怎么查或者只是口头承诺要查这就没有发挥 Agent 的价值。后来改成能安全执行就直接执行并且用终端脚本检查证据来源体验才好点。_emit_progress(progress, “intent_started”, “正在识别意图”)intent IntentClassifier(model).classify(…)_emit_progress(progress, “skill_selected”, f已识别 skill{selected_skill.name}{selected_skill.command}“)_emit_progress(progress, “tool_started”, f正在调用工具{selected_skill.tool}”)evidence self._collect_skill_evidence(selected_skill, message, intent)_emit_progress(progress, “tool_finished”, f工具采集完成{sources})_emit_progress(progress, “llm_started”, “正在调用模型总结”)
