谷歌大象金鱼模型 EGM：16 个评审者与 573 秒实测

谷歌开源的大象金鱼模型（Elephant-Goldfish Model，简称 EGM）把规格评审推到了写代码之前，让一批没有对话历史的新子智能体去挑规格里的错，全部家当是 7 个技能加 9 个评审角色。

这个判断在 2026 年下半年变得具体起来。编码智能体写代码的速度已经够快了，快到错误假设还留在设计阶段就被直接编译成了实现细节。EGM 的思路是把评审左移到一个 Markdown 文件里，人来决定取舍，机器只负责找盲点。仓库由 Google 官方账号 google 维护，采用 Apache 2.0 协议，项目站点写明已有数千名谷歌工程师在内部使用这套方法。方法本身来自 Dave Rensin 关于大象与金鱼的随笔，大象负责长期记忆与起草，金鱼负责短记忆挑错。

要留意的是，EGM 没有任何模型权重，也不提供 API，宿主智能体自带的模型额度就是全部成本来源。它是一层方法论与提示词的插件，不是新的编码智能体。下面的内容全部来自该仓库的 README、docs/harnesses.md、TESTING.md 测试记录表与技能文件本身，以及同类的 GitHub Spec Kit、Superpowers 仓库的公开数据。

EGM 是什么：一个插件而不是一个新模型

先看仓库的基本盘。截至 2026 年 11 月 11 日，google/elephant-goldfish-model 仓库的 star 数为 17227，fork 数为 1285，未关闭 issue 有 105 个，主语言标注为 Python，仓库体积约 13 MB。仓库在 2026 年 9 月 13 日创建，正式发版只有两次，v0.1.0 在 10 月 27 日，v0.1.1 在 11 月 6 日。

仓库体积这个数字值得停一下。13 MB 的仓库里没有任何二进制模型文件，主体是几百个 Markdown 文件，里面写的是给子智能体的角色说明和执行约束。这意味着任何人都能直接读懂并改写它的评审逻辑，也意味着它对模型的调用完全寄生在宿主的推理能力上。

README 里有一句官方限定写得很明确：这并非谷歌正式支持的产品。它是内部工具流入开源社区的产物，不承诺支持通道。这一点在评估时比 star 数更重要。

三步工作流与 7 个技能

EGM 把一次开发拆成三方博弈。大象是一个长会话，持有项目上下文和早期决策，只负责起草规格，不写代码。每一条金鱼都是一个无状态子智能体，只读规格草稿和它引用的文件，任务是找缺失的假设、说不清的要求和有实现风险的地方。第三方是人，人负责解决取舍、批准设计、决定做什么。

规格从想法到批准，走的是这条链路：/egm-brainstorm 先澄清问题，产出 concepts_brief.md；/egm-draft 把简报转成 docs/designs/ 下的设计文档，逐节暂停等反馈；/egm-review 交给金鱼群做五阶段评审；人批准之后才让智能体实现。实现落地之后还有 /egm-drift-report 定期比对代码和规格，文档建议按周跑一次。

构思阶段的评审用七条视角同时展开，其中六条是标准镜头。YAGNI 视角追问这个功能是否真需要存在，现成库或 API 能不能解决九成问题。Token 成本视角盯峰值 QPS、内存占用、数据库查询压力和模型 token 预算。开发者体验视角检查接口是否贴合生态惯例，错误信息是否可执行。迁移视角关心存量客户端与数据怎么迁，回滚怎么处理。可观测性视角问关键操作能不能被追踪，凌晨三点的线上故障怎么定位。技术债视角看两年后这段代码会不会难维护。第七条是 Inventive Catalyst，它负责找出设计里被当成必然的取舍，用成熟的软件变换去解冲突。

技能文件里有几条硬约束值得注意，它把大象的行为管得很紧。所有简报、设计稿和评审报告必须写进文件，只在对话里给出文件路径，禁止把大段方案直接铺在聊天窗口里。构思阶段必须经过多轮开放式追问，智能体不得在用户确认之前就拉起子智能体，也不得使用结构化问卷工具。评审默认走挑错路径，禁止谄媚，禁止使用没有依据的褒义词，发现问题时先讲问题再讲优点。

