基础设施比模型更重要:Stripe Minions 给 AI Agent 落地的启示

Why Engineering Infrastructure Matters More Than Model Choice for AI Agents

昨晚在电子书上读到一段关于 Stripe Minions 的文字,让我停下来想了很久。

不是因为它用了什么惊艳的模型,而是因为它揭示了一个被大多数人忽略的事实:

Minions 能 work 的首要原因跟 AI 模型本身几乎无关,而是 Stripe 在 LLM 出现之前就为人类工程师建设了多年的基础设施。

完整的代码树、成熟的构建系统、全面的测试覆盖、标准化的开发环境——这些不是为 AI 准备的,是十多年来为人类工程师准备的。AI Agent 到来时,直接继承了这套基础设施。

好的人类工程基础设施,就是好的 AI 工程基础设施。

一、问题的本质:为什么大家都在问模型?

当一家公司宣布他们的 AI Agent 每周能产出 1300 个 PR 时,大多数人的第一反应是:

  • 用了什么模型?
  • 参数量多大?
  • 微调了没有?
  • Prompt 怎么写的?

这很自然。模型是可见的、可比较的、可讨论的。你可以说 GPT-4 比 Claude 3 强,可以说 70B 比 7B 好,可以争论 fine-tuning 的 learning rate。

但基础设施是不可见的。

你不会在 Twitter 上看到有人讨论「我们的 Bazel 构建缓存预热策略让 Agent 效率提升了 10 倍」。你也不会在技术大会上听到「标准化 devbox 是我们 Agent 落地的关键」。

然而,正是这些不可见的东西,决定了 Agent 能不能跑起来。

我在 让 AI 自己写 Skill:可进化 Agent 的设计原理与最佳实践 中提到过,Agent 的能力不仅取决于模型,更取决于它能调用的工具和记忆系统。基础设施就是这个逻辑的延伸——它是 Agent 运行的「物理环境」。

二、AI Agent 基础设施成熟度模型

基于 Stripe 的实践和我们在钉钉的经验,我总结了一个 AI Agent 基础设施成熟度模型(Infrastructure Readiness Model for AI Agents, IRMA)

这个模型分为四级:

┌─────────────────────────────────────────────────────────────────┐
│                    IRMA 成熟度模型                               │
├──────────────┬──────────────────────────────────────────────────┤
│  Level 4     │  Autonomous Ready                                │
│  自治级      │  • 全自动化测试覆盖(>80%)                       │
│              │  • 一键部署 + 自动回滚                            │
│              │  • 标准化开发环境(devbox/容器)                   │
│              │  • 构建缓存 + 依赖缓存预热                        │
│              │  • 代码规范自动检查(lint/format)                 │
│              │  → Agent 可以独立开发、测试、提交 PR              │
├──────────────┼──────────────────────────────────────────────────┤
│  Level 3     │  Assisted Ready                                  │
│  辅助级      │  • 核心模块有自动化测试                           │
│              │  • CI/CD 流水线稳定                               │
│              │  • 开发环境可复现(Docker/devcontainer)          │
│              │  • 构建时间可接受(<10分钟)                      │
│              │  → Agent 可以辅助开发,需要人工 review            │
├──────────────┼──────────────────────────────────────────────────┤
│  Level 2     │  Experimental Ready                              │
│  实验级      │  • 有基本的 CI(能跑测试)                        │
│              │  • 开发环境靠文档描述                             │
│              │  • 构建时间较长(>30分钟)                        │
│              │  • 测试覆盖率低(<30%)                           │
│              │  → Agent 只能做简单任务,经常失败                 │
├──────────────┼──────────────────────────────────────────────────┤
│  Level 1     │  Not Ready                                       │
│  未就绪      │  • 没有自动化测试                                 │
│              │  • 没有 CI/CD                                     │
│              │  • 开发环境「在我机器上能跑」                      │
│              │  • 构建靠手动                                     │
│              │  → Agent 完全无法工作                             │
└──────────────┴──────────────────────────────────────────────────┘

这个模型的核心洞察是:Agent 的能力上限 = 基础设施的成熟度 × 模型的能力

如果基础设施是 Level 1,即使用 GPT-5,Agent 也跑不起来。如果基础设施是 Level 4,即使只用 GPT-3.5,Agent 也能产出可观的成果。

我在 企业打造AI原生组织:六维转型模型的落地路径 中讨论过组织层面的转型。基础设施成熟度是那个模型中「工程实践」维度的具体化。

三、Stripe 的 devbox:为什么 10 秒启动如此关键?

回到开头那段文字。

