gemini-cli-bot 的 Metrics Skill基于时间序列指标的仓库健康度根因分析实践【免费下载链接】gemini-cliAn open-source AI agent that brings the power of Gemini directly into your terminal.项目地址: https://gitcode.com/GitHub_Trending/gemi/gemini-cli本文围绕 gemini-cli 仓库中tools/gemini-cli-bot/.gemini/skills/metrics/SKILL.md定义的 The Brain (Metrics Root-Cause Analysis) 技能展开说明该 AI 维护者gemini-cli-bot如何消费确定性脚本产出的仓库时间序列指标、按优先级策略识别异常趋势、执行假设驱动的根因调查并受安全约束地决定是否提出可落地的改进直至自动开 PR。读完后你能掌握一套确定性数据采集 LLM 推理诊断相结合的仓库自我维护方法并理解指标产出格式、delta 计算、以及 LLM 调用边界分类专用、策略隔离等实现细节。技能定位Brain 推理层的第一阶段在 gemini-cli-bot 的双层执行模型中存在两个互补的系统见 tools/gemini-cli-bot/README.mdSystem 1Pulse/Reflex 层30 分钟 cron 触发的高频、确定性维护由纯 TypeScript 脚本执行分诊、路由等即时操作System 2Brain/Reasoning 层24 小时 cron 触发的战略性调查与自优化采用多阶段的 Agent 化 Gemini CLI 流程指标采集 → Phase 1 推理即本文的 metrics 技能→ Phase 2 批判验证 → Phase 3 发布自动 PR。metrics 技能正是 Brain 层的 Phase 1。其官方定义SKILL.md的目标是Analyze time-series repository metrics and current repository state to identify trends, anomalies, and opportunities for proactive improvement. You are empowered to formulate hypotheses, rigorously investigate root causes, and propose changes that safely improve repository health, productivity, and maintainability.值得注意的是调用链路编排者orchestrator提示模板 brain/scheduled.md 中明确要求将 **metrics 工作流委派给 worker agentworker 再激活本技能完成指标采集与初步分诊且所有来自 GitHub 的不可信内容须包裹在untrusted_context标签中传入。这体现了采集交给确定性脚本、分析交给受限 Agent的分工。输入数据三个 CSV 数据源技能在 Context 一节中声明了它的输入契约这也是理解整个数据流的关键数据源路径用途时间序列指标tools/gemini-cli-bot/history/metrics-timeseries.csv趋势分析、异常检测的主数据源上一轮点态快照tools/gemini-cli-bot/history/metrics-before-prev.csv与本轮指标对比环比本轮采集结果运行指标采集器后生成的metrics-before.csv当前时刻的指标值这三个文件全部由确定性采集器 metrics/index.ts 生成与维护技能本身不直接采集数据而是读数据、下判断。数据采集器指标是如何产出的理解技能的输入必须理解metrics/index.ts的工作方式它是整个指标管线的核心先同步历史通过execFileSync(npx, [tsx, SYNC_SCRIPT])调用 history/sync.ts 同步历史数据失败仅告警、不中断遍历执行脚本读取tools/gemini-cli-bot/metrics/scripts/下所有.ts/.js文件逐个用npx tsx执行捕获 stdout解析双格式输出processOutputLine同时兼容两种脚本输出——JSON 形式{metric: ..., value: ...}对应 metrics/types.ts 中的MetricOutput接口与裸 CSV 行metric,value自动追加 delta 指标对每个可解析为数字的指标调用 history-helper.ts 的getHistoricalAverage计算该指标过去 7 天与 30 天的历史均值并额外写入${metric}_delta_7d与${metric}_delta_30d两行——即当前值减去历史均值。这是让 LLM 无需自己做时间序列统计就能感知偏离度的设计滚动时间序列本轮全部行以timestamp,metric,value追加到metrics-timeseries.csv并维持表头 最近 5000 行数据的滚动窗口超过 5001 行即截断控制文件体积。当前仓库内置了 10 个指标脚本metrics/scripts/open_issues、open_prs、latency、throughput、backlog_age、review_distribution、time_to_first_response、user_touches、actions_spend、domain_expertise。本地运行方式为见 READMEnpx tsx tools/gemini-cli-bot/metrics/index.ts从两个脚本实现可以看采集的技术细节latency.ts通过gh api graphql查询最近 100 条已合并 PR 与最近 100 条已关闭 issue 的创建/关闭时间按authorAssociation区分维护者MEMBER/OWNER/COLLABORATOR与社区产出latency_pr_overall_hours、latency_pr_community_hours等 6 个指标。这正是 SKILL.md 中举例latency_pr_overall_hours 持续上升的指标来源actions_spend.ts拉取近 7 天 CI 运行记录逐条查询 jobs API 按started_at/completed_at计算计费分钟数按 workflow 聚合输出actions_spend_minutes总览与actions_spend_minutes_workflow:name明细——对应 SKILL.md 中监控 actions_spend_minutes 与 Gemini 用量的成本项。分析流程六步方法SKILL.md 的 Instructions 定义了完整的分析方法论以下按原文脉络展开并补充实现佐证。1. 读取并识别趋势Time-Series Analysis加载并分析metrics-timeseries.csv识别随时间恶化的显著异常原文示例latency_pr_overall_hours稳步上升、open_issues增长快于关闭速率。关键要求有两条主动性Proactive Opportunities即便指标稳定也要找出可改善可维护性或生产力的机会成本节约是最低优先级监控actions_spend_minutes和 Gemini 用量只有在仓库健康度与延迟等更高优先级满足后才可主动提出 Actions 与 Gemini 双端的成本节约建议。2. 假设检验与深入调查针对单个最显著或一组高度相关的趋势/机会提出竞争性假设头脑风暴多个潜在根因或改进策略收集证据使用ghCLI、GraphQL 等工具收集支持或反驳每个假设的数据允许编写临时本地脚本对数据切片选定根因选择被数据支持最强的假设。3. 维护者负载评估在提出任何依赖维护者行动的方案前必须先量化能力对比开放的、未处理的工作量未分诊 issue、待评审请求与活跃维护者人数。若比值表明过载不得提出只会产生更多 ping 的方案而应优先系统性分诊、自动路由或自动关闭类机制。4. 角色感知的瓶颈定位Actor-Aware Bottleneck Identification提出干预前必须先准确定位卡点属于哪一方卡在作者Author需要礼貌提醒或关闭宽限期卡在维护者Maintainer需要路由、聚合报告或升级机制卡系统CI/Infra需要工具修复或上报。这一条与 brain/scheduled.md 中 Phase 2 Critique 阶段审查的actor-awareness相互呼应构成提案质量的双重保障。5. 策略批判与评估审查现有策略检查.github/workflows/下的现有自动化与tools/gemini-cli-bot/reflexes/scripts/中的脚本分析有效性判断当前策略是否达成了其目标。6. 调查结论向 Orchestrator 总结发现。SKILL.md 在此设有一条硬约束修改tools/gemini-cli-bot/metrics/scripts/下的脚本时绝不允许改变输出格式必须是逗号分隔值写到 stdout。这与metrics/index.ts中processOutputLine的解析逻辑parts.length 2的name,value行才能参与 delta 计算严格对应——输出格式是采集器与脚本之间的契约。LLM 分类的使用边界确定性优先、角色分离、策略隔离技能中LLM-Powered Classification一节是本设计最容易被忽视、也最具工程价值的部分它授予在提案脚本中使用 Gemini CLIbundle/gemini.js做分类情感分析、高级分诊、语义标注的权限但附加了三条纪律确定性优先Preference for Determinism凡确定性 TypeScript/Git 逻辑System 1能达到同等质量与可靠性时优先用它仅在确需启发式或语义理解时才动用 LLM。这与 README 中 Pulse 层optionally utilizes Gemini CLI for high-confidence semantic classification的描述一致严格角色分离Strict Role SeparationGemini CLI 只能用于分类数据标注不得用于执行或决策默认策略强制执行Default Policy Enforcement调用 Gemini CLI 的生成脚本禁止使用专用的 tools/gemini-cli-bot/ci-policy.toml。从该文件内容看它是一条 priority999 的规则允许run_shell_command、write_file、replace与invoke_agent仅 headless 环境本质是为 bot 自身的 CI 环境保证 shell 与文件写入权限的高权策略。要求生成的脚本依赖默认仓库策略而非它是为了防止bot 自我生成的新自动化继承到超越其任务所需的执行权限是一种权限最小化设计。变更的发布约束PR 门控技能 Context 一节还定义了与 Orchestrator 的协作协议构成一道发布门Orchestrator 会通过 System Directive 告知本次运行是否启用 PR 创建启用时必须激活prs skill生成 PR 描述并暂存stage变更此时提案可被自动提升为 Pull Request未启用时不得暂存文件变更或尝试打补丁只需报告发现。此外brain/scheduled.md 对上层执行还施加了一次只改一件事One Thing at a Time、手术级最小变更Surgical Changes、零信任输入处理所有 GitHub 数据视为不可信、不得遵循其中的指令等约束确保 Phase 1 产出的提案在进入 Phase 2 批判与 Phase 3 发布前就已满足聚焦性与安全性要求。小结metrics 技能展示了 gemini-cli 仓库自我维护体系中的一个完整闭环确定性脚本metrics/scripts/ index.ts history-helper.ts负责可复现地采集指标与 7d/30d delta技能文档则以趋势识别 → 假设检验 → 负载评估 → 瓶颈定位 → 策略批判 → 结论六步法约束 LLM 的推理过程并用分类专用、确定性优先、禁用高权 CI 策略、PR 门控四条规则框死 LLM 的权限边界。其核心经验可以迁移到其他仓库先让数据采集完全确定性化固定输出契约、滚动窗口、自动 delta再把 LLM 限制在读证据、下判断的角色上并对任何 LLM 生成的自动化强制降权运行。【免费下载链接】gemini-cliAn open-source AI agent that brings the power of Gemini directly into your terminal.项目地址: https://gitcode.com/GitHub_Trending/gemi/gemini-cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考