视频深度解析：CI/CD 已死，智能体时代需要持续计算

这份根据视频《CI/CD Is Dead, Agents Need Continuous Compute and Computers》内容整理的结构清晰的 Markdown 解析报告，深入探讨了在 AI 智能体（Agent）时代，传统 CI/CD（持续集成/持续交付）如何失效，以及为何"持续计算（Continuous Compute）"将成为新的软件开发基础设施范式。

https://www.youtube.com/watch?v=VktrqzQgytY

视频深度解析：CI/CD 已死，智能体时代需要持续计算

1. 演讲者与背景介绍

Madison Faulkner：NEA 风险投资合伙人（专注于基础架构与开发者工具领域）。曾任 Meta AI 研究员，领导数据与 AI 团队。
Hugo Santos：Namespace 首席执行官（致力于构建高性能计算基础设施，用以取代新一代 CI/CD 浪潮）。曾任 Google 微服务架构负责人。
核心观点：随着 AI 智能体（Agentic Software）全面接管代码编写，传统的 CI/CD 管道因无法承受机器引发的爆发式网络请求与分支数量而彻底"死亡"，软件开发正在从小规模的人类提交转向高并发、常驻型的"持续计算"与"智能体微服务"架构。

2. 传统 CI/CD 在智能体时代的崩溃原因

2.1 人类开发者 vs AI 智能体的开发行为差异

人类开发模式：
每周仅提交 1~2 个 Pull Request (PR)。
团队成员需要花费大量时间进行代码审查（Code Review）。
依赖 GitHub Actions 运行耗时较长的"构建-测试-部署"流水线。
流程具备高可预测性，本地缓存通常保持"温热（Warm）"状态。
AI 智能体开发模式：
无限扩展的并发量 ：单个智能体可以瞬间创建 N 个代码库的 N 个 PR。
分支爆炸：产生数以千计的短生命周期分支（Short-lived branches），同时将同一个代码库拉向不同的演进方向。
代码冲突灾难：由于变更速率呈指数级增长，将这些不同版本合并（Merge）在一起变得几乎不可能。
近期 GitHub 的实际提交（Commits）数量以及代码行数的增加/删除出现了惊人的暴涨，验证了这一趋势。

2.2 串行锁与数据库级串行化瓶颈

传统的 PR 是专门为"人类审查"和"延迟反馈"设计的离散交付单元。
在智能体高频提交的背景下，代码仓库的"合并（Merging）"行为变得非常类似于高性能数据库中的串行化（Serialization）与单账本锁问题。
机器提交的间歇极短，若每次提交都需要锁定代码库并运行 15~45 分钟的传统 CI 测试，整个开发流将会被彻底卡死。

3. 演进路线：从"人类延迟"到"AI 循环"

演讲者将近期的技术演进划分为三个阶段：

阶段一：纯人类主导（~6个月前）

所有的代码由人类缓慢编写，打包成 PR，机器隐藏在人类高延迟的表象背后进行缓慢的静态验证。此时人类扮演了唯一的"智能体（Agent）"角色。

阶段二：人机协同的内部循环（当前现状）

代码生成变得极其廉价，代码编写更加连续（Continuous）。
工作流 ：从"意图与计划"出发 →\rightarrow→ 智能体（如 Cursor、Factory 等）拉取代码并实施计划 →\rightarrow→ 利用代码库现有资产在内部循环中快速构建和测试 →\rightarrow→ 智能体向人类询问"看起来如何？是否继续？" →\rightarrow→ 人类确认后进入合并队列。
局限性：由于外部验证（External Validation）仍需要人类参与，合并效率依然受限。

阶段三：全智能体闭环与多维平行世界（数周至数月内落地）

消除人类延迟：推理速度和内部验证（构建与测试）变得极快，不允许存在任何分钟级的等待。
多智能体对等审查 ：外部验证不再依赖人类，而是引入专注于不同领域的 AI 审查员（例如：安全专用 LLM 、API 一致性专用 LLM），在循环内部直接给主开发智能体提供反馈。
走向多宇宙（Multiverse）：因为代码库的最新提交（Tip of the ledger）处于高速移动状态，智能体将同时在多个平行 Commit 节点上尝试实施同一个计划，通过多路径探索寻求最佳合并解。

4. 新一代"持续计算"基础设施架构

为了支撑上述"全智能体闭环"，新型的软件开发基础设施必须具备以下四大核心要素：

复制代码

[输入流 (Intake)] ──> [流量整形/限流 (Ingress Shaping)]
                             │
                             ▼
                [有状态层/编排缓存 (Stateful Cache)] <──> [智能体开发/多LLM审查循环]
                             │
                             ▼
                [预合并队列 (Pre-merge Queue)] ──> [语义分组与人类最终审批] ──> [Git 主账本 (Ledger)]

1. 流量整形与限流（Ingress Shaping & Rate Limiting）

面对 AI 智能体激增的并发请求，基础架构的第一步必须进行入口流量控制，防止高频调用冲垮下游服务。

2. 有状态的常驻环境（Stateful & Incremental Compute）

缓存即编排：计算环境不能再像过去那样，每次触发 CI 就从零开始（Scratch）初始化虚拟机或容器。
智能体需要在一个具备记忆和状态（Stateful）的持久化环境中工作，类似于人类工程师常驻的本地工作站，采用完全"增量式（Incremental）"的方式进行编译与验证。

3. 预合并队列（Pre-merge Queue / Pre-Q）

由于大量智能体在并行操作代码，变更不能直达 Git 仓库。
系统设立一个"预合并队列"，动态调整和协调并行的变更，解决语义冲突并进行串行化调整，确保所有的提交能严丝合缝地写入 Git 账本（Ledger）。

4. 人类角色的升华：高层治理（Governance）

人类不再去审查具体的一行行代码（因为 PR 的数量庞大到人类无法看透）。
人类将主要审查"意图（Intent）与结果（Result）"的一致性（例如：观看 AI 自动生成的业务功能运行视频、阅读安全 LLM 的合规报告汇总）。人类拥有最终的审批权，且一个审批可以同时作用于批量打包的多个智能体变更。

5. 总结：CI 并没有消失，而是被重构

演讲最后强调，持续集成（CI）的原则并没有过时，但其形式已经发生了根本性转变：

验证代码是否正常运行不再是一个独立的"阶段（Phase）"，而是完全融入到了智能体每一步迭代的内部循环中。
保证代码一致性与合规性的约束将成为"持续常驻（Continuous Basis）"的底层策略。
资源消耗（计算力与存储需求）将会迎来爆发式增长，因此未来的核心竞争在于如何维持该闭环的高效能与低延迟运行。