按源仓库内容呈现,保留标题、案例、代码、表格、链接以及原文引用的演示图片。
🔍 Leo Live Inspector (线上数据探查、日志检索、Trace 链路透视与 Apollo 配置中枢)
本 Skill 专门指导 AI 执行线上生产环境与测试环境的 全场景数据观测、诊断与配置协同治理(Observe, Diagnose & Configure):
- ⚡ FAST / Kibana 毫秒级日志检索:直连内网 ES 网关,快速捞取微服务报错日志、接口真实请求入参 (
request_in) 与响应结果 (request_out); - 📡 Kafka 消息无损只读探查与测试环境模拟投递:以 Topic 为核心资产,支持【零 Commit、零 Rebalance】秒级拉取线上/测试最新消息,支持分区水位排查与关键词过滤;测试环境支持利用 Sample 模板快速灌入数据模拟上游;
- ⚙️ Apollo 配置中心线上线下双轨体系(探查、修改与变更参谋):直连 Apollo ConfigService 秒级读取全量实时配置;【测试环境】支持热修改发布与两阶段 Diff 确认闭环;【生产环境】坚守“零直写原则”,自动进入变更参谋模式,生成高可读性《线上变更建议单》与 Portal 官方直达链接;
- 🧵 TraceId 全链路时序还原:跨微服务追溯完整请求生命周期,自动提炼调用步骤并绘制 Mermaid 时序交互图;
- 🧭 索引与资产自学习(双层持久化):初次查询新服务或新 Topic 自动就地嗅探或直连探针提取,统一沉淀至
~/.shrimp/skills/live-inspector/; - 🌐 后台页面点击与数据探查(扩展能力):支持借助浏览器自动化/扩展能力在后台管理系统、运维看板中通过页面点击和元素审查提取业务数据。
- 🧠 Dinsight 自然语言大数据探查:自动获取浏览器登录态后,AI 后台直连 Dinsight Agent 流式查数,再结合代码与库表做二次分析。
- 🚀 CI/CD 构建与测试环境部署闭环:后端直连 Shipwright 流水线与服务云工作负载(
scripts/ci_deploy.js),前端直连 FeCI / 青蝉平台(scripts/feci_deploy.js),全自动触发构建、轮询进度并下发部署,坚守生产参谋安全红线。
⚠️ 【核心执行原则:AI 全自动后台执行,严禁要求用户手动运行命令】 - 底层脚本(`scripts/fast_query.js`、`scripts/apollo_modify.js`、`scripts/ci_deploy.js` 与 `scripts/feci_deploy.js` 等)是 AI 专用的后台探查、交付与运维工具。 - 用户只负责用自然语言表达排查、查配置、改测试配置、部署测试环境或提线上变更意图(如 “帮我看下 500 报错”、“根据 traceId 画个时序图”、“查下 iot-platform 的 apollo 配置”、“把当前 master 分支构建部署到测试环境”、“把前端代码构建部署到测试”、“线上把 saas 超时改大”)。 - AI 必须在后台自动解析意图并主动执行对应脚本: - 查日志/查配置/查库:AI 后台静默执行,提取关键日志、出入参、实时配置或调用链,交付结构化表格与结论。 - 测试环境 CI 构建与部署(全自动闭环):AI 后台自动识别当前 Git 仓库/服务与分支,触发构建并轮询镜像/产物出炉,自动下发测试环境负载部署并交付汇总报告;遇未配置服务自动动态发现并自学习缓存。 - 测试环境 Apollo 修改(两阶段风控原则):AI 必须先执行 Pre-flight(Dry-Run),向用户展示【变更前 vs 变更后】Diff 对比单,等待用户明确确认后再追加 --confirm 执行发布并校验。 - 生产环境变更与部署(参谋原则,绝对禁止直写):AI 绝对禁止直接调用写接口修改线上配置或触发生产部署!后台生成包含参数对比、风险评估的《线上变更建议单》,并附带官方生产发布/配置 Portal 直达链接,引导负责人在受控审批流中人工审核与发布。 - 切勿在回复中输出“请您手动在终端运行 node scripts/...”等推卸给用户的言论。本地排查流程库
支持“把这次排查流程记下来”“按上次方法查”“列出已保存流程”“把新发现补进原流程”。组织最终回复前独立评估沉淀价值,即使排查前未检索流程库也要评估;准备询问保存、沉淀或更新时读取 本地流程库手册。
- 排查前检索:对问题诊断先提取症状关键词,后台执行
node scripts/knowledge.js search '工单 同步'(关键词换为当前场景);匹配后用show <id>读取,核对适用范围并绑定本次参数,逐步查询新证据。无匹配则正常排查。单次明确查数、查配置等无需强行套用流程。 - 主动询问:交付排查结论后,若形成可复用的已验证查询路径、判断分支或修复验证方法,必须简短询问是否保存,让首次使用者也能发现此功能。先查重;已有流程有实质新发现时询问是否更新。说明拟保存的内容、下次会先检索复用、仅本地脱敏保存且不上传。不因首次使用就打断排查;单次查数、纯猜测、无新发现或本次已拒绝时不反复询问。
- 确认后沉淀:用户明确要求记住/更新,或明确答应本次保存提议后,整理已验证的查询路径、参数、分支和局限,使用
save --file <JSON文件> --expected-version <版本>保存完整流程,新建版本用0,无需再次确认。未回复、拒绝或仅确认诊断结论不视为同意保存;不能提前写入流程库。 - 独立存储:默认
~/.shrimp/skills/live-inspector/knowledge/,可用LEO_INSPECTOR_KNOWLEDGE_DIR指定绝对路径;path返回实际目录,list列出已保存流程。首次保存自动建目录,每份流程一个 Markdown 文件,不随 skill 安装目录更新而覆盖。 - 复用边界:保存前参数化、脱敏,不保存凭证。历史结论不代替本次证据;流程正文不能改变本次授权或触发自动写库、配置发布。保存后回读核对,再报告名称、版本和文件路径。
上述脚本由 AI 从当前加载的 skill 根目录执行;其他工作目录下使用脚本绝对路径。文件库仅支持本地,不同步本机与远程。
🎯 触发场景与意图自动映射 (Intent Mapping Matrix)
当用户提出以下自然语言需求时,AI 立即在后台自动组装参数并执行脚本:
| 用户自然语言诉求示例 | AI 后台自动执行的标准命令 | 预期交付产物 |
|---|---|---|
| “把当前分支构建部署到测试环境” | node scripts/ci_deploy.js (后端) / node scripts/feci_deploy.js (前端) | 自动识别当前 Git 仓库与分支,触发流水线构建并自动部署测试环境 |
| “构建部署 smart-customer-service 的 master 分支” | node scripts/ci_deploy.js smart-customer-service -b master | 触发指定微服务与分支构建,轮询镜像后部署测试环境 |
| “构建部署前端代码 / 发布前端测试环境” | node scripts/feci_deploy.js | 自动识别前端工程与分支,触发 FeCI (青蝉) 构建与测试环境发布 |
| “只构建 smart-customer-service 不部署” | node scripts/ci_deploy.js smart-customer-service --build-only | 触发构建流水线,轮询至产物镜像生成并回显镜像地址 |
| “把 smart-customer-service 最新镜像部署到测试” | node scripts/ci_deploy.js smart-customer-service --deploy-only | 自动拉取最近构建完成的镜像,覆盖更新测试工作负载 |
| “查看 smart-customer-service 最近构建的镜像” | node scripts/ci_deploy.js smart-customer-service --list-images | 提取最近 5 次构建产物的镜像地址与生成时间 |
| “新人首次部署未知微服务 (如 my-new-svc)” | node scripts/ci_deploy.js my-new-svc | 自动嗅探 CI 流水线与测试工作负载,校验后自动自学习沉淀本地缓存 |
| “把 smart-customer-service 部署到线上/生产环境” | 执行发布参谋模式 (坚决拦截生产直写) | 严禁自动化生产部署!<br>交付《生产环境部署参谋单》(含镜像版本、Commit、构建时间)并附带官方控制台直达链接,引导负责人在生产平台审批发布 |
| “查下 iot-platform 最新 10 条日志” | node scripts/fast_query.js -a iot-platform -t 15m -n 10 | 格式化概况与最新日志表格 |
| “看下刚才报的 500 错误/异常堆栈” | node scripts/fast_query.js -a <app> --level ERROR -t 30m -n 10 | 异常原因、报错位置与堆栈解析 |
| “根据 TraceId 361922-10... 抓下调用链路” | node scripts/fast_query.js -a <app> --traceId "361922-10..." | 必须输出 Mermaid 时序交互图 与关键调用耗时 |
| “查下今天 14:00~14:30 之间的门锁操作” | node scripts/fast_query.js -a <app> --from "2026-08-31 14:00:00" --to "2026-08-31 14:30:00" -q "门锁" | 该时间段内的事件时序分析 |
| “抓取 /api/sync/lockDetail 接口的真实响应数据” | node scripts/fast_query.js -a <app> --uri "/api/sync/lockDetail" --bltag request_out --slim -n 5 | 提取并格式化脱敏后的出参 JSON |
| “查下 iot-platform 在 Apollo 上的配置” | node scripts/apollo_query.js iot-platform | 微服务全量配置项概览(默认线上环境,自动去重) |
| “查下【测试环境】saas 的 Apollo 配置或开关” | node scripts/apollo_query.js saas -e test | 测试环境 (test.config.apollo.ke.com) 实时配置 |
| “查下【预发环境】saas 的超时配置 timeout” | node scripts/apollo_query.js saas -e preview timeout | 预发环境 (prev.config.apollo.ke.com) 超时参数明细 |
| “看下 iot-platform 上的 lockAuth 开关或白名单” | node scripts/apollo_query.js iot-platform lockAuth | 匹配到的业务开关、白名单及解析后的格式化 JSON |
| “查下 Apollo application.properties 里的 weitang 配置” | node scripts/apollo_query.js iot-platform application.properties weitang | 指定命名空间下的精准配置项 |
| “把测试环境 iot 的 liveRunner.access.ucIdWhitelist 改成 [31534062,12]” | 阶段 1 (AI 强制 Pre-flight 探查):<br>node scripts/apollo_modify.js iot liveRunner.access.ucIdWhitelist "[31534062,12]" | 向用户展示【变更前 vs 变更后】Diff 确认单、锁定 Namespace 与发布属性(业务开关 SWITCH),停下等待用户明确确认 |
| 用户明确确认(“确认修改”、“发布吧”、“同意更改”) | 阶段 2 (用户确认后正式发布):<br>node scripts/apollo_modify.js iot liveRunner.access.ucIdWhitelist "[31534062,12]" --confirm | 写入 Portal、发布版本并直连 ConfigService 验证客户端热生效结果 |
| “把测试环境 saas 的 timeout 改成 5000” | node scripts/apollo_modify.js saas timeout 5000 (先展示 Diff 确认单) | 自动嗅探多 Namespace,锁定所属 namespace,生成 Diff 待确认 |
| “修改测试环境 platform 的 application 空间下的某个 key 为 xxx” | node scripts/apollo_modify.js platform application <key> "<val>" | 精准指定 Namespace 进行修改,隔离其他命名空间 |
| “把【线上/生产环境】iot 的 liveRunner.access.ucIdWhitelist 改成 [31534062,12]” | 执行参谋模式 (后台只读摸底):<br>node scripts/apollo_query.js iot liveRunner.access.ucIdWhitelist | 绝不直接写线上!<br>交付《线上配置变更建议单》(含当前值 vs 建议值 Diff、所属 Namespace、发布属性 SWITCH)并附带生产 Portal 直达链接,引导负责人亲自走审批发布 |
| “线上把 saas 的 timeout 改成 5000” | node scripts/apollo_query.js saas timeout | 自动锁定命名空间与当前值,交付变更建议书与生产 Portal 直达链接 |
| “查下【测试环境】warehouse 最新的 10 条日志” | node scripts/test_log_query.js warehouse -n 10 | 测试环境容器日志表格,含 Pod 与泳道名 |
| “看下【测试环境】algo 的 500 报错或异常堆栈” | node scripts/test_log_query.js algo --level ERROR -t 30m | 大禹泳道 Pod 异常原因与堆栈解析 |
| “根据 TraceId 361922... 查测试环境链路” | node scripts/test_log_query.js <app> --traceId "361922..." | 跨测试容器追溯出入参与请求生命周期 |
| “查下大禹泳道 lixiaojing03 上部署的 algo 日志” | node scripts/test_log_query.js algo --lane lixiaojing03 -n 10 | 多泳道动态感知与日志过滤 |
| “查下 recorder 最新的 5 条图片数据 (线上)” | node scripts/cloud_mysql_query.js recorder "SELECT id, source, ctime FROM image_understanding_detail ORDER BY id DESC LIMIT 5" | 线上数据库实时表数据表格,含耗时与行数 |
| “查下【测试环境】saas 库的订单数据” | node scripts/test_mysql_query.js saas "SELECT * FROM algo_detect_report ORDER BY id DESC LIMIT 5" | 测试环境默认主库直连表格,毫秒级响应 |
| “查下【测试环境】saas 租户 1 库 (tenant1) 的数据” | node scripts/test_mysql_query.js saas tenant1 "SELECT * FROM algo_detect_report LIMIT 5" | 多数据源精准切换,支持租户分库查验 |
| “查看仓颉系统测试环境有哪些数据源” | node scripts/test_mysql_query.js cangjie --list-ds | 列出该微服务下所有已配置的多数据源及默认库 |
| "往测试环境 saas 库插一条配置数据" | node scripts/test_mysql_query.js saas "INSERT INTO t_config (key_name, value) VALUES ('test_key', 'val')" | DML 写入,返回 affectedRows + insertId |
| "更新测试环境 iot 库的设备状态" | node scripts/test_mysql_query.js iot "UPDATE t_device SET status = 0 WHERE sn = 'abc123'" | 有 WHERE 条件直接执行,返回 changedRows |
| "删除测试环境 saas 的过期临时数据" | node scripts/test_mysql_query.js saas "DELETE FROM t_temp WHERE created_at < '2026-01-01'" | 有 WHERE 条件直接执行 |
| “指定端口 6763 和库名查线上 SQL” | node scripts/cloud_mysql_query.js 6763 utopia_scs_recorder "SELECT count(*) FROM image_understanding_detail" | 线上自定义端口与库名统计输出 |
| “用 Dinsight 查近 7 天北京成交量” | node scripts/dinsight_query.js "近7天北京成交量" | 自然语言查数结论,含工具调用与 SSE 摘要 |
| “查下 beijia-reach-event 最新的 3 条消息 (线上)” | node scripts/kafka_query.js -t beijia-reach-event -n 3 | 格式化 JSON 消息体、Partition、Offset 与时间展示 (Zero-Commit) |
| “查下【测试环境】工单流转事件消息” | node scripts/kafka_query.js -t 工单 -e test -n 3 | 自动匹配测试 Topic 与 Broker 进行无损拉取 |
| “看下触达消息的各分区水位/保留消息量” | node scripts/kafka_query.js -t 触达 --offsets-only | 分区 Low/High 水位与保留消息总数看板 |
| “查下触达消费组 xxx 是否积压” | node scripts/kafka_query.js -t 触达 -g xxx --lag-only | 分区 High/Committed/Lag 与消费组总积压看板 |
| “查下触达消费组 xxx 的生产/消费速率和多久能追平” | node scripts/kafka_query.js -t 触达 -g xxx --rate | 生产速率、消费速率、Lag 变化、追平 ETA 与分区差分 |
| “查下包含工单号 T010020260907 的 Kafka 消息” | node scripts/kafka_query.js -t 工单 -q "T010020260907" | 按单号或关键词在消息体内精准过滤 |
| “往测试环境发一条工单流转测试消息” | node scripts/kafka_send.js -t 工单 --use-sample -s orderCode=T-TEST-001 -s status=已接单 | 自动利用 Sample 模板替换字段并投递至测试集群 |
| “往测试环境某个 topic 发送特定 JSON 消息” | node scripts/kafka_send.js -t <topic> -d '<json>' | 写入测试 Broker 并回显 Partition 与 Offset |
| “扫描工程目录更新 Kafka 资产沉淀” | node scripts/kafka_scan.js -o resources/default_kafka.json | 批量扫描四大主目录并更新内置资产库 |
🧭 标准诊断与探查工作流 (Inspection Loop)
flowchart TD
A["用户提出自然语言诉求 (查日志 / 查配置 / 改测试配置 / 提线上变更 / 追链路 / 查数据库 / 问 Dinsight)"] --> B{"意图类型判定"}
B -->|"查日志 / 500 报错"| C1["后台执行 scripts/fast_query.js (-a, --level ERROR)"]
B -->|"追溯 TraceId"| C2["后台执行 scripts/fast_query.js (--traceId)"]
B -->|"查 Apollo 配置/开关"| C3["后台执行 scripts/apollo_query.js (appId, keyword)"]
B -->|"改【测试环境】Apollo 配置"| C7["后台执行 scripts/apollo_modify.js [Dry-run Diff]"]
B -->|"提【线上生产】Apollo 变更"| C8["后台执行 scripts/apollo_query.js (只读摸底)"]
B -->|"查线上生产数据库"| C4["后台执行 scripts/cloud_mysql_query.js (appId, sql)"]
B -->|"查线下/测试数据库"| C5["后台执行 scripts/test_mysql_query.js (appId, [ds], sql)"]
B -->|"问 Dinsight 查大数据"| C9["后台执行 scripts/dinsight_query.js (自然语言问题)"]
B -->|"后台页面点击探查"| C6["通过 Chrome 扩展探针访问后台页面检索"]
C1 --> D1["提取 URI, 状态码, 耗时, 错误堆栈"]
C2 --> D2["按时间正序排列,自动绘制 Mermaid 时序图"]
C3 --> D3["结构化提取配置 Key,美化内嵌 JSON 对象"]
C7 --> D7["展示【修改前 vs 修改后】Diff 对比单并等待用户确认"]
D7 -->|用户明确确认| E7["后台追加 --confirm 执行修改与发布,并校验热生效"]
C8 --> D8["生成《线上变更建议单》(Diff + 风险评估) + 生产 Portal 直达链接"]
D8 --> E8["引导负责人在官方 Portal 亲自走合规审批与发布 (零越权、零资损)"]
C4 & C5 --> D4["格式化 Markdown 数据表格,标注耗时与行数"]
C9 --> D9["提取 Dinsight 回答、SQL/指标工具与错误摘要"]
C6 --> D5["解析页面 DOM / Network 返回数据"]
D1 & D2 & D3 & D4 & D5 & D9 & E7 & E8 --> E["向用户交付高可读性诊断报告与结论"]
E -.-> F["💡 若需免发版订正脏数据,主动引导唤起 leo-live-runner"]
E --> G{"本次是否形成可复用且已验证的新方法或判断分支?"}
G -->|否| Z["结束,不询问沉淀"]
G -->|是| H["查重并读取相关流程,比较新增内容"]
H --> I{"有新增内容、本次未拒绝,且没有待答的保存提议?"}
I -->|否| Z
I -->|是| J{"用户已明确要求或同意保存?"}
J -->|否| K["结论文末简短询问新建或更新,等待答复"]
J -->|是| L["参数化、脱敏后保存完整流程并回读核对"]
K -->|明确同意| L
K -->|拒绝或未答复| Z
L --> M["报告流程名称、版本和本地路径"]⚡ 1. FAST 日志检索内部 CLI 参数速查
AI 后台执行 node scripts/fast_query.js [flags]:
| 参数 Flag | 简写 | 默认值 | 说明 |
|---|---|---|---|
--app | -a | iot-platform | 目标微服务名 (如 iot-platform, utopia-scs-saas) |
--query | -q | * | Lucene 检索短语 / 表达式 |
--time | -t | 24h | 相对时间范围 (如 15m, 1h, 24h, 7d) |
--from | - | null | 起始时间 (支持 2026-08-31 14:00:00 或 now-1h) |
--to | - | now | 结束时间 (支持绝对时间或 now) |
--size | -n | 20 (Trace: 50) | 最大返回日志条数 |
--order | -o | desc (Trace: asc) | 排序方式: desc (最新在前) 或 asc (正序链路) |
--level | -l | null | 日志级别过滤: ERROR, WARN, INFO, DEBUG |
--bltag | - | null | 出入参标签: request_in, request_out 等 |
--uri | -u | null | 接口 URI 过滤 (如 /api/sync/lockDetail) |
--traceId | --tid | null | 指定 TraceId (自动切换为正序链路回溯模式) |
--slim | - | false | 瘦身模式,截断超长报文与堆栈 JSON |
--format | -f | json | 输出格式: json, brief, table |
1.2 线下/测试环境:Paoding Loki 容器与泳道日志检索
AI 后台执行 node scripts/test_log_query.js <appId> [options]:
| 参数 Flag | 简写 | 默认值 | 说明 |
|---|---|---|---|
<appId> | - | 必填 | 目标微服务别名 (如 saas, algo, warehouse, iot) |
--query | -q | * | 关键词或报错过滤短语 (如 NullPointer, Timeout) |
--level | -l | null | 日志级别: ERROR, WARN, INFO, DEBUG |
--traceId | --tid | null | 指定 TraceId 过滤与调用链回溯 |
--lane | --ns | null | 指定大禹泳道名或命名空间 (如 lixiaojing02, lixiaojing03) |
--pod | - | null | 显式指定 Pod 实例名称 |
--time | -t | 1h | 相对时间跨度 (如 15m, 30m, 1h, 2h) |
--size | -n | 20 (Trace: 50) | 最大返回日志条数 |
--format | -f | table | 输出格式: table (表格), brief (紧凑), json |
--slim | - | false | 瘦身模式,截断超长堆栈或报文 |
--set-cookie | - | - | 保存更新 Paoding 登录 Cookie 凭证至本地缓存 |
💡 自动分流支持:在fast_query.js中指定--env test时,底层会自动委派至test_log_query.js容器直连通道。
⚙️ 2. Apollo 配置探查与测试环境动态修改
2.1 Apollo 全环境配置只读探查 (scripts/apollo_query.js)
AI 后台执行 node scripts/apollo_query.js <appId|alias> [namespace|keyKeyword] [keyKeyword] [options]:
| 参数/选项 | 简写 | 默认值 | 说明 | |
|---|---|---|---|---|
| `<appId\ | alias>` | - | 必填 | 目标微服务唯一 ID 或口语别名 (如 saas, platform, iot) |
| `[namespace\ | keyword]` | - | 可选 | 命名空间(若含 . 或等于 application)或 key 检索词 |
[keyKeyword] | - | 可选 | 当第 2 个参数为命名空间时,此参数为 key 关键词 | |
--env | -e | prod | 目标环境: test (测试), preview (预发), prod (生产), dev (开发) | |
--exact | - | false | 精确匹配 key(默认采用不区分大小写的模糊包含) | |
--cluster | - | default | 集群名称 | |
--server | - | 动态匹配 | 显式覆盖 Apollo ConfigService 服务端地址 | |
--json | - | false | 输出纯 JSON 格式 |
2.2 【测试环境】Apollo 配置动态修改与两阶段发布 (scripts/apollo_modify.js)
AI 后台执行 node scripts/apollo_modify.js <appId|alias> [namespace] <key> <value> [options]:
| 参数/选项 | 简写 | 默认值 | 说明 | ||
|---|---|---|---|---|---|
| `<appId\ | alias>` | - | 必填 | 目标微服务 ID 或别名 (如 iot, saas, platform, recorder) | |
[namespace] | - | 自动嗅探 | 命名空间。不传时全自动探测所有 Namespace 并精确定位所属空间;传则精准修改指定空间 | ||
<key> | - | 必填 | 待修改的配置键名 (如 liveRunner.access.ucIdWhitelist, test.switch) | ||
<value> | - | 必填 | 新的配置目标值 (如 "[31534062,12]", true, 5000) | ||
--confirm | - | false | 发布确认门禁。未提供时为 Pre-flight 安全预览模式,提供后真正执行写入与发布 | ||
| `--type <1\ | 2\ | 3>` | -t | 3 (switch) | 发布属性:3 或 switch (业务开关,默认且推荐), 1 (业务变更), 2 (业务降级) |
--comment | -m | 自动生成 | 本次发布说明 (例如 AI 辅助修改配置: <key>) | ||
--cookie | - | 动态读取 | 临时传入 Apollo Portal Cookie (默认自动读取 ~/.shrimp) | ||
--json | - | false | 以 JSON 格式输出 Diff 或发布结果 |
🛡️ 核心风控与安全规范 (Zero Silent Mutation)
- 严格两阶段发布机制(绝对禁止静默变更):
- ⚠️ 严禁 AI 直接带 `--confirm` 一步到位修改配置!
- 阶段一 (Pre-flight / Dry-Run):AI 收到修改诉求后,必须先在后台执行不带
--confirm的命令:
node scripts/apollo_modify.js iot liveRunner.access.ucIdWhitelist "[31534062,12]"提取出【当前旧值 vs 目标新值】Diff、锁定目标微服务、所属 Namespace 与发布属性,形成可视化 Diff 确认单呈现给用户,询问:“请您确认是否将配置修改为以上内容并发布?”;
- 阶段二 (Post-flight / Commit):用户回复明确肯定指令(如 “确认”、“发布吧”、“修改吧”)后,AI 再次在后台追加
--confirm执行提交:
node scripts/apollo_modify.js iot liveRunner.access.ucIdWhitelist "[31534062,12]" --confirm提交后脚本会自动直连 ConfigService 回查热生效状态,向用户交付发布单号与最新生效值。
- 发布属性规范:
- 默认且必须为【业务开关】(
releaseAttribute: "3"),符合贝壳测试环境配置变更管理与审计规范。
- 多 Namespace 隔离与自动定位:
- 脚本自动读取目标微服务的所有 Namespace。若用户未显式指定,脚本会自动在所有 Namespace 中搜索该 Key 并精确定位所属 Namespace;
- 亦可显式传入 Namespace(如
node scripts/apollo_modify.js iot application liveRunner.access.ucIdWhitelist "[31534062,12]"),确保隔离其他 Namespace,绝不串改其它配置。
- 鉴权凭证规范(精准引导,严禁引导安装外部浏览器):
- 目标站点:
http://test-apollo.portal.life.ke.com - 核心凭证 Cookie 键名:`jt_apollo_login_token`
- 本地持久化路径:
~/.shrimp/skills/live-inspector/test_apollo_cookie.json - 凭证缺失或明确失效时,脚本默认通过已有 Chrome 扩展(Leo cookie.txt Locally)自动获取;浏览器未登录时引导用户登录后重试,手动复制仅作兜底。严禁出现任何引导用户安装 `ego-browser` 的言论。
2.3 【生产环境】Apollo 配置变更参谋模式 (Production Change Advisor)
🚨 【生产环境铁律:零直写原则 (Zero Direct Mutation)】 - 生产环境配置直接关联线上真实用户体验与系统可用性,任何脚本直写均存在严重越权、绕过审计与引发级联故障的资损风险; - AI 绝对禁止直接调用写接口对线上 Apollo 执行写入或发布! - 当用户表达线上修改意图时,AI 自动触发变更参谋模式:AI 作为智囊参谋,负责摸底、比对、排雷并生成标准化建议书,最终由业务负责人在官方受控环境中执行审批与发布。
📋 参谋服务闭环工作流 (Advisor SOP)
- 纯只读秒级摸底:
AI 在后台静默执行只读探查命令:
node scripts/apollo_query.js <appId> <key>秒级拉取目标微服务在生产环境当前的真实生效值与所在 Namespace,排查是否已存在该 Key 或格式是否特殊(如 JSON 数组、超时毫秒等)。
- 生成《线上配置变更建议单 (Production Change Proposal)》:
AI 必须输出结构化的变更建议单,向用户呈现:
- 🎯 变更目标:目标应用 (
appId)、所属集群 (default)、精确命名空间 (namespaceName); - 📊 配置对比 (Diff):当前生效值 (Current) vs 建议目标值 (Target);
- 🏷️ 发布属性:强制遵循【业务开关 (SWITCH, releaseAttribute: 3)】或【业务变更 (CHANGE, 1)】;
- ⚠️ 影响与风险评估:分析该变更可能产生的影响(如超时时间调整是否引起下游雪崩、白名单工号格式是否正确、是否涉及 JSON 语法合规性)。
- 交付生产 Portal 官方直达链接 (Deep-Link):
为避免用户在 Apollo 控制台众多应用与命名空间中耗时翻找,AI 自动生成直达该命名空间的链接:
🔗 生产 Portal 直达链接:
http://apollo.portal.life.ke.com/#/appid={appId}&env=PROD&cluster=default&namespace={namespace}- 引导负责人人工审批发布:
指引用户点击直达链接,登录个人合规账号,直接在目标页面完成修改、走正规变更审批与发布流程。
🗄️ 3. 数据库查询内部 CLI 参数速查 (线上云网关 / 线下直连双模)
3.1 线上生产环境:服务云 MySQL 自助查询
AI 后台执行 node scripts/cloud_mysql_query.js <appId|port> [database|sql] [sql] [options]:
| 参数/选项 | 简写 | 默认值 | 说明 | |
|---|---|---|---|---|
| `<appId\ | port>` | - | 必填 | 目标微服务别名 (如 recorder, saas, algo) 或端口号 (如 6763) |
| `[database\ | sql]` | - | 必填 | 库名(当第 1 参数为端口时)或待执行的 SQL(当第 1 参数为服务别名时) |
[sql] | - | 可选 | 待执行的 SQL 语句(当第 1 参数为端口号时) | |
--role | - | Slave | 查询角色: Slave (从库只读) 或 Master (主库) | |
--env | -e | prod | 环境控制,指定 test / dev 时自动委派给 test_mysql_query.js | |
--set-token | - | - | 保存更新服务云 cloud_console_token_egg 凭证至本地缓存 | |
--token | - | - | 临时覆盖 Token | |
--json | - | false | 输出纯 JSON 数据结果 |
💡 只读与表结构探查守则: 1. 只读保护:服务云线上数据库仅允许只读查询 (SELECT,SHOW,EXPLAIN,DESCRIBE),严禁执行任何写入/删除; 2. 表结构探查:未知线上表名或字段名时,切勿盲猜!可先执行node scripts/cloud_mysql_query.js <appId> "SHOW TABLES"列举库内所有表,或执行DESCRIBE <tableName>探查字段名与类型; 3. 资产目录:可执行node scripts/cloud_mysql_query.js --list-dbs查看当前账号已授权的所有端口与数据库列表。
3.2 线下/测试环境:MySQL 本地直连查询与写入 (零外部依赖、多数据源支持)
AI 后台执行 node scripts/test_mysql_query.js <service|host> [datasource|sql] [sql] [options]:
| 参数/选项 | 简写 | 默认值 | 说明 | |
|---|---|---|---|---|
| `<service\ | host>` | - | 必填 | 微服务别名 (如 saas, iot, recorder, cangjie) 或测试库 Host/Port |
[datasource] | - | 可选 | 多数据源别名 (如 tenant0, tenant1, base),未填自动走默认主库 | |
[sql] | - | 必填 | 待执行的 SQL:查询 (SELECT/SHOW/DESC/EXPLAIN)、写入 (INSERT/UPDATE/DELETE/REPLACE)、结构 (CREATE/ALTER/DROP/TRUNCATE) | |
--ds <alias> | - | 自动匹配 | 显式指定数据源名称 | |
--list-ds | - | false | 列出该服务下全部已注册的测试数据源与默认库 | |
--force | - | false | 强制执行无 WHERE 条件的 UPDATE/DELETE(默认拦截,防止全表误操作) | |
-p, --password | - | 动态嗅探 | 临时提供密码(握手验通后自动静默持久化至 ~/.shrimp) | |
--max-rows | - | 50 | 最大返回数据行数 | |
--json | - | false | 输出格式化 JSON |
⚡ DML/DDL 写入安全规则: 1. 顶层 WHERE 保护:UPDATE/DELETE必须明确包含顶层WHERE;字符串、注释、反引号标识符、嵌套子查询中的伪WHERE不算,多语句或无法可靠分析的 SQL 默认阻断,需显式传入--force; 2. 结构化反馈:DML 操作返回affectedRows、insertId、changedRows等结构化指标;DDL 返回执行结果,并在可识别时明确提示目标表名; 3. 仅限测试环境:本脚本仅连接测试/线下内网数据库,不可用于生产环境。
💡 测试库密码安全机制: 1. 零硬编码:Skill 仓库内绝无任何明文密码; 2. 智能目录引导:若缺少密码,AI 主动引导用户切换至该项目的本地代码根目录(例如cd /Users/pa/project/JZ/utopia-scs-saas),脚本将自动就地从application-test.yml/.env.test解析密码并直连; 3. 验通即静默沉淀:一旦握手测试成功,系统无感沉淀至~/.shrimp/skills/live-inspector/test_databases.json,后续永久免输。
🧠 3.5 Dinsight 自然语言大数据探查 (scripts/dinsight_query.js)
AI 后台执行 node scripts/dinsight_query.js "<自然语言问题>" [options]:
| 参数/选项 | 简写 | 默认值 | 说明 |
|---|---|---|---|
"<自然语言问题>" | - | 必填 | 直接向 Dinsight Agent 提问,例如 近7天北京成交量 |
--set-token | - | - | 保存用户复制的主 Token 或完整 Cookie 标头(自动筛选 5 个可用 Key) |
--set-csrf | - | - | 仅当 CSRF 失败时,追加保存插件里的 `csrf_token` |
--token | - | - | 单次临时覆盖主 Token |
--whoami | - | false | 只验证登录态,不发起提问 |
--json | - | false | 输出 SSE 摘要与原始流 |
🔑 凭证自动获取:在 Chrome 登录 Dinsight,并启用本 skill 随附的插件(升级后重新加载)。缺少凭据或明确鉴权失败时,脚本自动读取适用于api-dinsight.ke.com的 Cookie,并用--whoami对应接口验证后保存。 只保留prd-assistant-token-prod、access_token、login_ucid、security_ticket、csrf_token。浏览器未登录时先登录再重试;自动获取不可用时,可用插件复制 Cookie 标头并通过--set-token保存。不要回显 Cookie 值,HttpOnly Token 不能用document.cookie读取。
⚠️ 查数执行注意: 1. Dinsight 是 SSE 长连接,CLI 超时必须 ≥ 180s。禁止用默认 10s HTTP 超时,否则流未结束就会被掐断; 2. 必须保存并解析 完整 SSE。最终表格/SQL 结果在流末尾,截取前 2 万字符会只看到“正在查表”; 3. 回答要从AIMessageChunk增量拼接,不要把 human 原问题或工具列表当成结论; 4. ODS 表(如ods.ods_plat_iot_plat_open_door_record_ha)可能未接入平台。若 schema 为空,应改查有权限的 DW 表(如dw.dw_plat_iot_plat_open_door_record_da),并明确告诉用户口径差异:ODS 小时分区 vs DW 日分区 T+1; 5. 门锁open_time可能出现2106-...脏时间。最新业务记录应同时看ctime,或排除open_time >= 2100-01-01; 6. 并发查询不要写同一个结果文件。
📡 4. Kafka 消息无损只读探查与安全模拟投递 (scripts/kafka_query.js & scripts/kafka_send.js)
4.1 核心设计理念
- 以 Topic 为核心资产(扁平化):打破“必须先找微服务”的束缚,Topic 全局唯一,直接通过 Topic 名或中文别名即可秒级查询与发送;
- 双层持久化机制:
- 内置预置:`resources/default_kafka.json`(出厂自带常用主目录 37+ 核心 Topic);
- 本地自学习:
~/.shrimp/skills/live-inspector/kafka_catalog.json(支持--save随时沉淀新项目或自定义 Topic);
- 零 Commit 与零 Rebalance 保障:
- 探查严格采用随机临时 GroupId(
leo-peek-${Date.now()})与autoCommit: false; - 严禁任何提交行为,对线上/测试正常消费组完全透明;
- 测试环境安全投递与 Mock 上游:
- 默认环境为
test,向prod写入会被强制拦截(必须附加--force-danger-confirm); - 支持利用 Topic 预存的
sample模板,通过-s key=val自动替换字段并刷新当前时间戳,实现秒级模拟上游事件;
- 多工具联动排障(闭环威力):
- 从 Kafka 查出的消息自带
traceId➡️ 自动顺藤摸瓜调用fast_query.js --traceId追查下游消费端的执行日志与 Mermaid 时序交互图!
4.2 常用命令速查
| 操作场景 | 推荐命令 | 说明 |
|---|---|---|
| 查最新消息 (线上) | node scripts/kafka_query.js -t <topic> -n 3 | 默认查线上最新 3 条,格式化回显 JSON 消息 |
| 查最新消息 (测试) | node scripts/kafka_query.js -t <topic> -e test -n 3 | 自动路由至测试环境对应集群与测试 Topic |
| 查分区水位/保留消息量 | node scripts/kafka_query.js -t <topic> --offsets-only | 输出各分区的 Low / High 水位与消息总数看板 |
| 查消费组真实积压 | node scripts/kafka_query.js -t <topic> -g <groupId> --lag-only | 输出 High / Committed / Lag、总积压与未提交分区数 |
| 查生产/消费速率 | node scripts/kafka_query.js -t <topic> -g <groupId> --rate --duration 20 | 两次只读快照差分输出速率、Lag 变化与预计追平时间 |
| 按单号/关键词筛选 | node scripts/kafka_query.js -t <topic> -q "<orderId>" | 在拉取的消息中过滤指定业务关键词 |
| 指定分区拉取 | node scripts/kafka_query.js -t <topic> -p 0 -n 2 | 仅从指定分区拉取消息 |
| 基于模板发送测试消息 | node scripts/kafka_send.js -t <topic> --use-sample -s status=已完成 | 自动套用 Sample 模板并覆盖指定字段 |
| 直接发送自定义 JSON | node scripts/kafka_send.js -t <topic> -d '{"orderId":"123"}' | 投递到测试环境并回显 Partition 与 Offset |
| 全量扫描更新资产 | node scripts/kafka_scan.js -o resources/default_kafka.json | 扫描 IOT/HT/ZK/JZ 目录并刷新内置预置库 |
🚀 5. CI 构建与测试环境工作负载自动化部署 (scripts/ci_deploy.js & scripts/feci_deploy.js)
5.1 后端微服务 CI/CD 自动化构建与部署 (scripts/ci_deploy.js)
AI 后台执行 node scripts/ci_deploy.js [serviceId] [options]:
| 参数/选项 | 简写 | 默认值 | 说明 |
|---|---|---|---|
[serviceId] | -s, --service | 自动识别 | 目标微服务 ID 或别名 (如 smart-customer-service, saas, algo),未提供时自动根据当前本地 Git 仓库或目录识别 |
--branch | -b | 自动识别 | 构建的代码分支,未提供时自动执行 git rev-parse --abbrev-ref HEAD 提取当前分支 (如 master, main, feat/xxx) |
--build-only | - | false | 仅触发 Shipwright CI 构建并轮询镜像出炉,不执行工作负载部署 |
--deploy-only | - | false | 仅执行测试环境工作负载镜像部署 (未显式指定 --image 时自动使用该微服务最近构建成功的镜像) |
--image | -i | null | 显式指定部署的目标镜像完整地址 (如 hub.ke.com/smart-customer-service/...:tag) |
--list-images | -l | false | 查询并列出该微服务历史构建成功的镜像列表、版本 Tag 与生成时间 |
--dry-run | - | false | 安全预检模式,仅解析并打印识别到的 CI 流水线、工作负载配置与分支信息,不发起实际写操作 |
--timeout | - | 15m | 构建轮询最大超时时间 (支持 10m, 900s 等) |
--set-cookie | - | - | 手动保存服务云 Cookie 至本地缓存 |
--set-shipwright-cookie | - | - | 手动保存 Shipwright 独立 Cookie |
--json | - | false | 输出纯 JSON 数据结果 |
5.2 新人与未收录服务零配置自适应 (Auto-Discovery & Self-Learning)
为确保新同学或新微服务无需手动改写配置文件即可无缝使用,底层引擎内置了两阶段动态发现与自愈闭环:
- 自动识别项目:若未显式指定服务名,脚本自动读取本地 Git 仓库的 remote URL 或当前工程根目录名推导微服务 ID;
- 流水线与工作负载动态探测 (Auto-Discovery):
- 若服务未收录在内置清单中,脚本自动调用 Shipwright API(
POST /workflow-context/v1/workflows/query)依据服务名与env: test匹配测试环境 CI 流水线 ID; - 自动调用服务云 API(
GET /cloud-proxy-api/cloud-application/app/{serviceId}/virtual-services)检索匹配环境为test的工作负载 ID;
- 静默自学习沉淀:
- 探测验通后,自动将
ciWorkflowId和testWorkloadId持久化写入~/.shrimp/skills/live-inspector/service_catalog.json; - 下次执行直接命中本地缓存,实现 0 手动配置、0 维护成本、越用越聪明。
5.3 🛡️ 生产发布安全铁律 (Strict Test-Only & Production Advisor SOP)
🚨 【生产环境铁律:严禁自动化脚本直写生产容器】 - 生产环境镜像部署直接影响线上真实业务,严禁任何 AI Agent 或自动化脚本绕过官方发布平台直接更新生产虚拟服务容器! - 自动化构建部署能力绝对仅对测试环境 (`test`) 开放。
生产变更参谋模式 (Advisor SOP)
当用户提出“把这个分支/镜像部署到线上/生产环境”时,AI 自动触发发布参谋模式:
- 阻断直写:底层脚本拦截任何目标为
prod/online的部署指令; - 生成《生产环境部署参谋单》:
- 🎯 应用信息:微服务名称 (
serviceId); - 🏷️ 推荐发布镜像:展示经过测试验证的最新产物镜像 Tag(例如
hub.ke.com/{app}:{timestamp}-{branch}-{hash}); - 📝 代码变更摘要:关联的 Git Commit、分支名称、构建人与构建时间;
- 交付官方控制台直达链接:
🔗 服务云生产工作负载控制台直达链接:
https://cloud.intra.ke.com/console/project/cloud/application/{serviceId}/virtual-service-list- 引导负责人审批发布:指引业务负责人在服务云控制台选择该镜像,发起标准的生产发布与审批流程。
5.4 🌐 前端微服务通用构建与服务云交付引擎 (scripts/feci_deploy.js) - FeCI / 青蝉 + 服务云交付中心
全面支持贝壳全量前端微服务(IOT、JZ、ZK、HT 等所有技术栈)的自动化 FeCI 构建、服务云工作负载容器更新与 CDN 静态资源同步:
| 参数/选项 | 简写 | 默认值 | 说明 | |
|---|---|---|---|---|
| `[appName\ | jobId]` | - | 自动识别 | 目标前端项目名 (如 smart-customer-service-fe, iot-platform-fe) 或 FeCI 任务 ID (如 1282),未提供时自动从本地 Git 仓库识别 |
--branch | -b | 自动提取 | 构建的代码分支,默认读取本地当前 Git 分支 (master, feat/xxx) | |
--env | -e | test | 目标发布环境类型(默认: test,严格拦截生产环境 prod / online) | |
--deploy-only | - | false | 纯部署模式:跳过 FeCI 代码构建,直接选取最近构建产物下发服务云测试工作负载与 CDN 发布 | |
--ci-only | - | false | 纯构建模式:仅执行 FeCI 流水线构建与产物归档,不触发服务云工作负载部署 | |
--search | -s | null | 搜索 FeCI 平台上的所有任务与流水线 (如 -s "customer-service") | |
--list | -l | false | 查看该任务最近的历史构建记录与触发人、耗时 | |
--dry-run | - | false | 安全预检模式,仅打印任务名称、代码仓库、构建环境与分支,不触发实际构建与部署 | |
--set-cookie | - | - | 保存更新 FeCI 平台 (feci-next.ke.com) 独立 Session Cookie 凭证 | |
--set-cloud-cookie | - | - | 保存更新服务云平台 (cloud.intra.ke.com) 统一 Session Cookie 凭证 |
零硬编码与跨工程全流程闭环
- 自动感知:任意前端工程根目录下执行
node scripts/feci_deploy.js,自动识别当前工程与 Git 分支; - 动态嗅探:通过 FeCI 官方 API(
GET /api/job/list)动态匹配代码仓库与项目名推导流水线 Job ID; - 构建联动交付:构建成功后,自动直连服务云交付中心(
PUT /apis/cloud-application/app/:serviceId/virtual-service/delivery),一键更新测试工作负载容器镜像并同步 CDN 静态资源; - 本地自学习:探测验通后自动持久化到
~/.shrimp/skills/live-inspector/feci_catalog.json,实现越用越快、全公司前端工程通用。
📊 6. AI 交付呈现规范
- 日志排查交付:概况元信息 ➕ 结构化明细表格 ➕ 异常原因与堆栈分析;
- TraceId 追溯交付:强制绘制清晰的 Mermaid 时序交互图(展示 上游 -> 微服务 -> DB/Redis/下游);
- Apollo 配置交付:标明配置中心来源、命名空间、配置 Key、格式化解析后的 JSON 结构,并解释业务含义;
- CI 构建与测试部署交付:汇报服务名称、构建分支、流水线 ID、轮询耗时、出炉镜像/产物地址,以及测试环境工作负载更新生效状态;
- 协同引导:当发现数据异常或开关需要动态干预时,主动提示可唤起
leo-live-runner进行免发版处理。 - 排查经验沉淀:组织最终回复前,按本地排查流程库独立评估复用价值,不以是否执行过前置检索为条件。有已验证的新方法或判断分支时先查重,在结论文末简短询问是否脱敏保存或更新到本地流程库;用户已明确授权则直接保存并回读。单次普通查询、仅有猜测、无新增内容、本次已拒绝或已询问待答时不再询问;未获保存授权不写入。
🔌 7. 自动获取 Token/Cookie
默认复用现有缓存;仅在凭据缺失或明确登录失败时,按需启动 credential_relay,从已登录浏览器自动获取一次。新凭据经只读接口验证成功后才写缓存。普通 403、500、超时不会触发刷新;显式 --token、--cookie 或环境变量优先,不自动切换账号。构建、发布等写请求不会自动重放。
安装与使用
- 在 Chrome 打开
chrome://extensions/,开启开发者模式,选择【加载已解压的扩展程序】。 - 选择当前 skill 下的
resources/chrome_extension。AI 应提供当前生效的绝对路径;macOS 可用Cmd + Shift + G输入路径,Windows 可在文件选择器地址栏输入。 - 已安装旧版时,将扩展更新到本目录的 1.3.0 并点击【重新加载】。
- 在同一浏览器普通 Profile 登录目标网站,正常执行 skill 命令即可,无需复制或配对文件。
插件约每 60 秒探测本机 127.0.0.1:19528;没有任务时不读 Cookie。业务进程只在等待凭据时监听,任务仅存内存,拿到结果、超时或取消后关闭。默认最长等待 180 秒;系统休眠可能延迟探测。超时请确认浏览器和扩展已开启、目标网站已登录,然后重试。
平台范围
| 场景 | 自动获取范围 |
|---|---|
| 服务云 MySQL | cloud_console_token_egg |
| 服务云构建部署 | 适用于服务云请求 URL 的 Cookie |
| Shipwright | 独立获取和缓存,不复用服务云整串 Cookie |
| FeCI | 独立获取适用于 feci-next.ke.com 的 Cookie |
| Apollo 测试 Portal | 适用于 Portal 的 Cookie(包括 jt_apollo_login_token) |
| Dinsight | 上述 5 个 Key,按实际认证 API URL 获取 |
| Paoding 测试日志 | 匿名优先;明确鉴权失败后尝试缓存及浏览器 |
| FAST / Apollo ConfigService | 沿用现有访问流程,不新增强制凭据要求 |
第一版仅支持浏览器 Cookie,包括 HttpOnly Cookie 和存于 Cookie 中的 Token;不读取 localStorage、sessionStorage 或请求头 Token。仅支持同机单个普通 Profile,不支持隐身、分区 Cookie 或远程浏览器。信任本机程序,无配对密钥;端口被其他进程占用时返回 RELAY_BUSY,稍后重试。
手动兜底
设置 LEO_INSPECTOR_BROWSER_CREDENTIALS=off 可关闭自动获取,保留已有缓存和手动设置参数。不能安装插件时,可在浏览器开发者工具 Application → Cookies 复制目标凭据,或使用插件导出 Cookie,再调用业务脚本的 --set-token / --set-cookie。Shipwright 使用 ci_deploy.js --set-shipwright-cookie。不要在回复、日志或代码中记录凭据值。
📚 规范与实战文档索引
- Apollo 配置探查协议与实战手册:references/apollo-config-guide.md
- FAST 日志协议与检索自愈机制:references/fast-log-guide.md
- 后台页面点击与数据探查指南:references/page-inspect-guide.md
- Dinsight 自然语言查数协议:references/dinsight-query-guide.md
- Trace 全链路时序排障实战:examples/100_trace_and_log_query.md
