PR 已创建，但红色 CI 又成了人的工作
AI 代理实现了功能，完成本地测试，甚至创建了 PR。但如果只在远程 CI 中发生失败，流程就中断了。必须由人查看通知、复制日志，并重新说明失败的上下文，代理才能开始下一次修复。
Nx 想要填补的缺口不是代码生成，而是PR 之后的信息断层。它让本地代理能够重新获取 Nx Cloud 的流水线状态、失败任务输出以及 Self-Healing CI 的修复建议。
不过，这并不是一条命令就能自动解决所有失败的功能。需要依次准备本地 Nx 运行、Nx Cloud 与 VCS 连接、CI 中的 fix-ci 步骤，以及代理的 MCP 和技能配置。生成修复建议的条件与自动应用该建议的条件也需要分别查看。
代理重新获得的是失败后的上下文
Nx MCP 提供 ci_information 用于查询当前分支的 CI 状态，ci_task_output 用于获取单个任务输出，以及 update_self_healing_fix 用于应用或拒绝 Self-Healing 建议。 换句话说，代理可以直接查询过去由人在 CI 页面和编辑器之间传递的信息。
| PR 后阶段 | 连接前 | 连接后 |
|---|---|---|
| 状态确认 | 由人查看 CI 通知和页面 | 代理查询 Nx Cloud 状态 |
| 失败传递 | 复制日志并编写新提示 | 直接获取失败任务输出 |
| 修复建议 | 由人重新说明原因 | 审查 Self-Healing 建议并应用或拒绝 |
| 完成判断 | 每次失败后由人恢复流程 | 再次查询 CI 状态以判断后续工作 |
这里需要更正一个名称。早期官方文章写的是 ci-monitor，但当前公开仓库的技能路径和元数据中可确认的名称是monitor-ci。 如果仍用旧名称查找安装路径或技能名称，可能与当前配置不符。
Self-Healing CI 会利用失败日志和 Nx 项目图分析原因并生成修复方案，然后重新运行最初失败的任务，以验证修复是否有效。 这是对特定失败任务的验证，并不保证整个代码在业务上的正确性，也不保证 PR 可以合并。
先确认 Nx 能在全新检出中运行
此流程面向已有 nx.json 且 package.json 中包含 Nx 的现有工作区。在没有 Nx 的仓库中从初始化开始执行会更改依赖项和配置文件，因此应作为单独的引入工作处理。
- 准备仓库指定的 Node.js 和包管理器。
检查package.json、锁定文件、版本管理文件和现有 CI 配置。准确的 Node.js 版本和安装命令应遵循该仓库的设置。 - 执行与锁定文件匹配的项目依赖安装命令。
安装结束后，在工作区根目录运行npx nx --version，或运行仓库平时使用的 Nx 任务。本地 Nx 能正常启动是第一个成功标准。 - 如果没有 Nx，请停止连接工作。
如果既没有nx.json，package.json中也没有 Nx，请不要从configure-ai-agents开始。npx nx@latest init会添加 Nx 依赖项和配置，因此这是需要团队审查的单独变更。
先连接 Nx Cloud 和 CI
在配置代理之前，需要先建立一条让远程 CI 留下状态和修复建议的路径。你需要 Nx Cloud 账户、受支持的 VCS 集成，以及修改工作区和 CI 配置的权限。
- 打开Self-Healing CI 设置文档并连接工作区。
在工作区根目录运行npx nx@latest connect，然后完成浏览器认证。 - 在 Nx Cloud 中确认 VCS 连接。
连接官方文档列为支持对象的 GitHub、GitLab、Azure DevOps 或 Bitbucket 仓库，并在 Workspace Settings 中启用 Self-Healing CI。 - 在正确的 CI job 末尾添加
npx nx fix-ci。
将它放在启动 Nx 任务的 main 或 orchestrator job 中，并配置为即使前面的步骤失败也会运行。在 GitHub Actions 中需要if: always()；其他 CI 需要等效条件。若使用 BYOC 配置，则除 main job 外，每个 agent job 也需要相同处理。
如果 fix-ci 只在成功路径中运行，就无法处理失败。
除了命令的位置外，还要在 CI 日志中确认它是否会在之前的测试失败后实际运行。始终运行条件的语法因 CI 提供商而异，因此必须适配现有流水线的语法。
将代理配置分为安装和运行两部分确认
Nx Cloud 连接完成后，现在可在编程客户端中配置 Nx MCP 和 monitor-ci 技能。官方设置命令会确认现有 Nx 工作区，然后创建特定于客户端的规则、MCP 和技能文件。
- 指定要使用的客户端并生成配置。
运行npx nx configure-ai-agents进行交互式选择，或在自动化环境中使用npx nx configure-ai-agents --agents <claude|codex|copilot|cursor|gemini|opencode> --no-interactive格式。 - 审查生成的变更。
检查 diff，确认规则文件以及 MCP 和技能设置已添加到预期的客户端位置。在直接提交到仓库前，也要确认不会与组织规则或现有配置冲突。 - 检查安装状态。
运行npx nx configure-ai-agents --check=all。如果 rules、MCP 和 skills 检查通过，说明配置文件已成功安装。 此检查并不表示远程 CI 查询也已成功。 - 确认 VCS 认证和权限。
如果要让代理负责创建 PR，它必须具有提交、推送和创建 PR 所需的认证和权限。如果没有这些权限，请由人创建 PR 后仅请求监控。 - 从 PR 分支而非默认分支发送第一次输入。
如果有创建 PR 的权限，可以输入官方示例：Commit the work, create a PR and monitor CI.一开始不要以自动应用为前提；应先确认代理能否获取 Nx Cloud 的流水线状态。
建议生成和自动应用是两道不同的门
没有 Self-Healing 建议并不意味着 AI 可信度低。生成建议的阶段和自动应用已生成建议的阶段，受到不同条件的约束。
| 阶段 | 需要确认的条件 | 成功信号 |
|---|---|---|
| 代理安装 | 规则、MCP 和技能配置 | --check=all 检查通过 |
| CI 监控 | Nx Cloud 连接和 MCP 工具公开 | 查询当前 PR 分支的流水线状态 |
| 建议生成 | PR CI 运行、启用 Self-Healing、分支规则、eligible task 和排除模式 | 确认失败任务的建议或状态消息 |
| 自动应用 | auto-apply 模式、高置信度和失败任务重跑验证 | 通过全部条件的建议被自动应用 |
如果没有生成建议，请确认 PR 中是否运行了 CI、是否启用了 Self-Healing、是否在默认或受保护分支上运行，以及失败任务是否被 eligible task 或排除模式限制。 相反，如果能看到建议但没有自动应用，则需要单独检查 auto-apply 模式、置信度和重跑验证结果。
monitor-ci 公开的设计会区分成功、没有需要修复的内容、环境问题和超时等结果进行处理。 因此，如果第一个 PR 的 CI 从一开始就通过，没有修复建议也是正常的。如果代理查询到了该次运行的状态，监控连接这一首要目标就已经达成。
不要把首次引入的目标定为“无人合并”。
一开始请用 lint 或单元测试等失败和重跑结果明确的任务来确认连接。如果人们复制并传递 CI 日志的次数减少，而且代理能够区分报告失败输出和修复建议状态，那么 Nx 想要填补的自动化缺口就真正闭合了。
如果想进一步深入
End to End Autonomous AI Agent Workflows with Nx 是说明 PR 后需要人再次介入的问题，以及代理监控 CI 完整流程的起点。nx.dev
AI-Powered Self-Healing CI 可以分别确认 VCS 连接、fix-ci 放置位置、建议生成范围和自动应用条件。nx.dev
Integrate Nx with your Coding Assistant 可以确认支持的客户端、非交互式配置和 --check=all 检查流程。nx.dev
