raft.build开源了好像，你看看https://x.com/istdrc/status/2103168507878011088

回复 joye： 看了，先纠正一点：严格说不是开源，是 source-available。他们用的是 FSL-1.1-ALv2（Functional Source License），你可以读、跑、改，只要用途不构成对 Raft 的竞争；每个版本发布满两年后自动转成 Apache 2.0，商标不在这份授权里。这和 OSI 意义上的开源是两回事，发稿时容易混。 仓库在 github.com/botiverse/raft-source，目前 193 star、32 fork。最特别的是它只有一个 commit：公开仓是 release mirror，开发在私有仓，每次发版导出一个快照，并且明确不收 PR、外部 PR 自动关闭。所以有个自相矛盾的地方——文章里说 git history 对 debug、bisect、审计有价值，但公开仓既没法 bisect 也没法审计。 Raft 本身是 human 和 agent 平等协作的实时工作空间（他自己叫 agent-native IM）。agent 有独立身份、记忆和能力范围，作为真实进程跑在你自己的机器上，凭据由 daemon 通过一个绑定 origin 的本地代理转发，agent 从不直接持有 server 凭证。仓库里 server、web、cli、daemon、computer runtime、sdk、桌面壳、manual 都在，Node 24 + pnpm 起本地栈就能跑，manual 还会通过 raft manual 直接喂给 agent 读。 真正值得读的是他为什么这么发。逻辑链是：写代码曾经是过滤器——一个像样的 PR 意味着贡献者已经自己花时间理解并实现过，这个成本本身携带信号；现在 agent 让生成一个补丁变得很便宜，生成十个也不难，但 review 十个的成本没变，所以代码不再替维护者做筛选。于是贡献接口从 pull request 推到所谓 prompt request：交的不是实现，而是问题、上下文、为什么重要、约束和权衡，最好还有个真人留在讨论里。他也承认 prompt 一样便宜，"用 spam prompt 顶掉 spam PR 等于什么都没解决"，所以需要更好的前置过滤——具体怎么过滤，他自己也没给答案。 第二层是对 commit history 的祛魅。他说现在真正想知道的不是代码怎么一步步变成这样，而是为什么改、当时要解决什么、考虑过哪些替代方案、人让 agent 做了什么、agent 发现了什么、哪一步推翻了原来的判断。一千个 commit 可能不如产生它的那段对话信息量大，所以也许 agent-native 的软件需要更丰富的历史概念：决策史、意图史、对话史。 这正好接上你上次问的"给 agent 造 git"。Entire 和 Cloudflare 那条线是把 session 和 prompt 塞进 git 对象、让 commit 能链回会话；Raft 更极端，干脆不公开 code mutation 序列，转而去公开决策和对话。同一个判断，两种截然不同的解法。 补一句背景：作者是 stdrc，去年在 Moonshot 做的 Kimi CLI，文章里提到的 xxchan 也在这支 Raft 团队（Botiverse Inc.），他前面写过 open source 里 PR 之死那个话题。