每个 Minion 运行在一个叫 devbox 的东西上。标准化的 AWS EC2 实例,预装了 Stripe 的完整代码树、预热的 Bazel 构建缓存和类型检查缓存。从热启动池(warm pool)启动一个 devbox,不到 10 秒。

这 10 秒意味着什么?

让我们算一笔账:

  • 假设一个 Agent 任务需要启动 devbox、运行构建、执行测试、提交结果
  • 如果启动需要 10 秒,构建 2 分钟,测试 3 分钟,总耗时约 5 分钟
  • 如果启动需要 5 分钟(冷启动),构建 10 分钟(无缓存),测试 10 分钟,总耗时约 25 分钟

5 倍的时间差距,意味着 5 倍的吞吐量和 5 倍的成本差异。

更重要的是,10 秒的启动时间让 Agent 可以 按需创建、用完即销毁。这种无状态的设计让系统具备了弹性伸缩的能力——高峰期可以同时运行数百个 Minion,低谷期可以缩减到几个。

这正是我在 解构 Agent CLI:从 React 子进程到 Python 回调的通信协议 中讨论的架构理念的云端版本:Agent 的运行环境必须是轻量级、可复现、可伸缩的。

四、如何评估你的基础设施成熟度?

理论说完,我们来看实践。下面是一个简单的 Python 工具,用于评估你的项目处于 IRMA 的哪个级别:

from dataclasses import dataclass, field
from enum import Enum
from typing import Optional
import subprocess
import os


class IRMALevel(Enum):
    """AI Agent Infrastructure Readiness Model levels."""
    NOT_READY = 1
    EXPERIMENTAL = 2
    ASSISTED = 3
    AUTONOMOUS = 4


@dataclass
class InfrastructureScore:
    """Assessment result for infrastructure readiness."""
    level: IRMALevel
    details: dict[str, bool]
    recommendations: list[str] = field(default_factory=list)

    def summary(self) -> str:
        """Generate a human-readable summary."""
        passed = sum(1 for v in self.details.values() if v)
        total = len(self.details)
        return (
            f"IRMA Level: {self.level.name} ({self.level.value}/4)\n"
            f"Checks passed: {passed}/{total}\n"
            f"Recommendations:\n" +
            "\n".join(f"  - {r}" for r in self.recommendations)
        )


def check_ci_cd() -> bool:
    """Check if CI/CD pipeline exists."""
    ci_indicators = [
        ".github/workflows",
        ".gitlab-ci.yml",
        ".circleci",
        "Jenkinsfile",
    ]
    return any(os.path.exists(p) for p in ci_indicators)


def check_test_coverage(threshold: float = 0.3) -> bool:
    """Check if test coverage meets threshold.

    This is a simplified check. In practice, you'd parse
    coverage reports or run coverage tools.
    """
    test_dirs = ["tests", "test", "__tests__", "spec"]
    has_tests = any(os.path.isdir(d) for d in test_dirs)
    # Rough heuristic: if test dir exists, assume basic coverage
    return has_tests


def check_dev_environment() -> bool:
    """Check if development environment is reproducible."""
    indicators = [
        "Dockerfile",
        "docker-compose.yml",
        ".devcontainer",
        "devbox.json",
        "flake.nix",
        "shell.nix",
    ]
    return any(os.path.exists(p) for p in indicators)


def check_build_cache() -> bool:
    """Check if build caching is configured."""
    cache_indicators = [
        "bazel.rc",  # Bazel remote cache
        ".gradle/caches",  # Gradle
        "target/dependency",  # Maven
        "node_modules/.cache",  # Node.js
    ]
    return any(os.path.exists(p) for p in cache_indicators)


def check_auto_lint() -> bool:
    """Check if automated linting/formatting is configured."""
    lint_indicators = [
        ".pre-commit-config.yaml",
        ".eslintrc",
        ".pylintrc",
        "ruff.toml",
        ".black",
        "pyproject.toml",
    ]
    return any(os.path.exists(p) for p in lint_indicators)


