使用 Gemini 3.5 Flash 在几分钟内找出 ML CI 失败的根因
调试损坏的 ML 训练流水线既慢又繁琐。你要从两个不同的 CI 运行中拉取日志，将它们与 golden values 对比，翻查提交历史以找到回归点，然后再写一份报告解释哪里出了问题以及原因，而你的团队还在等待。这个用例将整个调查过程自动化了。
通过将 ml-failure-audit 技能与 Google 的 Gemini 3.5 Flash 模型以及作为远程推理引擎的 Gemini Agent API 结合，Eigent 的多 agent 团队可以端到端审计一次 CI 失败：获取日志、提取参考值、追踪证据、委派繁重分析，并生成结构化交付物，全部只需一个提示词。
选择 Gemini 3.5 Flash 作为你的模型
前往 Settings → Agents → Model，从云模型列表中选择 Gemini 3.5 Flash。如果你更希望使用自己的 API 凭据，可以在 Settings → API Keys → Gemini 下填入自己的 Gemini key。
Gemini 3.5 Flash 针对长上下文任务进行了快速且高性价比的推理优化，这正是 CI 日志分析所需要的。
启用 Gemini Agent API 作为远程子代理
前往 Settings → Agents → Remote Agents，打开 Gemini Agent API 开关。这会将 Gemini Agent 注册为 Eigent 团队中可调用的子代理。
启用后，你的 Developer Agent 可以把计算密集型推理任务，例如对数百行日志进行根因分析，直接交给 Gemini Agent，而不是在一次模型调用中处理所有内容。这样你就拥有了一个双层架构：Eigent 的本地 agents 负责编排和工具使用，而 Gemini Agent 负责深度推理。
上传 ml-failure-audit Skill
前往 Settings → Agents → Skills 并上传 ml-failure-audit skill 包。你也可以浏览 Skill Hub: ml-failure-audit 了解该 skill 的详细信息和安装步骤。这个 skill 定义了 Eigent 应如何处理 CI 失败审计：需要收集哪些工件、执行哪些比较、获取哪些证据，以及如何构建最终报告。
上传后，团队中的任何 agent 在处理 ML 审计任务时都可以调用该 skill。
将你的任务发送给 Eigent
完成所有配置后，将你的任务提示输入 Eigent 的聊天窗口：
遵循 {{ml-failure-audit}} skill，并使用 remote sub agent 完成复杂子任务。
请审计这个 Megatron-LM MIMO VLM pretraining golden metric CI 失败。我提供了一个本地 NVIDIA/Megatron-LM 检出版本，位于 commit <your-commit-sha>，以及我附加的 CI 工件（例如通过和失败运行的日志）。失败的工作负载是一个 8-GPU frozen start convergence check，使用 sequence packing、global batch size 32、total packed sequence length 3200、packing buffer 4，以及 100 次训练迭代。
请判断这个失败是真实的模型 convergence/correctness 回归，还是 metric/gating policy 问题。请使用仓库中的 golden value comparison 代码和 CI 日志作为证据。不要重新运行 GPU training。
在仓库根目录生成 answer.json，包含 source_refs、extracted_facts、calculations、final_answer 和 validation。还要生成一份简洁的 answer.md。
请包含 repository URL、你的目标 commit 检出版本，并附上你希望比较的 CI 工件。Eigent 会立即开始规划调查。
在运行此提示词之前，请先安装 ml-failure-audit skill。
自带输入： 将 <your-commit-sha> 替换为你要审计的 commit，在你的工作区检出该版本，并附上你自己的 CI 工件（例如通过与失败运行的日志、stderr 捕获内容或导出的 CI job 输出）。你可以将 Megatron-LM 示例改造为任何你正在调查的仓库和失败场景。
Coordinator Agent 规划并分配任务
Eigent 的 Coordinator Agent 会读取提示词，并将其拆解为结构化审计计划。它会识别关键阶段，日志检索、数据提取、证据追踪和报告生成，并将整个调查分配给 Developer Agent。
Coordinator 不会机械地盲目委派：它会一并传递 skill 引用、仓库上下文和 CI 日志工件，让 Developer Agent 一开始就拥有所需的一切。
Developer Agent 加载 skill 并获取日志
Developer Agent 的第一步是加载 ml-failure-audit skill，读取其中的说明以理解审计方法。
然后它会并行运行 4 个命令 来抓取 CI 日志数据，同时拉取两份失败日志以及任何相关元数据。并行工具执行意味着数据收集阶段所花时间只是顺序执行的一小部分。
提取 golden values 并追踪修复提交
拿到日志后，Developer Agent 会运行一个 Python 脚本 来提取 golden reference values，即通过 CI 运行应产生的预期训练指标、loss 曲线或基准数值。然后它会将这些数值与失败日志中记录的值进行 diff，以准确找出偏离发生的位置以及偏离幅度。
接着，Developer Agent 会搜索 Megatron-LM 的提交历史，找到 fix commit，最有可能导致回归的具体代码变更。这个 commit 会作为审计报告中的确凿证据，为审阅者提供失败现象与底层代码变更之间的直接关联。
将深度推理委派给 Gemini Agent
一旦原始证据整理完毕，日志 diff、golden value 对比以及追踪到的 commit，Developer Agent 就会调用 Gemini Agent 来执行最繁重的推理步骤。
Gemini Agent 会分析完整上下文：代码发生了什么变化、该变化如何影响训练行为，以及最可能的根因是什么。几分钟后，它会返回一份完整、结构化的审计报告，涵盖失败诊断、影响因素和建议修复方案。
Developer Agent 编写最终审计报告
Developer Agent 会吸收 Gemini Agent 的分析结果，并在工作区中写入两个交付物：
-
answer.json: 一份机器可读的审计记录，包含失败类型、根因、受影响指标、证据 commit 和建议解决方案等结构化字段。适用于自动化流水线、工单系统或 CI 仪表盘。 -
answer.md: 一份简洁、可供人阅读的审计摘要，说明失败了什么、为什么失败、证据是什么，以及下一步该做什么。可直接粘贴到 PR 评论、Slack 线程或事故报告中。
这两个文件都会直接写入工作区文件夹，并可立即访问。
为什么这个工作流很重要
ML CI 失败之所以极难调试，是因为信号被淹没在密集的日志输出中，而且根因通常出现在距离症状若干次提交之前。这个工作流通过三个协同工作的能力来解决这一问题：
- 并行日志检索 消除了逐个拉取工件的顺序瓶颈。
- 基于 Python 的 golden value 提取 通过精确数值比较，而不是依赖模式匹配或人工检查。
- 将 Gemini Agent 作为推理子代理 将最复杂的推断步骤卸载给最擅长它的模型，同时保持编排轻量、分析深入。
结果就是，一次原本需要工程师 30–60 分钟专注工作的根因审计，现在只需几分钟即可交付，并附带结构化工件链路。
接下来可以尝试什么
当你的第一次审计完成后，可以用如下后续提示词扩展工作流：
针对最近的三个 CI 失败执行相同审计，并比较根因。
找到修复 commit 之后，使用审计报告预填充一个 GitHub issue。
设置一个夜间触发器，审计任何新的 CI 失败并将 answer.md 发布到 Slack。
替换为不同的模型，尝试用 Gemini 3.5 Pro 获得更深入的分析，或用 Gemini Flash Lite 获得更快的响应。
提升效果的技巧
- 明确附上你的 CI 工件。 ml-failure-audit skill 在你提供 commit 检出版本以及想要比较的日志或导出内容时效果最好（例如，一次通过运行和一次失败运行）。
- 包含 repository URL。 Developer Agent 会用它在提交历史中搜索 fix commit。直接链接到仓库可以省去一个搜索步骤。
- 明确输出文件。 要求同时生成
answer.json和answer.md，可以让 Developer Agent 输出两种格式，如果你需要给 CI 流水线使用机器可读输出、同时又需要给团队使用人类可读输出，这会很有用。 - 将 Gemini Agent 用于重推理任务。 当本地 agents 负责数据收集、Gemini Agent 负责综合时，远程子代理模式效果最佳。不要把它用于本地工具可以更快完成的简单查询。
