「为什么是现在开始不对？」排障时，指标和日志告诉你现在哪里不对，但这个问题，答案常常在最近一次提交里。
AI SRE 现在可以连接你的 GitHub 组织或 GitLab 实例了。在控制台的 Apps 目录里装一次，之后三件事变得顺理成章：排查的时候它自己去读最近的提交，CI 红了它自己去翻失败日志，小修小补它直接开好 PR 等你评审。
全程不需要粘贴任何令牌。云端沙箱和自部署的 Runner 都支持，两种环境都只走出向连接，不用在防火墙上开入向端口。
能拿它做什么
排障时对上「什么时候开始坏的」。 以前想让 AI 看代码，得自己把 diff 复制进会话；现在直接说：
结合今天凌晨那次故障的时间窗，过一遍 payment-service 最近 24 小时的提交，找出最可疑的改动并说明理由。
我们之前写过一篇从用户现场到修复的完整过程，那次能一路追到修复，靠的就是能读到仓库。
CI 红了，先让它看一眼。 以前 CI 挂了，你得自己点开日志，翻到失败的那一步。现在：
main 分支的 CI 红了，读一下失败那步的日志，告诉我原因。如果是代码问题，开一个修复 PR。
能看到红叉和能看到日志是两回事，它两样都能：检查结果和提交状态告诉它 CI 过没过，Actions 的读权限给它失败步骤的完整日志。所以它能自己说出为什么没过，而不是把红叉转述给你。
小修小补，直接开 PR。 改文档、更新过时的示例、修一个明显的笔误，这类事不值得你放下手里的活：
把示例里还在用旧版配置项的地方都更新掉，开一个 PR。
PR 的作者是安装时开通的专用机器人账号，不是你本人。改动照常走你们的评审流程，合不合并永远是人说了算。如果修复同时动了 CI 配置也没问题，令牌连工作流也可写，代码和 CI 的改动可以落在同一个 PR 里被完整评审。
装一次，不贴令牌
GitHub 这边，在自己的组织里安装我们的 App，勾选哪些仓库可以给它看，就完了。不需要生成 Personal Access Token。PAT 是一个人的身份，他能看到的仓库它全能碰，有效期按月按年算，存在哪、谁能读到、人离职了怎么办，全是要操心的事，App 把这些都收掉了。一个账号连多个 GitHub 组织也支持，每个组织各自签发一把令牌。
GitLab 这边，管理员走一次标准 OAuth 授权，平台自动开一个专用的机器人账号，按能拿到的最高一级授予权限：先试服务账号，不行退到组级令牌，再不行退到项目级令牌，最终拿到 Developer 这一档。gitlab.com、极狐 GitLab 和自建实例都支持。
跑起来之后用的是机器人的身份，管理员本人的授权只在开通那一下用到，之后 Agent 干的每件事都记在机器人名下。令牌到期前平台自动换新，不需要人管。
装 App 不会给 Agent 增加任何新工具。它还是敲原来那些 git 命令，只是这些命令现在能连上你的仓库了。
凭据是怎么管的
每次派发命令时现签发，注入到 Agent 本来就在用的 git、gh、glab 里，只对你授权过的仓库有效，不落数据库，一轮命令结束就失效。就算哪天真有人读到一把，它能碰的也只有你勾选过的那几个仓库，而且活不过那一轮命令。敏感的 secret 建议在 GitHub 侧配 environment protection rules，让它只在受保护的环境里解开，这道闸门一直在仓库主人手上。
没装 App 的话，云端会话就是没有仓库访问，没有任何隐式回退。自部署 Runner 会用那台机器上本来就有的凭据，这条路完全在你的控制下。
一件小事说明白：GitHub 对「仓库不存在」和「仓库存在但没授权给这个 App」返回一模一样的 404。所以 Agent 说「当前凭据看不见这个仓库」的时候，意思是该去看一眼授权范围，不是仓库没了。
边界直说：Agent 能做的，上限就是你勾选给它的仓库范围；令牌一轮命令后就失效，留不下长期凭证。超出勾选范围的东西，它看都看不到。
从哪儿开始
控制台左侧导航 AI SRE → Apps（插件），安装 GitHub App，或连接 GitLab（gitlab.com、极狐 GitLab、自建实例都支持）。详细步骤见文档。
