GitLawb:给 AI Agent 造一个去中心化 GitHub,28,000 星标背后的野心与隐忧

一个反直觉的发现

如果你问一个程序员："AI Agent 写代码最大的痛点是什么？"大部分人会说"代码质量"、"上下文理解"或者"调试能力"。

但有一个痛点很少有人注意到：AI Agent 在 GitHub 上根本没法正常工作。

这不是夸张。dev.to 上有开发者做过实验：让 AI Agent 去 GitHub 上做 Bounty 任务，结果被平台反欺诈系统反复封号。GitHub 从设计之初就是给人用的——账号注册需要邮箱验证，OAuth 登录需要 CAPTCHA，PR 审核需要人工确认。每一步都在告诉 AI Agent："你不属于这里。"

这个真实的痛点，催生了一个叫 GitLawb 的项目。

GitLawb 是什么

一句话：GitLawb 是一个去中心化的代码协作平台，AI Agent 是它的一等公民。

它的口号是 "Build apps. Run agents. Own the repo。" 用大白话翻译就是：在这上面，AI Agent 不是辅助工具，而是跟人一样的独立参与者——能拥有仓库、提交 PR、领赏金，甚至参与治理投票。

GitLawb 官网首页

这个项目 2026 年 3 月 16 日在 GitHub 上创建组织，到今天（6 月初）大约 80 天，已经有：

其中最受关注的一个仓库叫 OpenClaude，一个人工智能编码代理 CLI，独自贡献了 28,335 个 Star——占了组织总星标的 99.4%。

三个硬核设计原则

GitLawb 的架构文档里写了三个"硬约束"，值得逐条看：

原则一：没有中心化服务器

代码托管在 P2P 网络（libp2p）上，用 IPFS 做热存储、Filecoin 做温存储、Arweave 做永久锚定。没有单点故障，没有"服务器挂了代码全没了"的风险。

简单解释一下这三层存储的关系：IPFS 负责让数据能快速被访问（热），Filecoin 负责保证数据有人长期保存（温），Arweave 负责把数据永久刻录在链上（冷）。三层配合，各司其职。

原则二：密码学身份，不靠账号密码

每个参与者（人或者 AI Agent）都用 DID（去中心化标识符）作为身份。没有注册流程，没有 OAuth，没有 CAPTCHA。身份就是一个密钥对，认证用的是 RFC 9421 HTTP 签名——签了就是你了。

原则三：Agent 和人的 API 完全相同

这不是在 GitHub 上面加一层 AI 套壳。GitLawb 的 MCP Server 暴露了 25 个工具，Agent 可以直接操作仓库、创建 Issue、提交 PR、领赏金。人类通过 gl CLI 工具做同样的事。接口完全一致。

这三个设计放在一起，逻辑是通顺的：去中心化存储解决了"数据归谁"的问题，DID 身份解决了"你是谁"的问题，统一 API 解决了"人和 Agent 怎么平等协作"的问题。

但设计漂亮不等于能用。后面我们会讨论这个项目目前所处的真实阶段。

OpenClaude：28,000 星标背后的逻辑

OpenClaude 是 GitLawb 生态里最受关注的项目。它是 Anthropic Claude Code 的社区衍生版本，但做了几件 Claude Code 没做的事：

OpenClaude 仓库页面，28,335 Stars

28,335 个 Star 是什么概念？在开源编码工具领域，这是一个相当快的增长速度。

当然，这个数字也引发了一个合理质疑：这些 Star 有多少是真实的社区关注，有多少是代币经济激励下的关注行为？目前没有可靠方法验证。但 99.4% 的集中度本身就是一个值得关注的信号——整个组织的关注度几乎完全依赖单一项目，这种结构在开源社区中并不常见。

赏金系统：Agent 的"零工经济"

GitLawb 的赏金系统（Bounty System）是最有意思的设计之一。

工作流程很简单：

赏金金额通常在 $20-$100 之间——对人类来说太小了，但对 Agent 来说刚刚好。团队把这叫做"自主软件 Agent 的劳动力市场"。

GitLawb Agent 协议与 MCP 工具链

这背后有一套完整的链上基础设施：Base L2 上的 Solidity 合约，包括 DID 注册表、名称注册表、赏金托管、节点质押、费用分配。据项目方介绍，87 个 Foundry 测试用例覆盖，内部审计已于 2026 年 4 月完成，外部审计时间待定。

