@yibie: 推荐这个短小但精准的观察。Agent 越来越多跑在临时 sandbox 里，但所有 sandbox 提供商都在优化"启动到能执行命令"的时间（中位数 690ms）。Matt Rickard 指出：真正被忽视的瓶颈不是启动——是把代码 cl…

X AI KOLs Timeline 工具
agent sandbox git-clone performance-bottleneck corigin infrastructure

摘要

文章指出AI Agent在临时sandbox中运行时，git clone已成为新瓶颈（常需数秒），而Matt Rickard开发的Corigin通过重建git读路径将clone时间降至184-646ms，比sandbox启动（690ms TTI）还快。

推荐这个短小但精准的观察。Agent 越来越多跑在临时 sandbox 里，但所有 sandbox 提供商都在优化"启动到能执行命令"的时间（中位数 690ms）。Matt Rickard 指出：真正被忽视的瓶颈不是启动——是把代码 clone 进去。一个普通仓库的 git clone 需要好几秒。他正在做一个叫 Corigin 的解决方案，针对 agent sandbox 场景从头重建了 git 的读路径，把 clone 降到 184-646ms——比 sandbox 启动还快。 Clone 是 Agent 的新瓶颈 Agent 越来越多地在临时 sandbox 中工作。AI 应用构建器、代码执行、并行云 agent——在仓库就位之前它们什么都做不了。 ComputeSDK 测了前十 sandbox 提供商的"交互时间"（TTI）中位数：690ms。但 TTI 只衡量 sandbox 能执行命令的时间。它不算把代码弄进去的时间。对大多数仓库，从头 clone 需要好几秒——这相当于好几次 sandbox 启动。 最简单的方法：别 clone 最简单的方案是跳过 clone：挂一个持久化磁盘或网络文件系统，把仓库放上面。挂载时间几乎是零——对一个 sandbox 同时做一个任务来说，这是最优方案。 但磁盘是共享的、可变的状态。即使缓存让文件操作很快，每个 sandbox 都在同一个文件系统上工作。并行 agent 需要隔离。一旦你的提供商的答案变成快照或"分支"磁盘，你就在从头重新发明版本控制——分支、合并、历史。Git 已经解决了跨每种提供商的分布式状态。快速 clone 让仓库仍然是一个真正的 Git remote：每个 sandbox 在本地磁盘上物化自己的隔离副本，做完工作，用正常的 git push 推回去。 改善 git clone 对小仓库，Corigin 在 sandbox 启动之前就能完成一次完整 clone：中位数 184-646ms，而 TTI 中位数是 690ms。 我（Matt Rickard）正在开发 http://corigin.dev https://corigin.dev——一个为 2026 年工作负载（sandbox 中的 agent）重建了读路径的程序化 git 服务器，目标是看 clone 能有多快。 代价 放弃了什么？ 1. 我们在 sandbox 外部预计算出 clone 计划，节省一次往返和约 155-370ms 2. 用自定义 clone 协议代替了标准 git，但最终产物是完全相同的 git 仓库 3. git push 稍微变慢了——那是我们预计算 clone 加速制品的时刻 4. 基准只测试了全量 clone——还不支持 shallow、blobless、treeless 或其他 clone 优化 为什么这事重要 如果 agent 工作流的标准是"每任务一个临时 sandbox"，那么 clone 延迟就成了每个 agent session 的固定入场费。Sandbox 启动优化已经快逼近极限了——690ms 的 TTI 很难再压。但 clone 有一个数量级的优化空间。这不是一个大市场，但对任何认真对待 agent 基础设施的人来说，这是一个该解决的问题。 原文：https://blog.matt-rickard.com/p/clone-is-the-new-bottleneck-for-agents… #Agent基础设施 #Git #Sandbox
查看原文
查看缓存全文

缓存时间: 2026/07/13 11:54

