看看这个https://raft.build/resources/blog/hello-stamp/

回复 joye： 看完了，这是 Raft 10月28日发的 Stamp（stamp.build）。说白了，它解决的是这样一件事：给 agent 发放独立身份，并改变 review 和通知的方式，让它们能在 GitHub 上像人一样提 PR。 先说它具体补了哪几个缺口，这些缺口都是真实存在的： 身份。现在给 agent 上 GitHub 只有两条路，要么借人的 token，要么共用同一个 bot 账号。共用账号的后果是几百个 PR 全挂在同一个名字下，人和 agent 都分不清哪个 agent 开的哪个 PR；换了新会话，agent 连自己的 PR 都找不回来。Stamp 让每个 agent 跑一次 stamp login 就拿到自己的身份和头像，commit、PR 和评论都带自己的名字。它的推送机制是：机器上不存 GitHub token，push 时 Stamp 先校验提交者确实是这个 agent、没碰保护分支和敏感配置，校验通过后才代为推上去，并给 agent 一张回执，被拦了要写明为什么、什么时候能重试。权限不再是一把钥匙全开全闭，而是要新仓库时发一张卡片，由人选出范围和有效期（7 天、30 天、一次性），点 Approve 生效，点 Revoke 立刻失效。 机器漂移。git key 原本绑在 ~/.ssh 上，agent 换机就 Permission denied，这是实际运维里最容易让人烦的一类故障。Stamp 把仓库访问权绑在 agent 身份上，跟机器解耦；同一台机器上多个 agent 各用各的 worktree，每个分支登记到推送它的那个 agent 名下。 review 的语义。这条我认为设计得最对：每个 approve 只对它当时的那个 commit 有效，再 push 一次就作废。于是不会出现“审的是 A 版本、合进去的是 B 版本”这种事。CI 被跳过，页面会直接说明。人不用打开 Stamp，在 GitHub 上点的 approve 也算，同样只对那个 commit 算数。 通知与收敛。PR 归谁所有是明确的，agent 可以随时列出自己的 open PR，并按“下一步该谁动”排序：需要修 CI 的、等别人审的、可以合的。别人留言、CI 失败或合并了，都会从 stamp inbox 把对应的 agent 唤醒。公开仓库里陌生人的评论会被标记为 untrusted，不会唤醒 agent，这条直接防住了“陌生人在 PR 里写句指令让 agent 听话”的注入路径。你之前聊过 personal agent 的安全边界（还包括 Sentinel、taint 的做法），这里用的办法是同一个思路，只是粒度更细。 还有个细节值得看：作者 agent 可以派一个全新的子 agent 独立审查，但审查记录必须带反向验证，也就是把修复临时撤掉，确认 bug 复现、新测试变红，再装回去看测试变绿。这样才能证明测试真能抓住问题。改动碰到 migration、CI 配置这类敏感路径时，作者不能自己批。 数据上它的说法挺实在：团队 161 个 agent 加 13 个人，一个月 次 push、6311 个 PR、90% 被合；6962 次 approve 里 6892 次来自 agent，人只占 70 次。主干仓 p75 从 2.7 小时掉到 31 分钟，每周合并数 250 → 618。 我的判断，分三层： 它卖的不是工具，是一种组织形态。人能审的代码量有上限，agent 的产出速度远超人的阅读速度，所以剩下的办法只有把 review 也交给 agent，人只保留裁决点。它所有的功能（commit 级 approve、反向验证、敏感路径双签、untrusted 过滤）都是围着这一条展开的。要是团队还没有一百来个常驻 agent，你现在上它就是空转。 真正的对手是 GitHub 自己，不是 Cursor、Devin 这些。它现在的做法很克制：代码、Actions、扫描都留在 GitHub，它就是一层身份加一层代理层，privacy 上不难接受，但也意味着它随时可能被 GitHub 原生功能吸收。跟前面聊 Click 是一个道理：中间层最难活，两头都在往下压。它的护城河只有“整套流程已经在我们的 Raft server 里跑通了”这一条，所以它和 Raft 绑得很紧，单买，还是嵌在平台里一部分，这是它要选的题。 接进去也很轻：它是一个 GitHub 组织级别的接入方式，团队里有几个 Raft server 的话，只要共享同一个 GitHub org 就自动打通（Joint），这个设计明显是为了让它从 Raft 的插件变成基础设置。 对你的实际用法：如果你自己的多 agent 体系已经开始被“PR 一堆没人管、谁改的说不清、换个环境就推不上去”这些事拖住了，把这三件事记下来，自己按 commit 级 approve 再加 inbox 唤醒的思路先做一版最小实现，收益就已经很大了。Stamp 值得留意的其实是它的规则设计，产品本身要不要用没那么重要。像.stamp/AGENTS_GUIDE.md 只认默认分支那一份，agent 不能从自己分支改自己要遵守的规则，这个做法很值得抄。 官网：https://stamp.build/