给 AI 编码团队用的运行时 broker，把测试和生成代码放进带签名、可审计的 sandbox，在割裂的云容量之间调度。

1. 企业采用 AI 编码，已经在制造一类新的高 runtime 强度工作负载，而不只是多几次聊天调用。
2. 买方现在开始在意 AI 生成代码能否安全执行，因此隔离 sandbox 不再是加分项，而是必备原语。
3. 尖锐的容量短缺和 13 家合作方组成的供应链，让多 provider brokerage 的价值突然变得很实，因为对单一供应商的依赖已经开始失灵。
4. Modal 的估值重估说明，资本市场预期 agent runtime 这一层会长成独立大类，因此仍给聚焦型的中立 broker 留了空间。

催化因素。 正是这波把 Modal 从 $60M ARR 推到 $300M ARR、并逼着它接 13 家基础设施伙伴的企业 AI 编码浪潮，也在逼买方立刻补上“多 provider、策略安全”的执行层；否则单一供应商很快就会成为瓶颈。

产品夹在编码 agent 与基础设施 provider 之间，既是控制平面，也是执行层。开发者或平台团队先定义好批准过的基础镜像、secret 边界、网络策略和成本上限；随后 broker 会按延迟、合规和实时容量，把每个任务拉起到最合适的 provider 上，并放进带签名的 sandbox 里执行。它还能把 build layer 和测试产物的缓存跨 provider 复用，所以面对突发高峰时，成本和速度都比简单做云容灾更好。每次运行都会留下可回放的轨迹，说明执行了哪段代码、调用了哪些工具、暴露了哪些 secret、以及最终跑在哪个 provider 上。这让产品同时能打动两类人：一类想把 agent 扩到更多团队的平台团队，另一类是不愿盲信 agent 的安全团队。

差异化。 传统 CI 厂商管的是可信开发者工作流和固定 runner；serverless GPU 云卖的是裸执行容量。这家公司要解的是另一个控制问题：如何为不受信任的 AI 生成代码，同时做好策略执行、可复现的 sandbox 打包，以及实时容量 brokerage。时间一长，它还能沉淀出跨 provider 的可靠性与价格地图，知道什么工作负载该往哪儿路由，这层路由智能会越来越难替代。

待完成任务

flowchart LR
  Buyer[VP Platform Engineering] --> Pain[Agent PRs overload CI and raise sandbox risk]
  Pain --> Product[Policy-aware burst runtime broker]
  Product --> Outcome[Faster agent rollout with auditable multi-cloud execution]

高管要点

• AI 编码正在把基础设施需求从静态 CI 容量，推向可治理的执行环境——后者专门承接不受信任的 agent 生成代码。
• 买方缺的并不只是裸算力，而是已过策略审批的爆发容量、可溯源能力，以及跨多家 provider 的网络安全执行层。
• 现有厂商分散在 CI 在位者、点状 sandbox runtime 和 CI 加速层三类里，给一个中立的治理与路由 broker 留出了空白。
• 创业公司只有把“安全吞吐”和“多云可靠性”卖出去，而不是沦为更便宜的 runner 池，才有机会赢。

市场定义

面向 AI 编码与 agent 工作流的受治理执行基础设施：它负责把编码 agent 触发的 build、测试、浏览器检查和生成代码任务打包、调度、隔离，并拿出可证明的执行结果。

用户与买方

最核心的使用者，是负责 CI、runner 策略、网络边界和 secret 管理的平台团队或 AI 基础设施团队。经济买方通常是平台主管工程 VP 或相近的内部 AI 平台 owner；因为工作负载里包含不受信任的 agent 生成代码，所以安全与合规团队会共同审批。

购买触发点

• 当 agent 生成的 PR 开始与人工编写的 CI 共享同一批 runner 池时，平台团队会明显感到排队、编排和清理工作正在拖累可靠性。 [20][21][22][26][31]
• 一旦工作负载里包含不受信任的 agent 代码，安全审查就会陡然升级，因为 secret、出网和宿主复用都会变成采购卡点。 [25][28][39][43][48]
• 发布周、评测批处理和多分支 rollout 会制造爆发需求，而单一 runner 池或单一云都不适合吃这种尖峰。 [1][2][31][35]

支付意愿

直接替代方案已经把“按用量为受治理执行付费”这件事正常化了：E2B 和 Daytona 都公开了约 $0.000028/秒的 2-vCPU sandbox 定价，Depot 公布 2-vCPU GitHub Actions runner 为 $0.004/分钟，Modal 则按秒收 core 和 GiB 费用。只要 broker 能在这条基线之上，把排队、闲置峰值容量和安全审查人力明显降下来，它的付费逻辑就站得住。 [3][11][14][15]

品类动态

