昨晚在电子书上读到一段关于 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 有用。关键是:
- 核心路径有测试:Agent 最常修改的模块必须有测试保护
- 测试运行快:如果跑一次测试要 30 分钟,Agent 的效率会被严重拖累
- 测试稳定: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,我的建议是:
- 先用上面的工具评估你的基础设施成熟度
- 如果低于 Level 3,先别急着上 Agent,先补基础设施
- 如果已经在 Level 3 以上,开始小范围试验 Agent
- 无论哪个级别,持续投资基础设施——它是 Agent 能力的放大器
记住:好的人类工程基础设施,就是好的 AI 工程基础设施。
这不是 AI 时代的新道理。这是软件工程的老道理,只是在 AI 时代变得更加显而易见。
你的项目处于 IRMA 的哪个级别?你在建设基础设施的过程中遇到过什么坑?欢迎留言讨论。