五阶段评审与九个角色

评审是这个插件的核心，也是区别于同类工具的地方。一份规格要连续通过五个阶段，每个阶段最多允许一次复审，发现按 Blocker、Major、Nit 三档定级。

九个评审角色分别承担上面这些视角，另有结构类与风格类角色专门盯组织方式和表达，代码库细节角色负责核对文档与实际代码是否对得上，最后由汇总器角色把各阶段结果收拢。角色文件里写死了金鱼的三条底线。严格只读，没有任何修改工作区或写文件的能力。完全无状态，必须以刚加入项目的新人视角读文档。禁止闲聊，只输出技术依据和结论。

隔离机制是这套方法成立的前提，技能文件里有一条不留情面的规定。如果宿主无法拉起新的子智能体，EGM 直接中止，同一个上下文里做的评审不算金鱼评审。这条限制反过来解释了为什么 EGM 特别依赖 fork_context 这类参数，而不是简单地在同一个会话里多问几轮。站内关于多智能体 harness 成本与通过率的拆解也说明过，子智能体隔离带来的结构收益通常要用额外调用量来换，这笔账在评审流程里会被放大。

各宿主的实测数字

仓库里的 TESTING.md 维护了一张宿主测试记录表，这是判断 EGM 好不好用最硬的证据。表里每一行都是真实跑过的流程，包含安装、构思、起草、评审四列结果和备注。

两处数字最值得记住。Codex 0.163.0 那一行，15 个原生评审者在 573.13 秒里按顺序跑完，官方 ZIP 版本的全套件实跑是 482.30 秒。这说明一次完整的多阶段评审大致落在十分钟量级，而它背后是 15 份彼此独立的上下文。这笔开销用在你自己的模型额度上。

Claude Code 那一行还有个细节。评审者在该宿主里只拿到 Read、Grep、Glob 三个只读工具，项目级的 CLAUDE.md 被排除在上下文之外，实现方式是适配器设置 omitClaudeMd 为真。这个设计意图很明确，评审者不该继承设计者的上下文偏见。站内拆过 Claude Code 六种权限模式与拦截差异，EGM 在这里用的是同一套思路的极端版本，把权限收窄到只读加无状态。

三个已知的坑

第一个坑是宿主指令文件会漏进评审者上下文。issue 237 报告，Codex CLI 0.166.0 即使设了 fork_turns 为 none，仍然把项目级和用户级的 AGENTS.md 送进了评审者上下文，Antigravity CLI 侧则出现了 AGENTS.md 与 GEMINI.md 注入。官方文档对这件事的表述很严谨，fork_context 关闭与 fork_turns 设为 none 隔离的是父会话轮次，它们不构成项目或用户指令被排除的证据。结论是这些参数保证隔离了对话，没保证隔离了指令文件。这个缺陷对安全性有实际影响，因为 AGENTS.md 投毒是真实存在的攻击面，站内那份 Codex 中招率超 90% 的自查清单给出过排查方法。在隔离没被验证的宿主上启用 EGM，等于把项目的规则文件喂给了一群本该保持中立的评审者。

第二个坑是 token 与额度。Claude Cowork 的实跑在第 8 个阶段被 workspace 用量限制打断，前七个阶段正常完成。同一份规格在九个评审角色手里翻来覆去读，token 消耗是成倍叠加的。媒体测算规划阶段的调用量可能放大三到五倍，这属于经验估算，官方没有给出定价，但机制上的量级关系是清楚的。

第三个坑是安装方式。文档里有句话写得很直白，只拷贝 skills/ 目录的精简安装会直接搞坏 EGM，因为技能在运行时要读 agents/ 与 resources/document_standards/ 里的文件。必须装整个插件。omp 这个宿主还额外要求技能目录名用连字符，plugin.json 里不能有 $schema 键，否则它的严格校验器会拒绝 disable-model-invocation 字段。Muse 那边的记录显示 9 个工具投影全部不受支持，评审者没有拿到工具白名单限制，等于只读约束在这个宿主上失效了。