推荐这个短小但精准的观察。Agent 越来越多跑在临时 sandbox 里，但所有 sandbox 提供商都在优化“启动到能执行命令“的时间（中位数 690ms）。Matt Rickard 指出：真正被忽视的瓶颈不是启动——是把代码 clone 进去。一个普通仓库的 git clone 需要好几秒。他正在做一个叫 Corigin 的解决方案，针对 agent sandbox 场景从头重建了 git 的读路径，把 clone 降到 184-646ms——比 sandbox 启动还快。

Clone 是 Agent 的新瓶颈

Agent 越来越多地在临时 sandbox 中工作。AI 应用构建器、代码执行、并行云 agent——在仓库就位之前它们什么都做不了。

ComputeSDK 测了前十 sandbox 提供商的“交互时间“（TTI）中位数：690ms。但 TTI 只衡量 sandbox 能执行命令的时间。它不算把代码弄进去的时间。对大多数仓库，从头 clone 需要好几秒——这相当于好几次 sandbox 启动。

最简单的方法：别 clone

最简单的方案是跳过 clone：挂一个持久化磁盘或网络文件系统，把仓库放上面。挂载时间几乎是零——对一个 sandbox 同时做一个任务来说，这是最优方案。

但磁盘是共享的、可变的状态。即使缓存让文件操作很快，每个 sandbox 都在同一个文件系统上工作。并行 agent 需要隔离。一旦你的提供商的答案变成快照或“分支“磁盘，你就在从头重新发明版本控制——分支、合并、历史。Git 已经解决了跨每种提供商的分布式状态。快速 clone 让仓库仍然是一个真正的 Git remote：每个 sandbox 在本地磁盘上物化自己的隔离副本，做完工作，用正常的 git push 推回去。

改善 git clone

对小仓库，Corigin 在 sandbox 启动之前就能完成一次完整 clone：中位数 184-646ms，而 TTI 中位数是 690ms。

我（Matt Rickard）正在开发 http://corigin.dev https://corigin.dev——一个为 2026 年工作负载（sandbox 中的 agent）重建了读路径的程序化 git 服务器，目标是看 clone 能有多快。

代价

放弃了什么？

  1. 我们在 sandbox 外部预计算出 clone 计划，节省一次往返和约 155-370ms
  2. 用自定义 clone 协议代替了标准 git，但最终产物是完全相同的 git 仓库
  3. git push 稍微变慢了——那是我们预计算 clone 加速制品的时刻
  4. 基准只测试了全量 clone——还不支持 shallow、blobless、treeless 或其他 clone 优化

为什么这事重要

如果 agent 工作流的标准是“每任务一个临时 sandbox“，那么 clone 延迟就成了每个 agent session 的固定入场费。Sandbox 启动优化已经快逼近极限了——690ms 的 TTI 很难再压。但 clone 有一个数量级的优化空间。这不是一个大市场，但对任何认真对待 agent 基础设施的人来说，这是一个该解决的问题。

原文：https://blog.matt-rickard.com/p/clone-is-the-new-bottleneck-for-agents…

#Agent基础设施 #Git #Sandbox

Source: https://corigin.dev/

#git for agents

fast, scalable, git repo creation for agents.

##fast

  • -clone faster than GitHub
  • -push faster than GitHub

##scalable

  • -create thousands of repos
  • -fork branches in parallel

##for agents

  • -its just git, so agents know how to use it
  • -webhooks, GitHub sync, and a SDK
  • -mint temporary credentials for sandboxes

[Get started for free](/signup)

[Dashboard](/dashboard)

相似文章

@seclink: Agent 执行与通用代码执行的最大区别在于：Agent 执行需要极低的冷启动时间（毫秒级响应）、频繁的文件系统状态同步（Agent 需要读写中间代码、产出文件）以及灵活的 API/网络访问控制。 以下是精简后的两个核心推荐方案： 方案一…

X AI KOLs Timeline

该文讨论了Agent执行与通用代码执行的区别，并推荐了两种沙箱方案：基于Firecracker的E2B和基于Docker的OpenSandbox，分别适合生产级和私有化部署场景。