AI 部署基准怎么读：别只比较“成功率”，还要算上人工步骤与安全成本
AI 编码 Agent 能把应用写出来，不代表它已经能独立交付。真正的部署链路还包括云端凭证、资源配置、上线验证和清理；只看生成代码，容易把“能写”误认为“能上线”。开源项目 ai-deploy-bench 把问题做成可复查的实验：让 Claude Code 按同一份规格构建并部署应用，再由独立验证流程检查线上结果。
它测量的不是单一速度
仓库最新一次完整运行记录于 2026 年 10 月 13 日，使用 Claude Code 2.1.296 与 Opus 5.5，在 Cloudish、DigitalOcean、Render、Vercel 上测试五类应用：静态站、CRUD 应用、API、数据可视化和实时协作应用。摘要表同时展示部署成功、人工介入、构建与部署时间、Token、Agent 成本、托管费用及安全合规评分。
这组指标特别适合揭示“成功”背后的差异。例如该次表格中，Render 为 5/5 成功、需要 2 个人工步骤；Vercel 为 4/5，且安全与合规评分为 76/100。项目把成功定义为通过该应用的全部必需检查，而不是仅仅返回一个可访问 URL。不同云服务也不能只按单次实验排名：项目明确提供多个运行结果，并提示样本规模有限，结果需要结合方法与重复试验理解。
实验如何降低“看起来成功”的假象
流程把工作拆成构建、部署、资源清点、线上验证、安全审查、拆除和结果归档。Agent 先在空工作区实现应用并做本地测试；部署阶段才提供云端凭证。之后验证器通过公开 URL 检查应用行为，检查范围可能包括 HTTP、WebSocket/SSE 与浏览器交互；安全审查另由独立 Claude Code 会话完成。结束时清理云资源，并把逐项结果提交到仓库。
五类应用不是随意挑的提示词，而是有可验证契约的任务：例如 CRUD 应用检查账户隔离和持久化，API 检查密钥、OpenAPI 与限流，实时应用检查消息传递和房间隔离。这样做的价值在于，评估对象从“模型说自己完成了”变成“外部测试能否证明它完成”。
项目 README 中的最新结果是一次特定配置下的观察，不是云平台的普遍能力保证。像安全评分、成本与耗时都会受任务、模型、套餐价格和实验时间影响。尤其托管月费分为轻量与繁忙场景，不能把某一列数字直接当作所有团队的账单预测。
如何自己复现实验
仓库提供 GitHub Actions 工作流。先按 docs/setup.md 准备所需账户和 API Token，再把凭证配置为 Actions secrets；Smoke test 会用 stub 替代 Claude Code，避免消耗模型额度，同时运行其余步骤。正式实验可从 Actions 页面启动，也可用 gh workflow run 指定云平台、应用子集或重复次数。每个单元的详细记录、报告和截图会写入 results/runs/，方法定义见 docs/methodology.md。
# 先复制模板并填写凭证；.env 已被仓库忽略 cp .env.example .env scripts/set-secrets.sh # 无模型费用的冒烟测试 # gh workflow run benchmark.yml -f smoke_test=true # 只测试 Vercel 上的静态站与 API # gh workflow run benchmark.yml -f clouds=vercel -f apps=static,api
另一个重要边界是安全：实验会实际创建云资源并使用密钥，复现者应先用隔离的测试账户、最小权限凭证和预算上限；确认清理工作流可用后再跑正式测试。
对团队最实用的启发
当团队要评估自家 Agent，不必第一天就复制四个平台和五类应用。先选一条最常见交付路径，写出外部可验证的验收条件：部署后健康检查、关键页面操作、数据持久化、权限边界、资源清理。记录人工步骤和等待时间，并把模型成本与云资源成本分开。这样比“这次部署成功了”更容易定位瓶颈：是 Agent 不会配置、平台需要人工确认，还是验证与安全环节尚未自动化。
ai-deploy-bench 的核心贡献不是宣称某个平台或模型胜出，而是提供一套可审计的比较框架。把失败、人工动作和安全审查也纳入指标，才能判断 AI Agent 是否真的减少了交付成本。
相关链接