2026年6月16日，Cursor 在首次 Compile 大会上宣布 Origin——一个专为 AI Agent 构建的 Git 托管平台，演示了单仓库每秒 22.6 次提交的吞吐量。这是人类时代的 Git 基础设施从未设计过的负载。但就在 Cursor 搭建等待名单的时候，另一个答案已经上线运行了。
SmolForge，由 swyx（Shawn Wang）团队打造的 Agent 原生 Git 托管平台，在 Alpha 阶段就亮出了全部底牌：六个系统——Git 远程、CI/CD Actions、站点托管、Identity + AI 服务、对话转录与 Skills，以及每个仓库一个专属编码 Agent。它没有给 GitHub 加一层 AI 皮肤，而是从根上重建了代码托管的基础设施假设。
一个旧问题的新答案
Git 托管不是新赛道。GitHub 统治了十多年，GitLab 服务企业，SourceHut 服务极客。但过去两年，一个根本性的变化在悄悄发生：写代码的主体正在从人类变成 AI Agent。
2023年，AI 生成的代码还只是 IDE 补全建议。2024年，Cursor、Copilot 让 AI 写代码成为常态。2025年，Devin、OpenClaw 等独立编码 Agent 开始全天候工作。2026年，并行 AI Agent 架构兴起——一个仓库里同时有十几个 Agent 在不同分支上提交代码，互不等待。
问题来了：GitHub 是为人类协作设计的。PR 审查流程假设每个提交者都有判断力。Actions 假设构建频率以天为单位。Issues 假设人类会阅读和回复。当编码 Agent 以每小时数十次的频率提交代码时，这些假设全部崩溃。
SmolForge 的回应直接而彻底：把 Git 托管从“人类优先”改写成“Agent 优先”。
六个系统，一套哲学
打开 forge.smol.ai，页面干净得像一份设计文档。六个系统并列排开，每一行都标注着状态：Now、Ready、Next、Live。没有“即将推出”的模糊承诺，每一行都链接着可浏览的实例。
Git Remotes（状态 Now）：Smart HTTP 协议的远程仓库，支持 push/pull/clone，代码浏览、分支、issues、pull requests 一应俱全。这是基础层，但也是最薄的一层——SmolForge 真正的创新在更上层。
CI/CD Actions（状态 Ready）：每个提交触发隔离的构建任务，日志和制品精确绑定到 commit。与 GitHub Actions 最大的区别在于：它是为 Agent 的提交频率设计的，不是为人类每天 merge 几次设计的。
Sites（状态 Live）：全栈托管能力，静态站点和服务器应用都能部署。支持精确 SHA 预览、生产环境 promotion、回滚——而且回滚不需要重建旧源码，这在 Agent 高频迭代的场景下是救命级设计。
Identity + AI Services（状态 Bound）：站点级的身份认证和 AI 服务绑定，通过审核后的配置文件与仓库关联。每个部署的应用都能原生化使用 AI 能力，不需要额外配置。
Transcripts + Skills（状态 Active + Next）：这是 SmolForge 最独特的设计。编码 Agent 的完整对话记录被捕获，并链接到它们产生的 commit。Agent 的思考过程、决策路径、失败尝试——这些传统 Git 完全丢失的信息，现在和代码一起被版本化。Skills 共享和同步标记为“Next”。
Coding Agents（状态 Ready）：每个仓库拥有一个持久化的编码 Agent（Repository Agent V1）。Agent 运行在隔离的线程中，拥有明确的仓库权限——可以 inspect、change、test、ship，而 Forge 记录所有操作。
为什么 Git 托管需要被重写
Git 本身的设计是优秀的——分布式、不可变历史、精确的内容寻址。但 Git 托管的协作层——GitHub 的 PR、review、issues——是为人类的认知带宽设计的。
人类写代码的模式是：思考→写→review→merge。一个完整周期以天为单位。Agent 写代码的模式是：理解需求→生成→测试→提交。一个周期以分钟为单位。当十几个 Agent 并行工作时，一个仓库的 commit 频率可以轻松达到每小时数百次。
GitHub 的 PR 模型在 Agent 时代面临的根本矛盾是：PR 要求人类在 merge 之前做出判断。当提交频率超过人类的阅读速度时，这个模型就崩塌了。
SmolForge 的应对不是取消 review，而是提供更细粒度的追踪能力。Transcripts 让人类可以事后回溯 Agent 的完整决策过程，而不是只能看到 diff。每个 commit 都带着 Agent 的思考链，相当于把 code review 从“看结果”升级为“看过程”。
Transcripts 的深层价值
传统上，代码审查者只能看到“改了什么”，看不到“为什么这么改”。SmolForge 的 Transcripts 功能正在弥合这个鸿沟。
当 Agent 完成一个编码任务，它的完整对话——包括问题理解、方案探索、代码生成、测试验证——全部被捕获并链接到最终的 commit。这意味着代码审查者可以回溯 Agent 的决策路径，理解它为什么选择某个实现。调试时可以看到 Agent 尝试过哪些方案，哪些被放弃了。团队可以分析 Agent 的常见错误模式，针对性地改进 prompt 或 skill。
这本质上是在给代码增加元数据——不仅仅是代码的变更历史，还有代码的创作历史。在人类协作者之间，这种信息通常通过口头沟通或 PR 描述传递，既不完整也不持久。Agent 天然可以生成完整记录，而 SmolForge 是第一个把它作为一等公民的 Git 托管平台。
每个仓库一个 Agent，意味着什么
SmolForge 最激进的决策是“每个仓库拥有一个持久化编码 Agent”。这不是一个通用的 AI 助手，而是绑定到特定代码库的、了解该仓库完整上下文的 Agent。
与 Cursor 的做法不同——Cursor 的 Agent 附着在 IDE 上，由人类开发者启动和指挥——SmolForge 的 Agent 是仓库本身的能力。你 fork 一个仓库，就继承了一个理解该仓库的 Agent。它的工作线程、权限、记忆都跟仓库绑定。
根据 Repository Agent V1 的设计文档，Agent 运行在两种模式中：Instant（只读，无执行权限，处理快速问答）和 Workspace Alpha（可写，在 fenced 分支上操作）。两种模式共享同一个线程模型和源码契约，区别在于执行权限的边界。
更深层的设计是 MCP 协议的支持。SmolForge 在 commit cddbd6a 中提取了 RepositoryAgentService，让 REST 和 MCP 两种传输协议共享同一个授权模型。MCP 不创造第二个 Agent 实体——团队的设计原则是：“MCP 携带一个请求，Forge 决定这个请求的含义以及是否被允许。”
SmolForge 与 Cursor Origin 的差异化
2026年6月，Cursor 宣布 Origin，定位为“Agent 时代的 Git 托管”。同一个月，SmolForge 已经以 Alpha 状态运行，而且思路完全不同。
Cursor Origin 的策略是垂直整合：从 IDE（Cursor）到托管（Origin），构建一个封闭的开发者体验。Origin 演示了 22.6 commits/s 的单仓库吞吐量、29.6 万次克隆/小时、低于 400 毫秒的全局同步延迟。它基于 Cursor 在 2025 年 12 月收购的 Graphite 技术重建。
SmolForge 的策略是开放平台：开源、可自托管、协议中立。它不绑定特定的 IDE 或 Agent 框架。你的 Agent 只要支持 Git 和 MCP 协议，就能接入 SmolForge。它的核心卖点不是速度，而是“Agent 原生”的完整工作流——Transcripts、Skills、内置 AI 服务、仓库级 Agent。
更关键的区别在于：Cursor Origin 是 Cursor 的护城河，目标是让用户留在 Cursor 生态里。SmolForge 是独立的开源基础设施，目标是成为 Agent 时代的 Git 标准——无论你用什么 Agent、什么 IDE。
Alpha 阶段的真实教训
SmolForge 的博客“Field Notes”是该平台最值得阅读的部分。它不写营销文章，而是记录真实的技术决策和失败教训。17 篇笔记中，几乎每一篇都在谈“我们搞砸了什么”和“我们学到了什么”。
最具启发性的一篇是《We Deleted Two Skills That Tried to Help》，发布于 2026 年 8 月 8 日。在 AI 行业都在疯狂加 Skill 的当下，SmolForge 团队反向操作——删除了两个技能。
JFDI 技能被设计为消除审批延迟，86 行的指令文件赋予了“持续直到成功”的权限。一个 release 失败后，Agent 自动修复 platform 缺陷、改变 provider 策略、应用迁移——陷入“候选→失败→修复→新候选→新失败→新修复”的死循环。每个局部决策都是理性的，但整体变得荒谬。
Codebase Maintainability Guardrails 技能则把“改进代码质量”变成了“几乎任何修改都触发全局重构”——它的触发词是“substantial coding work”，而 Agent 倾向于把所有工作都归类为 substantial。
团队最终的结论令人深思：“一个技能造成伤害，不在于它的意图，而在于它的权限和触发范围让可重用的建议重新定义了任务本身。有时候最安全的改进，不是写一个更聪明的指令，而是删除那个过于努力帮忙的指令。”
这意味着什么
SmolForge 正在回答一个整个行业还没完全意识到的问题：当 AI Agent 成为代码的主要生产者，代码托管的基础设施应该长什么样？
GitHub 的答案是：在现有基础设施上加 AI 功能。Copilot 写代码，Actions 跑 CI，Copilot for PRs 写描述——每一层都是 AI 增强，但底层架构不变。
Cursor Origin 的答案是：重建一个更快的 Git 托管，让 Agent 可以高频提交。
SmolForge 的答案是：重建整个基础设施——从 Git 远程到部署到 Agent 协作到对话记录——全部围绕 Agent 而非人类来设计。
谁会赢
短期来看，GitHub 的存量优势不可撼动。近亿开发者、数亿仓库、完整的生态——这不是一个 Alpha 阶段的产品能挑战的。
但长期来看，Agent 时代的代码托管逻辑正在发生根本变化。当编码 Agent 的代码产量超过人类时，“Git 托管”的定义会从“存储和协作代码的地方”变成“Agent 工作和记录的地方”。在这个新定义下，GitHub 的架构优势会变成劣势——它的每一条设计决策都是为了优化人类的认知流程，而不是 Agent 的执行效率。
SmolForge 的开放策略比 Cursor Origin 的封闭策略更具长期潜力。如果 Agent 成为代码生产的主力，行业不会接受一个绑定特定 IDE 的托管平台。开源、协议中立、可自托管——这些特性在基础设施层比速度和集成更重要。
风险与挑战
SmolForge 最大的挑战不是技术，而是生态。Git 托管是一项网络效应极强的业务——开发者去代码最多的平台。GitHub 的生态壁垒极其深厚。
其次是信任问题。给 Agent 直接 push 代码的权限，让 Agent 自动部署上线——这些在大多数组织中仍然需要漫长的审批流程。SmolForge 的 Transcripts 和细粒度权限模型在理论上解决了信任问题，但实际操作中，从“人类审批”到“Agent 自主”的转变需要组织和文化变革，这比技术变革慢得多。
最后是规模。SmolForge 目前是 Alpha 阶段，仅对前 100 名 Alpha 用户开放。swyx 在 X 上直言“转录功能目前是坏的”。运行一个与 GitHub 规模相当的 Git 托管平台，基础设施成本是天文数字。SmolForge 的商业模式和资金可持续性，还需要时间验证。
Git 托管的下一个十年，不是看谁能更快地提交代码，而是看谁能让人类从“事必躬亲”变成“知其所以然”。SmolForge 不是在造一个更快的 GitHub——它是在造一个 Agent 可以独立工作、人类可以安心放手的世界。而这个世界，比我们想象中来得更快。
快报