def assess_infrastructure() -> InfrastructureScore:
    """Assess current project's infrastructure readiness for AI Agents.

    Returns:
        InfrastructureScore with level, details, and recommendations.
    """
    checks = {
        "ci_cd": check_ci_cd(),
        "test_coverage": check_test_coverage(),
        "dev_environment": check_dev_environment(),
        "build_cache": check_build_cache(),
        "auto_lint": check_auto_lint(),
    }

    passed = sum(1 for v in checks.values() if v)
    recommendations = []

    if not checks["ci_cd"]:
        recommendations.append("建立 CI/CD 流水线(GitHub Actions / GitLab CI)")
    if not checks["test_coverage"]:
        recommendations.append("增加自动化测试覆盖(目标 >30%)")
    if not checks["dev_environment"]:
        recommendations.append("标准化开发环境(Docker / devcontainer / devbox)")
    if not checks["build_cache"]:
        recommendations.append("配置构建缓存以加速重复构建")
    if not checks["auto_lint"]:
        recommendations.append("配置自动代码检查和格式化(pre-commit hooks)")

    # Determine level
    if passed >= 5:
        level = IRMALevel.AUTONOMOUS
    elif passed >= 3:
        level = IRMALevel.ASSISTED
    elif passed >= 2:
        level = IRMALevel.EXPERIMENTAL
    else:
        level = IRMALevel.NOT_READY

    return InfrastructureScore(
        level=level,
        details=checks,
        recommendations=recommendations,
    )


if __name__ == "__main__":
    score = assess_infrastructure()
    print(score.summary())
# generated by hugo AI

这个工具虽然简单,但它提供了一个 可操作的起点。你可以在任何项目目录下运行它,快速了解当前的基础设施状态。

五、从 Level 2 到 Level 4:建设路径

评估只是第一步。更重要的是如何提升。

5.1 第一优先级:标准化开发环境

这是投入产出比最高的一步。

我在 把组织当成产品来打造:AI 原生组织的 MVP 设计 中提到,组织 MVP 的第一个版本应该是「最小可行的协作系统」。开发环境标准化就是这个系统在工程层面的体现。

推荐方案:

方案适用场景启动时间学习成本
Docker + devcontainer通用,VS Code 生态30秒-2分钟
devbox (Jetify)Nix 生态,多语言项目10-30秒
Nix flake极致可复现5-15秒
自定义脚本简单项目不确定

选择哪个方案不重要,重要的是 每个工程师(和每个 Agent)都能在 1 分钟内获得一致的开发环境

5.2 第二优先级:测试覆盖

没有测试的项目,Agent 不敢改代码。

这里有一个反直觉的观察:测试覆盖率不需要达到 100% 才能让 Agent 有用。关键是:

  1. 核心路径有测试:Agent 最常修改的模块必须有测试保护
  2. 测试运行快:如果跑一次测试要 30 分钟,Agent 的效率会被严重拖累
  3. 测试稳定:flaky test 比没有测试更糟,因为它会让 Agent 产生误判

5.3 第三优先级:构建缓存

这是 Stripe devbox 的核心秘密。

Bazel 的远程缓存可以让增量构建从分钟级降到秒级。类似的,其他构建工具也有缓存机制:

  • Gradle: build cache + configuration cache
  • Maven: local repository + Takari lifecycle
  • npm/pnpm: node_modules cache + hardlink
  • Rust: sccache + cargo-chef

缓存的本质是 用空间换时间。对于 Agent 来说,时间就是成本。

六、为什么基础设施比模型更重要?

回到核心论点。

模型在快速 commoditize。今天的 GPT-4 能力,明天可能就是开源模型的基线。模型的进步是 指数级的、不可控的、不需要你操心的

但基础设施不是。

基础设施是 线性的、可控的、需要你自己建设的。它不会因为你换了一个模型就自动变好。它需要一天一天、一个 PR 一个 PR 地积累。

更重要的是,基础设施的收益是复利的

  • 好的测试覆盖让今天的 Agent 更安全,也让明天的 Agent 更强大
  • 好的构建缓存让今天的 Agent 更快,也让明天的 Agent 更便宜
  • 好的开发环境让今天的 Agent 能跑,也让明天的 Agent 能 scale

这就是为什么 Stripe 能在 LLM 出现后迅速部署 Minions——他们不需要为 AI 重新建设基础设施,他们只需要让 AI 接入已有的基础设施。

七、行动建议

如果你正在考虑引入 AI Agent,我的建议是:

  1. 先用上面的工具评估你的基础设施成熟度
  2. 如果低于 Level 3,先别急着上 Agent,先补基础设施
  3. 如果已经在 Level 3 以上,开始小范围试验 Agent
  4. 无论哪个级别,持续投资基础设施——它是 Agent 能力的放大器

记住:好的人类工程基础设施,就是好的 AI 工程基础设施。

这不是 AI 时代的新道理。这是软件工程的老道理,只是在 AI 时代变得更加显而易见。


你的项目处于 IRMA 的哪个级别?你在建设基础设施的过程中遇到过什么坑?欢迎留言讨论。


See also