puppyone vs GitHub：给代码的版本控制 vs 给 Agent 上下文的版本控制

TL;DR

• GitHub 是给代码的版本控制。 仓库、PR、code review、CI/CD —— 围绕"人评审人写的代码再合并"做。
• puppyone 是给 Agent 上下文的版本控制。 文件、自动 commit、per-agent 权限、MCP/Bash/REST —— 围绕"Agent 一直在写、人只看需要看的"做。
• 它们都借了 Git 的形状（commit、diff、branch、rollback），用法完全不同。
• 大多数团队代码留在 GitHub，Agent 读写的上下文放 puppyone。把 GitHub 当 Agent 工作空间用，是恰好错的形状。

老实话

GitHub 是过去 20 年最好的产品之一。puppyone 自己就 host 在上面。我们不替代它。

我们想说的是：当你问"我的 Agent 在哪里读写所有不是应用代码的东西"时，答案不是 GitHub。这是我们眼睁睁看着很多团队碰墙之后才想明白的一句话。

GitHub 围绕一个特定的舞步做：人写代码，开 PR，另一个人 review，CI 跑，merge。所有产品面 —— protected branch、required review、status check、branch protection —— 都是为了让"人评审-再合并"这套舞跳得安全。

Agent 不这么跳。它 90 秒能写 200 个文件。它对同一个计划要试 14 次才对。这些写入大多数不该开 PR；有些该被静默覆盖；少数该开分支。把这些都放进 GitHub 要么是一墙没法 review 的 PR，要么是一堆没保护直接 push 到 main 的 commit。两个都不是 GitHub 的用途。

puppyone 就是为这个建的：一个 Git 形状的底座，Agent 是一等写入方，历史自动，人只 review 真正重要的切片。

并排对比

维度	GitHub	puppyone
主要用户	写代码、评审代码的人	读写上下文的 Agent
基本单位	仓库 + commit + PR	工作空间 + commit（不强制 PR）
写入模型	author commit → push → 开 PR → review → merge	Agent 写 → 自动 commit → 继续（review 可选，事后做）
身份	per-user（GitHub 账号）	per-agent（带明确身份的 Access Point）
权限	仓库级 / 组织级 / 分支保护	per-agent 路径 scope（/research 读、/output 写）
存什么好	代码、构建产物、release	markdown、JSON、CSV、生成报告、scratch、ingest 的 SaaS 数据
原生接口	git CLI、Web、GitHub API	Bash、SSH、MCP server、REST API、sandbox 挂载
diff / 历史	per-file diff、commit log、blame	per-file diff、commit log、per-agent provenance、秒级回滚
SaaS 接入	没有（它是 Git 托管）	内置：Notion、Slack、Gmail、Postgres 等
能否自托管	能（GitHub Enterprise）	能（开源、Docker）
真正擅长	代码、release、人的评审	Agent 上下文、多 Agent 协作、SaaS 形状的知识

什么时候该用 GitHub（而不是 puppyone）

让 GitHub 干它最强的活：上线前需要人评审的代码。

• 应用源码、IaC、CI/CD 流水线。
• 开源项目，PR review 和讨论本身就是产品。
• 任何受益于 CODEOWNERS、status check、签名 commit、release notes、整套代码协作机制的场景。
• 描述某个仓库内 Agent 应该如何行为的 AGENTS.md / 仓库专属指令的标准家。

我们不替代这些。puppyone 没有 PR 流程。我们没有 CODEOWNERS。我们不是代码托管。

什么时候该用 puppyone（而不是 GitHub）

写入方是 Agent，内容不是应用代码的时候用 puppyone：

• Agent scratch —— 草稿、计划、中间结果 —— 强制每写一次开 PR 是荒谬的。
• 多 Agent 工作流，每个 Agent 应该有自己 scope 内的路径。GitHub 给你的是仓库级访问；puppyone 在一个工作空间内给你 per-agent 路径 scope。
• 长跑研究 Agent，一小时产几十个文件。你想要 commit 历史和回滚，不想要 PR 队列里 60 个待评审。
• 物化为文件的 SaaS 数据（Notion / Slack / Gmail / Postgres）。GitHub 不接你的 Slack；puppyone 接。
• 你想要版本化但不一定要 code review 的 Agent 输出。报告、转换数据集、生成资产、对话快照 —— 全部版本化，但都不属于某个仓库的 main。

如果你一直在为"Agent 用"建私有 GitHub 仓库、然后看着它们变成不可评审 commit 的坟场 —— 你在重新实现错的原语。puppyone 才是那些仓库本来想成为的样子。

什么时候两个一起用（最常见的答案）

只要团队同时跑工程和 Agent，几乎都长这样：

1. 代码留在 GitHub。 应用源码、infra、CI/CD、release —— 跟以前一样。PR、review、check 全保留。
2. AGENTS.md 和仓库专属指令也留在 GitHub，跟它们描述的代码挨在一起。Agent 在那个仓库里工作时去读它们。
3. 其他所有 Agent 读或写的东西放 puppyone。 规格、研究、生成报告、多步计划、ingest 的 SaaS 上下文、scratch、转换数据切片。
4. puppyone 把 Agent 需要读的 GitHub 仓库挂载 进来 —— 代码、文档、AGENTS.md 都作为文件出现，commit 落地时自动刷新。Agent 拿到统一的文件系统，你不用教它 GitHub API。
5. 如果 Agent 产出某个东西应该变成 PR（代码改动、文档更新），它先 stage 在 puppyone 里，你 review，过了之后通过连接器开成真 PR 回 GitHub。"评审 gate"留在它该在的地方。

