让无历史上下文的智能体独立审查方案
文章介绍 Elephant-Goldfish Model 开源技能集：掌握项目上下文的智能体起草设计，另一个全新智能体仅凭文档与引用文件审查。开发者负责架构取舍，并在编码前批准方案；作者还检查了仓库文档与待处理事项。
AI 深度解读
让 AI 先写方案，再开一个全新会话审方案，最后由人批准实现，这是 Elephant-Goldfish Model（EGM）的核心流程。它试图解决的，是 AI 写得越来越快，团队却来不及判断方案是否完整。
原文核对了仓库、技能文件和运行环境文档，也找到了两份结果不同的外部实验。读完最该带走的结论是：隔离上下文有助于暴露文档缺口，但还不能据此认定代码质量会显著提高。
为什么写方案和审方案要分开
EGM 是 google/elephant-goldfish-model 仓库中的开源技能与插件集合，采用 Apache 2.0 许可证，并非一个新模型。
「大象」保留项目上下文，和人讨论需求、形成设计文档；「金鱼」是新启动的审阅代理，只读取文档及指定参考文件；人负责架构取舍，并在写代码前批准方案。
作者引用的理由是：同一个代理讨论了很久，再审自己的方案，容易沿用刚才的解释，默认那些没有写下来的前提已经成立。新代理不知道讨论经过，只能根据文档判断。
这里真正有用的是一道约束：如果审阅者无法复述方案，先检查文档是否遗漏了关键条件。否则，实现者可能也要靠猜。
但新会话只能隔离先前对话，无法消除模型已有的偏差。把它理解为一次独立阅读，比理解为「无偏审查」更准确。
五轮审查分别在检查什么
EGM 的七项技能可以单独使用：egm-brainstorm 检验想法并形成概念简报，egm-draft 编写设计文档，egm-resolve 处理审查意见，egm-review 执行五阶段审查，egm-review-loop 调用预设审阅组，egm-bootstrap 补建或更新已有代码的文档，egm-drift-report 比较文档与当前代码的偏离。
README 主要演示 /egm-brainstorm、/egm-draft 和 /egm-review。作者核对 skills/egm-review/SKILL.md 后，列出了实际审查阶段：
Stage 5 Initial Zoom Out Review
Stage 6 Comprehension Test
Stage 7 Critic Review (egm-design, egm-structural, egm-style)
Stage 8 Intermediate Zoom Out Review
Stage 9 Implementation Readiness Test
要看的是 Stage 6 和 Stage 9：前者要求审阅者理解并解释方案，后者检查文件路径、函数签名等信息是否足以支持实现。编号从 Stage 5 开始，原文没有进一步解释其编号体系。
这套流程先看整体，再检查可理解性、设计与结构等问题，最终判断能否动手。对于存在多个决策分支的功能，它能把「直接生成代码」之前的讨论显式保存下来。
例如原文建议尝试 webhook：发送失败如何处理，同一事件到达两次如何避免重复执行。这些问题若在方案中缺席，后面即使代码能运行，也可能没有满足实际需求。
能不能用，取决于是否真的隔离上下文
按原文核对的文档，EGM 已支持 Antigravity CLI、App、VS Code 扩展，以及 Claude Code、Claude Cowork、Codex、通过上传插件使用的 ChatGPT 和 omp。
但独立版 Antigravity IDE 不支持，因为缺少 invoke_subagent。这里的关键能力，是启动上下文独立的审阅代理。
Codex 没有具名 reviewer persona，文档要求使用内置 spawn/wait，并在启动金鱼时设置 fork_context: false。这是原文所述 EGM 适配文档的要求，实际可用程度仍需核对 docs/codex.md。
安装也有一个容易踩的坑：不能只复制 skills/，运行时还会读取 agents/ 和 resources/，需要安装完整插件。Claude Code 的原文命令如下：
claude plugin marketplace add google/elephant-goldfish-model
claude plugin install egm@egm
第二行的 egm@egm 要保留。Antigravity CLI 对应命令是 agy plugin install https://github.com/google/elephant-goldfish-model。安装后应开启新会话；在 Antigravity 和 Claude Code 中，调用要带命名空间，例如 /egm:egm-brainstorm，因为部分 agy 版本不会自动补齐。
项目热度与效果也要分开看。原文记录，截至 2026 年 11 月 1 日，仓库有 7,923 个 star、465 个 fork；创建于 9 月 13 日，最近 push 是 10 月 30 日；62 个未关闭条目包含 40 个 issue 和 22 个 PR；git tree 共 316 项，其中实际文件 227 个。
这些数字描述了项目状态，没有回答它能减少多少缺陷。
我的判断
我认可 EGM 把设计文档变成可检查交付物的做法。尤其在跨团队交接时，独立审阅者能否理解文档，是一个有用的质量信号。不过，原文作者这轮只查阅了资料，没有安装 EGM 并在真实项目上运行，不能把这篇解读当作作者的实测推荐。
两份外部实验更能说明证据的边界。
第一份发表于 2026 年 10 月 23 日，针对一个困难功能，分两组、每组三轮，以 16 项隐藏测试评分。EGM 平均得到 12.3/16，普通方案是 11.7/16；每轮 Codex 成本分别为 0.95 美元和 0.19 美元，约差五倍。
实验两组都由 AI 代替人批准方案，成本也不包含批准者。研究者认为没有测出 EGM 的额外收益，但单个功能、每组三轮的规模，同样不足以证明它普遍无效。
另一份同日发表于 dev.to 的体验使用 Claude Code 2.1.278 和 EGM 0.1.0。审查耗时 14 分钟，发现 26 条意见，包括 9 条阻塞、9 条重大、8 条轻微问题；按 Claude Sonnet 5 的 API 价格估算，成本约 3.40 美元。但金鱼也误判了 2 次，漏掉了 2 个 bug。它展示了能找出问题，却没有对照组证明净收益。
审查意见的数量，不能直接当作缺陷减少的数量。
「数千名 Google 工程师每天使用」也有出处：原文称，2026 年 10 月 22 日的 Google Open Source Blog 公告包含这一说法，署名 Brian Suchy、Jim Quinn、Elise Ewing、Oliver Newth 和 Dave Rensin。但没有可核验的用户统计或效果测量，应视为开发方陈述。
README 同时注明它不是 Google 官方支持的产品。TESTING.md 验证的也是插件自身，而非使用插件后交付的软件质量。
与「写一份普通方案，再请独立代理审一次」相比，EGM 提供了更明确的角色与检查步骤；是否值得增加成本，原文没有足够对照数据。对小团队而言，先采用独立审阅的原则，再判断是否需要完整流程，更容易控制投入。
能拿来做什么
- 给 Node webhook 等有失败重试、重复事件问题的功能先写方案，明确异常路径，再让独立会话复述处理过程，检查双方理解是否一致。
- 做跨团队交接时，只向审阅代理提供设计文档和必要参考文件；如果关键结论必须依赖口头补充才能成立，就把条件补进文档。
- 用一个真实功能比较普通方案与 EGM，记录实际修复的问题、误报、遗漏、耗时和模型费用，再决定是否纳入团队流程。
- 单行 bug 或改字继续使用常规编码流程。原文 README 也明确，这类任务不必套用完整设计审查。