把五个 Agent 塞进一个 Loop，产出速度会翻几倍 —— 错误也会。 因为多 Agent 协作最危险的情形，从来不是"没人干活"，而是"所有人都干得很像对的"。
这一页不介绍 Loop 是什么，而是交代一件更实在的事：这个作品本身，是怎么在被否决了 13 次之后才敢拿出来投稿的。 以及，那套否决机制如何从"我一个人的习惯"，变成循环里一个固定的角色。
一个 Agent 从头写到尾，没有第二双眼睛。它错了，就是整篇错。
多个 Agent 分工协作，流程看起来很严谨。但如果它们读的是同一批二手资料、用的是同一类模型， 它们会犯同一个错，然后互相点头。
coprocessor.region-split-size 的默认值，中文技术圈里大量二手资料写的是 96MiB。
这是 v8.4.0 之前的值，v8.4.0 起官方默认已改为 256MiB。
现在设想：我让三个 Agent 分头去写"分裂阈值是多少"，再让它们交叉校验。 它们大概率三个都写 96MiB，然后三票互证通过 —— 因为它们的语料里躺着同一批过时文章。
这不是协作出了问题，而是协作的目标函数设错了。 当"互相校验"的判据是"我们说的是否一致"，协作就退化成了一次共识幻觉； 只有当判据是"我们说的是否对得上官方文档"，协作才开始产生真实价值。
在 Loop 的项目分工里，通常会给角色起名字：架构、设计、开发、测试、文案。 我们额外留了一个位置，叫 核验 Agent。
它不写文案、不做设计、不写代码。它唯一的工作，是在任何内容出门之前，逐条要求出示出处。 没有出处的表述，它有权直接卡住 —— 不需要跟任何人商量，也不需要征得产出方同意。
这个角色最反直觉的一点是：它的产出是好内容的副产品，而不是它的目标。 一个核验 Agent 如果从不否决任何东西，那它不是宽容，而是失职。
spec.js：69 项官方口径，
每项包含条目名、官方原文、适用版本、文档链接四要素。
任何 Agent 想往画面里写一个数字，先去字典里查；字典里没有的，不许写。
前面几节讲的是「怎么不写错」，这一节换个方向：把这些机制本身摆成可以亲手点的微缩沙盘。 三个沙盘的画面里每个机制参数都是虚线锚点 —— 点开就是官方原文。 这不是装饰：模拟器一旦用了错的默认值（例如把分裂阈值仍写成 96MiB），它演示的就是错误结论 —— 所以这里的每个数字都先过字典，才轮到上场。
上一节是机制沙盘，这一节换一种证据：真机读数回放。
三台 TiKV 现场采集的 store 状态、Region 分布与故障转移时间线，整理成 JSON 放进 dev/probe/
后由本区原样渲染 —— 不加工、不补数；没采集到的时候显示空态与字段结构，页面照常可读。
沙盘可以搬走，读数只能自己采 —— 这正是这套机制拒绝「代写数据」的边界。
| 被拦下的表述 | 坑的类型 | 如果漏出去会怎样 |
|---|---|---|
| Region 分裂阈值 = 96MiB | 过时值 | 这是社区流传很广的一个旧值。评审只要点开官方文档，第一眼就会看到差异 —— 而技术解读准确性占 30%。 |
| PD 按 region score 公式给 store 打分 | 无出处 | 写出来极像"内核级理解"，但官方《TiDB 数据库的调度》只公开调度目标，未公开打分公式。看起来很专业，恰恰是最危险的那种错。 |
| 存储健康度 100%（字样拼装型） | 绝对化 | 违反广告法绝对化用语要求。且它是 v:'100' 与 u:'%' 分开声明拼出来的，字面量搜索抓不到，只能靠断言专门识别。 |
| Leader 故障后 3 秒内完成重新选举 | 编造时长 | 官方只给了 tick 机制（raft-base-tick-interval 1s × raft-election-timeout-ticks 10），未给出端到端时长。凭空补一个"3 秒"，就是替官方发明结论。 |
如果你也在用多 Agent 协作做有对外交付压力的内容，下面三样东西可以直接拿走：
① 口径字典的字段结构 —— 条目名 / 官方原文 / 适用版本 / 文档链接 / 状态（已核验 · 官方未列明）。 最后那个"官方未列明"状态是整套机制的关键：它把"查不到"从失败，变成了一个合法的结论。 没有这个状态，Agent 在查不到出处时会倾向于编一个，因为流程里只认"必须有答案"。
② 断言清单的组织方式 —— 每类检查一个独立文件，各自维护，由一条总命令串起来全量执行， 以退出码决定通过与否。好处是：加一条新规则只需要加一个文件，不必改动已有检查。
③ 核验 Agent 的评审提示词，只有三条要求 —— (a) 任何数字必须出示官方出处，否则不许写； (b) 必须区分"官方未列明"与"我没查到"，前者是结论，后者是待办； (c) 否决必须留痕，写清原表述、正确口径与修正理由。
它不能替你把机制讲明白。 核验只保证"不写错"，不保证"讲得懂"。内容质量仍然取决于人。
它拦不住"出处本身被理解错了"。 如果我把官方原文读错了，再写进字典，核验 Agent 会照样放行 —— 它守的是"有没有出处"，不是"出处理解得对不对"。这一层只能靠人。
它依赖人先定下标准答案从哪来。 字典是人建的，Agent 只是守门。 标准答案的来源一旦选错，整套机制会非常高效地生产错误。
它不降低工作量，只是改变错误发生的位置。 从"发出去之后被发现"，变成"发出去之前被拦下"。 前者要付声誉成本，后者只付返工成本 —— 这就是它值得的全部理由。
前面讲的所有规则，如果只停留在页面上，那就还是"自说自话"。所以这一段不写结论，只放过程录像：
在平凯 Loop 的工作区里，真实地建实验频道、把核验智能体加进去、用真实 @ 提及把核验任务派下去。
全程由浏览器自动化操作、连续录屏，未剪辑、未加速。
fact-checker 这一次没有返回审核结论 —— 原因是当前工作区的模型服务接口返回
workspace identity cannot be resolved，智能体拿不到可用的模型，因此停在"离线/未响应"。
智能体本身、主机接入、频道、提及触发都是真的；没跑出结论这件事也是真的，所以不剪掉、也不编一段结论补上。
这正是本页第七节说的那句话：核验机制的价值不在于它一定说"通过"，而在于它不通过时你敢不敢把"不通过"也摆出来。
前面讲的抽象规则，在这个作品里都有具体的落点。你可以逐一去核对它们是否真的存在：
换句话说：这一页是"怎么保证没讲错"的交代，其他页面是"讲对了什么"的成果。 两者合起来，才是一个完整的多 Agent 协作交付。