干净的规则：代码走 GitHub PR；其他所有东西作为自动版本化的文件留在 puppyone 里。边界就是"上线前是不是要人 review"。

"可是 Git 已经有 commit、branch、回滚了，我用一个私有 Git 仓库当 Agent 工作空间不就行了？"

有人试过。三件事可预期地坏：

1. 没有 per-agent 权限。 Git 的权限模型是仓库级。你没法在一个仓库内说"这个 Agent 能读 /specs 但不能读 /finance"。要么所有人看所有，要么拆成十几个仓库各自鉴权 —— 然后你的 Agent 要去玩 token 和 API 限流的杂技。
2. push / commit 流程对 Agent 写入速度太重。 Agent 写得勤、批量小、有时候写错。把每一次写都包成 git add / git commit / git push 要么很脆（一次网络抖动断链），要么很吵（你的 main 一天一千条 "wip" commit）。puppyone 在存储层默认就是"写即 commit"，不需要胶水代码。
3. Git 没有 SaaS 连接器。 Agent 要 Slack 线程、Notion 规格、Postgres 切片。GitHub 不会把它们放进你仓库。要么你自己建同步流水线（你的，永远你的），要么 Agent 现场打每个 API（限流、schema、漂移、重试）。puppyone 自带连接器，这个不是你的问题。

你完全可以用 Git 仓库当"Agent 上下文存储"撑两周。通常在第三个 Agent 或者第二个集成的时候开始崩。

"那 Cursor 的仓库记忆、Claude 的 Project、Devin 的工作空间呢？"

per-product 的 Agent 记忆在那个产品内很好用。它不是共享底座。

会撞上的问题：

• Cursor 的记忆只帮 Cursor。
• Claude 的 Project 只帮 Claude。
• 你的 n8n 工作流读不到。
• 你的自建 Python Agent 读不到。
• 你团队用别的编辑器的同事读不到。

puppyone 在它们底下。同一个工作空间通过 MCP 暴露给 Cursor、通过 MCP 暴露给 Claude Code、通过 REST 暴露给 n8n、通过 Bash/SSH 暴露给你的自建代码 —— 任何会用文件的东西。每个工具保留自己 product 级的记忆；puppyone 是跨 product、跨 Agent 那一层，让"共享上下文"真的等于共享。

实际怎么集成

不存在迁移。GitHub 不动。

1. GitHub 原地不动。 代码、PR、CI、release —— 不碰。
2. 在 puppyone 里加 GitHub 连接器。 选定 Agent 要读的仓库 / 分支 / 路径，它们以文件夹形式出现在 Agent 工作空间里，commit 落地时同步。
3. 把 Agent 可读的叙述从 GitHub README/docs 里搬到 puppyone 文件，当它们不该跟代码挨着的时候。长篇研究、生成报告、多步计划 —— 它们停止污染你的仓库，开始在 puppyone 里被版本化。
4. 每个 Agent 给一个 Access Point。 Cursor 读 /repos/your-app/、/specs。Researcher 读 /research 写 /research-notes。它们拿到正好需要的切片。
5. 该变成真 PR 的改动（代码编辑、文档改动），Agent 先写到 puppyone 的 staging 路径；人 review；过了再通过连接器 push 成真 PR 回 GitHub。

一个月后你会看到：GitHub 装可评审的代码；puppyone 装宇宙剩下的部分；Agent 看到两边，你的 main 不再淹没在"wip from agent run #2,481"里。

FAQ

puppyone 替代 GitHub 吗？ 不。我们不 host 你的代码、不跑你的 CI、不替代你的 PR review。GitHub 干这个，干得很棒。我们存 Agent 可读、可写、不属于代码仓库的那层上下文。

puppyone 是基于 Git 的吗？ 我们在存储层借用 Git 的思路（commit、diff、branch、回滚）。我们不是 Git 托管，也不 1:1 暴露 git 语义。重点是给 Agent Git 风格的保证，但不让它每次写都做 Git 仪式。

puppyone 能往 GitHub 开 PR 吗？ 能 —— GitHub 连接器支持双向操作，包括从 Agent staged 改动开 PR。评审 gate 留在 GitHub。

AGENTS.md 应该放 puppyone 还是 GitHub？ GitHub，跟它描述的代码挨着。puppyone 从那里读。AGENTS.md 是关于这个仓库的文档，应该跟仓库一起。

为什么不给每个 Agent 建一个 GitHub 仓库？ 能。然后你会花大量时间管仓库的创建、删除、权限、token、限流、Agent 间隔离。puppyone 给你的是一个工作空间加 per-agent Access Point —— 没有仓库爆炸。

再说一遍 TL;DR

GitHub 给人评审的代码做版本控制。puppyone 给 Agent 读写的上下文做版本控制。同样的 Git 形状，不同的活。代码留 GitHub。Agent 碰的其他所有东西放 puppyone。在该有缝的地方接起来。

别再把私有 GitHub 仓库变成 Agent 的坟场。给它们一个真正的工作空间。Get started→