增长信号 19.7%-24.0% CAGR across adjacent DevOps and AI code tools markets

验证信号

• Modal 表示 sandboxes 已贡献超过三分之一收入，平台累计启动超过 10 亿个 sandbox，说明 runtime 需求不是 demo 级别，而是实打实的线上需求。
• Claude Code 明确宣传自己能读代码、跑测试和开 PR，这意味着执行基础设施已成为 agent 产品表面的一部分。
• Codex 也把 git、包管理器和测试 runner 等子命令放进同一层 sandbox 边界里，说明执行控制本来就是 agent 编码产品的核心组件。
• JetBrains 2026 AI Pulse 显示，90% 的开发者在工作中至少使用一种 AI 工具，74% 使用专门的 AI 开发工具，未来需求底盘会继续扩大。

监管与技术约束

• 只要生成代码会碰到云资源或内部系统，短时凭证与最小权限访问就是入场券。
• 溯源与签名 attestation 正在成为构建产物和 SBOM 的默认控制面。
• 在多租户环境里执行不受信任代码时，共享企业环境往往需要比默认容器更强的隔离。
• 为了降低污染与可复现性风险，临时构建环境正越来越取代可复用宿主机。

竞争大体分成三堆：Git 为中心的 CI 在位厂商、专门做 sandbox 的 runtime，以及 CI 加速厂商。真正的白地带，是一层中立治理层，能跨这些栈去做路由，而不是强迫客户整套替换。

为什么现有厂商不会默认胜出

• 云构建服务. hyperscaler 的构建服务能减少 runner 运维，但它们天然绑定单一 provider；默认并不能解决跨多云的中立路由，也做不到在既有 CI 体系上统一策略。
• Git 型 CI 平台. GitHub 一类的 CI 已经深度嵌进开发流程，但面对爆发式 agent 流量，团队仍得在受限的托管容量、付费大 runner 和自建 ARC 复杂度之间做取舍。
• Sandbox 专业厂商. 点状 sandbox 厂商把安全执行这件事做得不错，但它们大多仍是单一 runtime，而不是能跨已批准云、企业网络和既有 CI 控制层做中立 brokerage 的平台。
• CI 加速厂商. CI 加速厂商证明了买方愿意为更快执行付费，但它们优化的是自己托管的 runner 栈，而不是在异构 execution provider 之间做受策略治理的路由。

Agent Runtime Burst Broker 的第一站，不该是替代 GitHub Actions、云构建服务或某家 sandbox 厂商，而应当先做一层受策略约束的溢出执行层，卖给那些已经把内部编码 agent 推开、现在又被 agent 生成 PR 挤爆 CI 队列的 500-2,000 人 B2B 软件团队。第一款产品的边界要很清楚：只拦截 agent 触发的 build、集成测试、浏览器检查和部分生成代码任务，把它们封进带签名的临时 sandbox，再在已批准的 provider 之间路由，并留下可回放的审计轨迹。这个滩头故意做窄，因为一旦同一个平台团队已经在发布周扛排队高峰、安全审查摩擦和突发容量超支，买方、触发点和 ROI 就最清楚。按研究测算，只要公司先守在中大型软件团队，就有约 $1.1B TAM、$264.6M 初始 SAM 和 $7.9M 的第 3 年 SOM，之后还能往更广的 agent runtime 工作负载扩。GTM 也别卖“更便宜的算力”，而要卖安全吞吐和爆发可靠性：用付费 BYOC pilot 证明排队时间下降、执行轨迹完整、采购更容易过。只有当公司能成为在位厂商天然不给的那层“中立治理与路由层”，跨既有 CI 体系和多朵云同时成立，才有机会赢。最关键的反证风险也很明确：只做 overflow 也许撑不起预算；在位厂商也可能把相近的策略能力打包进去；早期买方还可能一上来就要求 GPU、浏览器或 VPC 能力，超出初始工作负载范围。因此，前 12 个月必须证明三件事：买方愿不愿为 agent 专用执行池付费，BYOC 能否明显缩短安全审查，以及跨 provider 路由在延迟、成本或审批时间上，能否真胜过单一供应商基线。

问题

• 随着内部编码 agent 从给建议走到直接创建 PR，agent 生成的 build、集成测试和浏览器检查开始与人工 CI 抢同一批 runner，而现有 runner 池根本不是按这种高峰设计的。
• 只要不受信任的 agent 代码需要接触高权限系统，安全与合规团队就不会轻易放行；他们要的是隔离、可审计，以及明确绑定网络、secret 和溯源控制的执行环境。

解决方案