与 Spec Kit、Kiro、Superpowers 的横向对比

把 EGM 放到同类工具里看，差异点才清楚。下面这张表的公开数据来自三个项目各自的 GitHub 仓库与许可证文件。

Star 数上 EGM 差着两个量级，Superpowers 三十一万多、Spec Kit 十四万九，EGM 一万七。人气与成熟度不是一回事，但这个差距说明 EGM 还处在早期。真正的差异在倒数第三行，只有 EGM 把规格交给全新上下文的子智能体审，而且审了五轮。Spec Kit 与 Kiro 把人工确认放在阶段之间，Superpowers 的隔离主要发生在实现期，审的是代码不是规格。

代价是 EGM 这条路更贵也更脆。隔离效果依赖宿主是否真的支持无状态子智能体，而上面提到的三个坑里有两个就出在隔离这一层。人气更高、宿主更广、流程更简单的工具未必更弱，只是解决的不是同一个问题。

谁该用，以及怎么用才不亏

如果团队已经在用 Claude Code 或 Codex 并且会写代码，EGM 值得试，因为它的插件形态不改你现有工作流，只在需要规格的地方插入一段评审。如果团队习惯先写实现再补文档，EGM 的收益会打折，因为它的价值全在左移那一段。第一次上手别从构思开始，先拿一份已经写好的设计文档或 PR 计划跑一次 /egm-review，官方 README 给的最短路径就是这条，几十秒就能看到金鱼给出的东西是不是有用。站点上另有一篇 Karpathy 用 Claude 做全流程开发的拆解，可以对照着看两套方法在人机分工上的差别。

还有一点，EGM 不替代测试，也不替代人的判断。评审发现的质量取决于评审者看到的材料是否完整，如果规格本身就写得含糊，理解测试阶段的复述失败只是症状。这套工具适合在规格还便宜的时候多花一点力气。

常见问题

EGM 和代码评审、Claude Code 自带的 review 有什么区别？核心差别在时点和上下文隔离。代码评审发生在实现之后，看的是 diff；Claude Code 自带的 review 跑在同一个会话里，评审者继承了设计时的上下文。EGM 在写代码之前审一份 Markdown 规格，并且每个评审者都是零上下文的新实例，专门用来暴露设计者的盲区。

用 EGM 会多花多少 token？官方没有给出定价数据。可查到的实测量级是 Codex 0.163.0 一次完整评审跑了 15 个评审者、耗时 573.13 秒，Claude Cowork 在第 8 阶段被用量限制打断。规划阶段调用量放大三到五倍是外部媒体的估算。按你自己的额度实测一次最稳妥。

我该选哪个宿主跑 EGM？优先选能拉起新鲜子智能体、且官方已跑通端到端流程的宿主。Antigravity CLI 1.4.5、Claude Code 2.1.271 以上与 Codex 0.163.0 三个通过了自动化端到端夹具。避开指令文件隔离尚未验证的环境，同时确认你的额度能撑住一轮 15 个评审者规模的评审。

小结

EGM 提供的没有更强的编码智能体，它给的是一套把评审往前挪的纪律。大象拿住上下文，金鱼只读文档挑错，人做最终决定，三方各管一段。7 个技能、9 个评审角色、5 个评审阶段、Apache 2.0 协议，加上 17227 个 star 与 8 个已测宿主，它已经是规格驱动开发这条线上最完整的一份开源实现。

同时它的边界也很清楚。评审成本落在你自己的模型额度上，一次完整流程约十分钟量级。隔离在部分宿主上仍会被指令文件污染，这是安全相关的真实缺陷而非体验问题。官方自己把这套方法定位为内部工具外流，没有支持承诺。想试的话，最短路径是拿一份现成设计文档跑一遍评审，看金鱼给出的东西对你是否有用，再决定要不要把它接进日常流程。