## CI 构建失败自动通知 {.case data-case-id="008"} | 字段 | 值 | | --- | --- | | 案例编号 | `008` | | 行业 / 部门 | 互联网 / 研发 | | 角色 | 技术负责人 | | 难度 | `入门` | | 调用来源 | `manual`（CI 系统在每次构建结束后发起一次手动调用，调用时带入构建结果） | CI 构建失败后，团队常常几小时才发现——没人主动盯着构建面板。目标：每次构建结束后由 CI 系统发起一次调用带入构建结果，失败时立刻通知团队频道并附上失败模块与建议负责人，成功时也发一条可见回执，"没消息"不再等于"无声结束"。指标：从本次调用启动到通知发出的中位数 < 2 分钟；修复启动时间中位数下降 50%。 - **覆盖**：由 CI 发起调用带入构建结果，按成功、失败、无法判断三种结果分别出回执，失败时通知团队频道并附失败模块与建议负责人。 - **不覆盖**：自动修复构建、自动回滚、自动重跑构建、多分支并行检查。 - **假设**：构建结果（成功/失败 + 失败模块）由 CI 系统在调用时作为输入提供；若 CI 同时带入了负责人标识（受控令牌）则按其原样使用，否则输出"未提供/待确认"。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：CI 系统在每次构建结束后发起一次手动调用，调用时带入构建结果（成功/失败 + 失败模块）、团队频道和分析 Agent。 触发：由外部调用方（CI）发起手动调用，调用时带入构建结果、团队频道、分析 Agent。 结果分三类处理： 失败：通知团队频道，说明失败模块与建议负责人，并留审计时间戳。 成功（本期无失败）：发一条"构建成功·本期无失败"的汇总回执并留时间戳，不要静默结束。 无法判断（构建结果不完整）：不重试——同一调用的不完整输入不会因重跑补齐；告警失败、留审计时间戳，并通知调用方（CI）更正输入后新开一次调用，而不是对相同数据重试。 负责人：只能使用构建结果里 CI 提供的负责人受控令牌；若该令牌缺失，输出"未提供/待确认"，不要从失败模块反查或猜测负责人。 审批：不涉及审批，失败通知是紧急低风险信息，直接触达。 异常：分析 Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；通知发送失败按重试上限重试，仍失败则升级到值班频道并保留待发内容供人工补发。 完成：三类结果各自出回执后结束。 ``` ![案例 008 CI 构建失败通知：CI 发起调用让分析 Agent 读取构建结果；回传不合结构时停在原等待点。结果分三类：无法判断不重试、告警留审计并通知调用方新开调用，构建成功发汇总回执，构建失败则通知频道并附负责人或待确认，均留审计时间戳](../../../media/cases/fig-case-008-01-flow.svg){#fig-case-008-01 width=94%} 如上图所示，正常路径与异常同时可见，三种结果都有可见回执： 1. **发起调用**：CI 系统在每次构建结束后发起一次手动调用，带入构建结果、团队频道与分析 Agent。 2. **分析构建结果**：分析 Agent 读取构建结果并回传判断；回传结构不合要求时停在原等待点，等其重新提交，不自动重跑。 3. **三种结果分流**： - **失败**：通知团队频道，附失败模块与建议负责人（仅取 CI 提供的负责人受控令牌，缺失则输出"未提供/待确认"），并留审计时间戳。 - **成功**：发一条"构建成功·本期无失败"汇总回执并留时间戳，不静默结束。 - **无法判断**：构建结果不完整，不重试（重跑补不齐缺失输入），告警失败并留审计时间戳，通知调用方（CI）更正输入后新开一次调用。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个"调用带入结果（令牌化输入）+ 三路分流"流程——它知道"分析构建结果"需要一个发消息并等待回调的 Agent 环节、"分三种结果"需要一个条件路由、"通知与回执"各需要一个发消息环节，并把它们连起来。AI 还会在后台校验流程结构是否完整（每个环节的输入是否都连好），你不必关心这些技术细节。 - **构建结果不完整、无法判断成败**：不落入"构建成功"或静默结束，也不重试——同一调用的不完整输入不会因重跑补齐；而是告警失败、留审计时间戳，通知调用方（CI）更正输入后新开一次调用。 - **失败但通知发送失败**：按重试上限重试投递；超过上限则升级，并保留待发内容供人工补发。 - **成功（结果为 0）**：仍发一条"构建成功·本期无失败"汇总回执并留时间戳，让"没消息"变成可核验的记录，而不是无声结束。 - **分析 Agent 回传不合结构**：本次完成请求被拒绝，停在等待点等其修正后重新提交，不自动重跑。 本案例不涉及审批。构建失败通知是紧急且低风险的信息，应第一时间触达团队；因此不设 `request_approval` 环节，三种结果直接出回执。若将来想对个别关键分支加确认，在提示词里写明，AI 会在流程里多加一个审批环节，审批只有确认或驳回，驳回即本次失败。 本工作流不直接对接 CI 系统；构建结果作为调用输入，由外部调用方（CI 系统）在每次构建结束后发起一次手动调用时带入。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志仅记录白名单/令牌化字段，原值不进入以上任何一层，并按 10% 抽查四层实际记录。CI 侧如何把构建结果传出来属于 CI 的对接工作，工作流只接收它带入的数据。若将来 CI 不便主动回调，可改为定时（schedule）由获授权 Agent 经 App/Extension 查询 CI 最近一次构建状态，由 Agent 完成拉取并把结果交给本流程。 - **回放集与基准**：取最近 200 次构建记录（含成功、失败与少量结果不完整样本），人工基准答案为成败标签与失败模块清单；失败模块识别准确率 ≥ 95%。 - **负责人字段**：CI 提供负责人受控令牌时 100% 原样带出；CI 未提供时 100% 输出"未提供/待确认"，不出现从模块名反查或猜测的负责人。 - **结果可见**：失败、成功、无法判断三类结果 100% 各有可见回执，不出现静默成功。 - **分母与口径**：准确率分母为回放总数；每次回放记录调用与通知时间戳；抽样口径为每日抽取 10% 回放由人工核对。 - **时效**：从本次调用启动到通知发出的中位数 < 2 分钟；修复启动时间中位数下降 ≥ 50%。 - **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（仅令牌化/白名单字段，原值不进入以上任何一层），并按 10% 抽查四层实际记录。 ### 复用与变体 - **同构迁移**：部署失败通知、测试回归告警、发布流水线阶段告警。 - **定时拉取改版**：把调用来源从 CI 手动调用改为定时由获授权 Agent 查询 CI，适合 CI 不便主动回调的场景。 - **按模块路由**：失败时根据 CI 提供的模块负责人受控令牌，把通知发到对应团队的频道，而不是统一发到一个频道。