把本地AI代理交给功能实现到PR提交，都给它包了。心想应该没问题吧，结果CI一变红就卡死了。得有人打开日志、找出原因、重新写个提示词它才肯继续动。这还能算自主工作流吗？
为什么AI代理在CI面前就停住了？
做Nx这个monorepo平台的Nrwl公司直接点出了这个问题。他们说"2025年是代理年，2026年就该是自主工作流的年代"，但真正卡脖子的不是代码能力，而是CI流程本身。
流程基本都一样。本地代理读需求、写功能。类型检查、lint、测试全过。自己提PR。到这儿还挺自主的。问题在PR上去以后，CI一旦fail了，代理根本不知道。得有人看到告警、打开日志、搞明白出了啥事、再给代理解释一遍，下一轮才能开始。
人类一插手就失去什么？
不是就失点时间那么简单。上下文就断了——这才是真问题。代理做的时候那套思路、为什么这么写，一到人手里就reset。人类得从头读日志。
上下文丢失的代价
Nx Cloud能让CI比GitHub Actions快30～70%，成本低40～75%。但要是CI一fail就得人来收拾，这省下来的钱就打了不少折扣。流程快了，人工介入的频次没少。
有意思的是，不只Nx碰上这事儿。2025年中期，软件工程师Geoffrey Huntley分享了个叫"Ralph Wiggum循环"的东西——同一个问题，换个角度。最简单的形式就是：while:; do cat PROMPT.md | claude-code; done。让代理不自己停，一直循环到任务完成。Huntley把它叫"非决定性世界里的决定性坏办法"。问题是这循环有个死角——只在本地跑，跟CI这个外部世界根本接不上。
Nx怎么接上这个口子的？
Nx的办法是连接两样东西。一个是Self-Healing CI，2025年6月就开了公测。另一个是ci-monitor技能，通过MCP把本地代理和Nx Cloud的CI连起来。两个东西一组合，Ralph循环就跑出本地了。
| 传统做法 | ci-monitor + Self-Healing CI | |
|---|---|---|
| 检测CI失败 | 人看告警、打开日志 | MCP实时送给本地代理 |
| 分析根因 | 人对着日志和代码找 | 错误日志+项目图谱自动分析 |
| 应用修复 | 人改代码、重新推送 | 代理检查再应用修复方案 |
| 继续迭代 | 每次fail都得人来 | 自动循环直到绿灯 |
流程这样：代理提交、发PR，ci-monitor技能就开始盯着流程进度。有失败？Self-Healing CI根据错误日志和Nx项目图谱生成修复方案。代理检查一遍、应用上去，CI绿了就行。人类呢？只用看最后的PR——中间那些修复不用一个个看。
Nx的2026路线图继续推进这事儿。Self-Healing CI生成的修复方案有超一半被评为有用。下一步是把多个仓库并进一个代理会话处理，一个PR修好几十个项目。
现在就接上
- 把工作区连到Nx Cloud
现有Nx工作区的话，先连到Nx Cloud账户。Self-Healing CI需要这个前置。 - 启用Self-Healing CI
Nx Cloud控制板里开关一拨就行。不用什么批准，马上能用。 - 跑nx configure-ai-agents
MCP服务器、monorepo技能（包括ci-monitor）、CLAUDE.md和AGENTS.md文档一起给整好。 - 告诉代理干活儿去
"Commit the work, create a PR and monitor CI"一句话，剩下的代理搞定。 - 只看最后的PR
不用看中间的修复日志。CI绿了的最终成果检查一遍就行。
不一定要Claude Code
Nx的技能系统不锁定在某一个代理上。任何支持MCP的工具都能用——Claude Code、Cursor、GitHub Copilot、Gemini等都能同样配置。
想深入了解
Introducing Self-Healing CI Nx Cloud自我修复CI功能的首次公开发布 nx.dev
Teach Your AI Agent How to Work in a Monorepo ci-monitor在内的完整技能列表和配置方法 nx.dev
Nx 2026 Roadmap 复合monorepo、代理迁移等后续计划 nx.dev
Orchestration & CI with Nx Cloud CI速度和成本改进数据及不稳定任务处理方式 nx.dev
Ralph技法原文 Geoffrey Huntley自己写的Ralph Wiggum循环解释 ghuntley.com
