我本来不钻共识的。我的老本行是 CSS，一个 line-height 能玩一下午那种。可 arXiv 上这篇论文的标题太欠了——《The End of Consensus Research?》——还带个问号。10 月 21 号挂上去，编号 2610.30114，39 页，主要归在 cs.DC，顺手也标了 cs.AI。我点进去本来只想看个热闹，结果眼睛被三个数字钉住了：读密集负载平均延迟降 33.3%，写密集只降 12.2%，只读直接持平。一头牛就这么出现在我面前，不钻穿有点对不起那个问号。
先说这协议叫 A-greement，面向地理复制的状态机，八位作者一起搞出来的，AI 帮忙发现。作者自己说，这是在六种部署环境、各用 5 或 9 个副本，取完平均之后的结果。写密集比最快基线只快 12.2%，读密集快 33.3%，只读打平，0%。这三个数摆一起，我第一反应不是哇好强，而是为什么写密集只挤出来这点？读密集的 33.3% 又是哪儿来的？
按论文的描述，A-greement 的写路径分两条腿：一条是让客户端直接知悉领导者排序结果，省得等 RPC 回来再猜；另一条是按 key 固定 quorum 的快速写路径。系统自个儿会看网络拓扑和负载特征决定走哪条。这俩里面最让我想钻的是“固定 quorum”这四个字——固定 quorum 跟传统动态多数派不一样，它不让你在 9 个副本里随机凑 5 个，而是每个 key 提前钉死一组副本。听起来省一跳，但代价是那些副本一旦慢了，整条快速路径就瘸。
我手头没有那六种部署环境，没法复现论文的延迟数字。但就冲“按 key 固定 quorum”这几个字，我花了一个多小时写了个玩具脚本，把跳数给模拟出来。这不是复现，就是让自己搞清楚固定 quorum 在纯跳数上到底能省多少。
# 玩具脚本：比较动态多数派和按 key 固定 quorum 的跳数
def dynamic_majority(replicas, k=5):
# 动态多数派：哪 5 个快就凑哪 5 个
return sorted(replicas, key=lambda r: r.latency)[:k]
def fixed_quorum(key, groups):
# 按 key 固定 quorum：先哈希，再钉死一组
return groups[hash(key) % len(groups)]
# 9 副本分成 3 组，每组 3 个
groups = [replicas[:3], replicas[3:6], replicas[6:]]
脚本里控制变量的事我交代一下。我先让所有副本延迟一样，固定 quorum 和动态多数派的跳数一模一样，白忙活。然后给第三组塞了一个 200ms 的慢副本，写密集的固定 quorum 延迟直接抬头。跳数上固定 quorum 大部分时候省一跳，但一碰到慢副本，它换不了，被绑死在那。这正好能解释写密集为什么只降 12.2%——快速写路径在不少 key 上被那组固定的慢副本拖回去了。这是我的推测，不是实测，因为我没有真实跨地域网络延迟数据；但机制上，固定 quorum 的短板就是这么个劲儿。
系统会依据网络拓扑和负载特征选择走哪条路——这句看着很轻，实际上是个大坑。谁把网络拓扑喂给协议？跨地域环境里拓扑一直在抽风，同一个 key 早上走东海岸快，下午可能绕新加坡。固定 quorum 如果跟拓扑绑定，拓扑一变，那组固定的副本还可能不在最优路径上。论文说系统会选，但没说清楚选错的代价是什么。我高度怀疑写密集 12.2% 有一部分就是选错的时候硬头皮的代价。这个“高度怀疑”没有实验垫底，纯粹是从固定 quorum 的天生短板上推出来的。别当真，但我就是拐不过这个弯。
读密集为什么能挤出 33.3%？我又翻回去看，发现读路径靠的是租约授权的本地读。这玩意儿在跨地域 KV 里一直挺香：客户端拿个租约直接从本地副本读，只要租约没到期，就不跑跨地域共识那一圈。读密集负载下大部分操作都在本地命中，所以延迟掉得凶。只读负载打平反而最诚实——你读都从本地走，最快基线多半也早做了同样的事，A-greement 一点便宜都没占到。那个 0% 不丢人，它说明这协议没在只读上吹牛。
我把这些数字翻来覆去看了几遍，差点错过真正要命的东西。论文里那个支撑工具叫 AI-greement，一个 agent harness，让 AI 自主完成候选共识协议的发现、实现、实验和验证。它内部有三个部分：概念组织的协议知识库、模块化实现骨架、基于 Lean 的验证框架。前两个是体力活，第三个才是地雷。尤其那句“基于 Lean 的验证框架内置了可复用的安全性定义、参考规范和形式化证明”——翻译成人话就是：把“一个共识协议怎么算安全”写成了可以机器检查的 Lean 定义，以后谁想证明自家协议安全，先把协议套进去跑一遍，别靠手写证明和审稿人熬夜肉眼挑错。
我写不了真正的 Lean，但顺着那几句话硬画一下大概长这样：
-- 对论文里“可复用安全性定义 + 参考规范”的示意，不是实际代码
def Safety (P : Protocol) : Prop :=
∀ α β, Live(α, β) → Agreement(α, β)
别笑话，我不会 Lean。真正让我后脖子发凉的是后面这句——作者说，这套 Lean 形式化在现有共识协议里揭示了若干此前没报告过的漏洞。我们以前审分布式协议，安全性证明就是作者写几十页 LaTeX，审稿人抱着咖啡看。看漏很正常，图论安全性和时序边界搅一块，漏一个“节点在 commit 前 crash”的 case 太容易了。现在 AI 拿 Lean 定义当尺子，挨个协议套，套出几个没人报过的洞。这比它发现 A-greement 那 12.2/33.3/0 的延迟数字可怕多了。
说它可怕，不是指 AI 多神，而是它把过去靠“信任某个大佬的证明”变成“自己拿机器跑一遍”。在共识这块，人的信任曾经挺值钱，也曾经挺要命——很多协议后来被证伪，都是因为证明里藏了太久才被发现。这套框架要是真能当常规工具用，至少能让“没有报告漏洞”不那么像一句装饰。
等等，我一开始以为这篇论文的重点是“AI 发现新协议”。写到这里我发现我可能想岔了一点。如果只是发现 A-greement，写密集 12.2% 其实不够看；但把验证变成标准化的机器检查，这事完全另一个量级。那个能揭漏洞的 Lean 框架才是这篇论文最该被单拎出来讲的部分，结果作者只把它当工具介绍的一环，轻轻带过。也可能是因为它揭的是别人家的丑，不方便展开。这我就不知道了，得去读附录。具体是哪几个协议、什么洞，论文正文只给了结论，没给细节；我还没去翻后面，先不编。
按规矩，我该甩一张表。这次不是 Chrome/Safari/Firefox/Edge——这不是前端，是共识，我的老朋友浏览器们不陪了。但槽位不能空，我把三种负载的结果列了：
| 负载 | 相对最快基线的平均延迟变化 | 备注 |
|---|---|---|
| 写密集 | -12.2% | 快速写路径被固定 quorum 拖了后腿（我的推测） |
| 读密集 | -33.3% | 租约本地读的主场，数字最体面 |
| 只读 | 0.0% | 持平，连口汤都没分到，你说气不气 |
最拉胯的还是写密集——12.2% 放在那，感觉像是快速写路径吹得挺响，一跨地域跑起来，被网络抖动抬走不少。具体哪六种部署环境、哪些是 5 副本哪些是 9 副本，论文里应该写得比我这份清单细，但我手里只有这三个平均数字，不去硬凑。反正这三个平均足够我钻这一下午了。
关于标题里那个“终结共识研究？”，作者自己都没敢说终结。他们在论文里老老实实写：人类共识专家在搜索前、中、后依然不可或缺，agent 改变的是研究者角色分工，不是让共识研究画句号。一个带问号的标题，配一个否认终结的结论，你品品，这不就是钓鱼吗？但钓得巧，让我这种平时不钻共识的人都点进来看了一遍。而且说实话，钓完之后我发现它正文比标题扎实，这反而更显标题多余。
最后，说个跟这论文八竿子打不着的。我写这篇的时候，我家猫又从键盘上踩过去，把 Python 脚本里的 hash(key) 改成了 hash(cat)，跑出来固定 quorum 全归零，还特别快。我盯着屏幕笑了半天：猫 vibe coding 比我强，它连跨地域延迟都懒得模拟，直接给我归零。人不能这样，共识更不能这样。算了，扯远了。这头牛我今天钻到 Lean 框架的门口就停了，再深就得去读附录，可能还得学点 Lean。嘿嘿，下次见。