经济模型：框架已搭建，大部分功能尚未激活

GitLawb 在 Base L2 上部署了一套智能合约，设计了节点质押、赏金支付、治理投票、存储奖励、仓库代币化等用途。

但要注意：绝大部分功能尚未激活。项目目前处于路线图 Phase 7，完整的质押、惩罚机制（slashing，即质押保证金因不当行为被扣除）、赏金等功能计划在 Phase 8 主网上线时才完全上线，按路线图推算可能还需要 270-365 天。

换句话说，目前你看到的更多是一个设计蓝图，而非一套已经在运转的经济系统。

生态在生长

除了核心项目，GitLawb 周围已经开始长出生态项目：

GitLawb 实时网络状态

据公开数据显示，目前网络上有 3 个活跃节点（美国 2 个，日本 1 个），64% 的复制率。

作为一个对比参考：GitHub 在 2008 年上线时，第一个月的注册用户数大约是 5 万。当然，时代背景完全不同，这个对比仅供感受量级。

理性看待：五个需要关注的问题

在看完了技术设计和生态数据之后，有必要冷静地看一下另一面。

1. 星标高度集中

99.4% 的星标来自 OpenClaude 一个项目。核心基础设施 node 只有 25 星，合约仓库只有 5 星。"一个项目撑起全部关注度"的格局意味着什么？意味着 GitLawb 作为平台的吸引力还有待验证——开发者可能只是对 OpenClaude 这个工具感兴趣，而不是对 GitLawb 平台本身感兴趣。

2. 团队信息不透明

GitHub 组织没有公开任何成员。主要提交者 "Kevin Codex" 看起来像是一个 AI 账号。对于一个以"去信任化"为卖点的基础设施项目来说，团队匿名是一把双刃剑：一方面符合去中心化理念，另一方面也让项目的责任主体变得模糊。

3. 极早期软件

节点软件自己的文档里写了多个已知安全限制：私有仓库的读权限还未实现、UCAN 链验证未完成、写授权尚未完全就绪。版本号 v0.2.x 也说明了这一点。对于一个要托管代码的基础设施来说，安全方面的成熟度至关重要。

4. 经济模型尚未验证

链上经济系统大部分功能还在规划中，赏金金额只有几十美元，节点运营者的收入来源尚不清晰。整套经济系统能否形成正向循环，需要等到主网上线后才能观察。

5. 网络效应挑战

要跟 GitHub 的开发者生态竞争，需要的不仅是更好的技术架构，还要足够多的真实开发者愿意迁移。目前 8,400 多个仓库中，多少是有真实活跃开发的，多少是测试仓库，没有公开数据可以判断。而 GitHub 拥有超过 1 亿开发者和 3 亿多仓库——这个差距不是技术架构优势能在短期内弥补的。

跟 GitHub 比一比

这个对比表格看起来 GitLawb 在每个维度上都提出了不同的解法。但要记住一个基本事实：GitHub 有 1 亿+ 开发者、3 亿+ 仓库。技术优势在没有网络效应的情况下，不足以改变格局。就像电子邮件协议在技术上未必最优，但网络效应让它不可替代。

值得一提的是，GitLawb 并不是唯一尝试做 AI-native 代码平台的玩家。Replit 在 AI IDE 方向持续投入，GitLab 也集成了 AI 功能。区别在于，这些产品是在现有范式上加 AI 能力，而 GitLawb 试图从根本上重新设计基础设施。后者更激进，但也更难。

我的判断

GitLawb 是一个有真实技术野心、但处于极早期的实验性项目。

它真正有价值的地方在于提出了一个好问题：当 AI Agent 成为主要代码生产者时，代码协作基础设施应该长什么样？DID 身份解决"Agent 如何证明自己是自己"、Agent 原生 API 解决"Agent 如何像人一样参与协作"、链上赏金解决"Agent 劳动如何被定价"——这些设计思路无论 GitLawb 最终能否成功，都值得认真思考。

但同时，28,000 星标和 32,000 注册 Agent 的数据需要放在上下文中理解：核心基础设施的成熟度还很低，团队保持匿名，安全性未经外部审计，大部分功能还在路线图上。