• 在编码 agent 与执行基础设施之间插入一个具备策略感知的控制平面，让每个 agent 任务都运行在带签名的临时 sandbox 里，并强制使用批准过的基础镜像、短时凭证、明确的出网规则和可回放的执行轨迹。
• 把 CPU、浏览器、以及后续 GPU 工作负载路由到多家已批准的 provider，上线第一步只做 agent 专用 overflow 池，和客户现有 CI 工作流并存，而不是一上来就推翻重建。

为什么我们会赢

• GitHub Actions、云构建服务和 sandbox 厂商各自都只覆盖工作流的一部分，但没有谁天然拥有跨多 provider、跨客户既有 CI 体系的中立治理、溯源和路由层。
• 每一次线上运行，都会继续沉淀工作负载形态、冷启动、失败模式、缓存行为和策略结果的数据；这会让路由质量和审计能力比单一 provider runtime 更快迭代。

里程碑

flowchart LR
  Wedge[Agent-only overflow wedge] --> MVP[Signed sandbox MVP]
  MVP --> Proof[Queue and audit proof]
  Proof --> Expansion[Broader governed runtime]

创始团队

实验路线图

风险评估

必须成立的条件

• 至少 30% 的合格滩头账户，愿意在不替换现有 CI 栈的前提下，购买一层 agent 专用 overflow 执行层。
• 前 3 个付费 pilot 能把 agent 生成任务的中位排队时间至少压低 30%，同时保持完整执行可追溯性。
• 安全和采购团队接受 BYOC、短时凭证与审计导出，认为这足以构成第三方路由的控制边界。
• 早期大多数工作负载都能靠 CPU 与浏览器导向的执行层承接，因此公司可以推迟 GPU 密集型架构，而不至于错过购买触发点。
• 至少一半付费 pilot 能转成年 ARR 超过 $80k 的合同，因为买方把产品看成控制层，而不是廉价 runner 池。

待尽调问题

• 第一批买方更想要 overflow-only 部署，还是更想顺手迁走整套 CI 与 sandbox？
• 什么证明材料最常用来撬开采购：attestation、network trace、secret access log，还是 customer-cloud 部署？
• 前 90 天的主工作负载到底是什么：集成测试、浏览器检查、生成代码执行，还是 GPU 任务？
• 在位替代方案里，最常见的是优化 GitHub Actions、采购点状 sandbox，还是内部平台团队自己做？
• 第一单预算最可能挂在开发者效率、AI 平台、云基础设施，还是安全工具？

模型合理性

• 收入引擎. 基准情形下的收入，来自付费账户数从 Y1 结束时的 4 个增至 Q4Y3 的 30 个，同时综合年化 ARPU 随合同转化与扩张，从相当于 pilot 的 $36K 抬到 $165K。
• 必须成立的前提. BYOC 和短时凭证必须按时过安全审查，因为在所有敏感项里，销售周期对 Y3 收入和现金风险的影响最大。
• 模型失真条件. 如果采购再拖一个季度、同时毛利率卡在 65-68%，模型就会明显承压，现金低点会在下一轮融资前逼近零。
• 下一轮融资证明. 一旦公司做到大约 8-12 个生产客户，部署流程可重复、安全审查可引用，并能看到第二条工作流扩张，下一轮融资就有了充分依据。

情景

敏感性

flowchart LR
  Leads[Triggered platform teams] --> Pilots[Paid BYOC pilots]
  Pilots --> Customers[Production customers]
  Customers --> Revenue[Subscription plus usage revenue]
  Revenue --> GrossProfit[Gross profit]
  GrossProfit --> Cash[Cash runway]

警示项: Y1 收入只有 $65.5K，但 EBITDA burn 达 $919.5K，因此在年度生产合同开始复利前，公司必须严控纪律。 · Rule of 40 看起来异常高，主要是因为 Y3 增长是拿不到 $1M 的 Y2 基数来算，而不是成熟规模。 · 模型默认 BYOC 能过安全审查，且不用被迫改成 customer-hosted 控制平面；若这一点不成立，销售周期和服务负担都会明显变差。

• 在位厂商打包. 云 runtime 供应商或 hyperscaler 可能补上足够多的策略与路由能力，缩小差异化空间。 缓解措施: 把重点放在中立的多 provider 治理、跨厂商审计，以及单一 provider 结构上难以提供的工作负载可移植性上。
• 采用节奏偏慢. 如果企业始终把编码 agent 关在有限 pilot 里，工作负载规模可能来不及支撑一层新的 runtime 产品。 缓解措施: 先挑已经看到 CI 饱和的客户，把定价锚在立刻可见的排队时间与容量节省上，而不是远期转型承诺。
• 安全证明负担. 买方可能不愿把不受信任代码执行和敏感 build 上下文交给一个新的中间层。 缓解措施: 从第一批共创客户开始，就提供带签名的 sandbox 模板、严格的 secret 范围控制、可回放轨迹，以及第三方安全证明。