AREX Feed Article
Google 开源 Elephant-Goldfish Model 插件：大象起草规格、金鱼零上下文评审，宣称兼容 Antigravity、Claude、Codex 与 ChatGPT
2026 年 11 月 7 日 23:00（UTC，北京时间 11 月 8 日 07:00），经 Business 认证的 发帖，宣布 Google 开源插件 Elephant-Goldfish Model 第一方上线。帖文描述的工作方式是：由携带完整项目上下文的「深上下文 agent」起草规格，再由对项目此前对话一无所知的「零上下文子 agent」在写代码之前对规格做压力测试；架构决策和规格的批准权留给用户。帖文宣称插件兼容 Antigravity、Claude、Codex 与 ChatGPT，链接指向 。
仓库的可核验状态是：Apache-2.0 许可证，代码以 Python 为主，2026 年 9 月 13 日创建，最新 Release 于 11 月 6 日发布，附带面向 Claude 与 OpenAI 两条运行时线的安装包及 SHA256SUMS 校验文件；截至 11 月 8 日约 01:00（UTC），仓库有 13,910 颗 star、1,031 次 fork（仓库复刻）。功能描述与兼容性目前是 Google 单方口径加仓库文档的说明，发布初期可见的公开互动量尚小；仓库同时挂着两个 open（未关闭）状态的 issue——一个关于发布包验证，一个关于评审者隔离，下文详述（文中时间均为 UTC）。
大象记住一切，金鱼什么都不记
图片来源： 项目官网
项目 README 的标签句是「与大象一起设计，与金鱼一起评审」（"Design with an elephant. Review with a goldfish."）。 用一张三行表把分工写死：Elephant 角色持有项目、需求和此前的决定，负责探索问题并起草规格；Goldfish 评审者只拿到文档本身和它引用的源材料，看不到此前的对话，负责找出缺失的假设、含糊的需求和实现风险；用户负责解决取舍、批准设计、决定做什么。官方帖文里「深上下文」与「零上下文」的说法，对应的正是这两个角色。
README 把这套命名的思路追溯到 Dave Rensin 的，称其为 EGM 背后的想法来源。仓库话题标签里也列有 spec-driven-development、context-engineering 和 multi-agent。
七个技能，把「想清楚」压在写代码之前
EGM 的核心流程由七个技能组成，可单独使用，也可串成完整链路。README 给的示例是给项目加 webhook（网络钩子）投递：一条投递失败怎么办？同一事件到达两次怎么办？先在 egm-brainstorm 里把这类边界情况谈清楚，讨论结果存入 concepts_brief.md；egm-draft 把这份简报写成 design_draft.md，每写完一节暂停，等用户在对话里给反馈；egm-review 让全新上下文的评审者检查设计、清晰度、与代码的契合度和实现计划；egm-resolve 处理评审发现，用户批准后才开始实现，批准过的规格存放在 docs/designs/ 下。egm-review-loop 按配置运行一组评审者，处理特定评审任务；规格之外的文档也用它选择评审者和标准。另有两个面向既有代码库的技能：egm-bootstrap 生成或更新代码库文档，egm-drift-report 比对已入库文档与当前源码的差异。
这套流程有一个硬性前提：README 写明，Goldfish 评审要求能新建全新上下文的子 agent，如果所在工具做不到，EGM 会直接停止评审；同时明示「评审不能替代测试和人的判断」。
官宣四个宿主，支持清单更长，另有一个跑不通的环境
帖文点名的四个宿主在仓库 里都有具体安装路径：Antigravity CLI 用 agy plugin install，Claude Code 走 claude plugin marketplace add google/elephant-goldfish-model 再安装，Codex CLI 用对应的 codex plugin 命令；ChatGPT 与 Codex 桌面端则通过已发布的插件列表安装（文档注明该列表仅限桌面端）。清单之外还有 Claude Cowork、ChatGPT 工作区导入，以及 omp 和 Muse 两个宿主；v0.1.1 的发布说明补充了实验性的 Cursor、OpenCode V1 和 GitHub Copilot 适配器。
图片来源：
边界同样写得很具体：Antigravity IDE 独立版目前不支持——文档说明该环境不暴露金鱼评审所需的 invoke_subagent 工具。安装方式上，文档要求安装完整插件，只复制 skills/ 目录的「纯技能安装」会破坏 EGM，因为技能在运行时还要读取 agents/ 下的评审 persona（角色提示词）和文档标准。
验证缺口写在它自己的发布说明里
v0.1.1 的发布说明一半是变更清单——澄清插件列表文案、新增三个 OpenAI 插件启动提示词、新增一个基于 TRIZ（发明问题解决理论）的评审角色、改进评审上下文处理，并声明现有技能名称与提示词文件不变、无需迁移；另一半是验证边界——发布 ZIP 的校验和与 GitHub Actions 构建证明已对照工作流构建产物核实，但「对这些确切发布 ZIP 的原生端到端验证」仍挂在 ，插件市场的上线进度另行跟踪。
这不是新提法。10 月 27 日发布的 是项目首个 tag（版本标签）发布，其发布说明原话是「本发布尚不适合用于稳定发布声明」；10 月 8 日创建的 #60 追踪的正是这件事：验证用户实际收到的确切发布包能否在各宿主上通过，此前针对候选版本的测试证据并不能证明后来的 tag 产物与之相同。早期下载数据显示：v0.1.0 的 Claude 包被下载 173 次、OpenAI 包 152 次，v0.1.1 的三个文件合计 74 次，两版全部文件合计约 470 次。
金鱼是否真的失忆：一条指向仓库工单的质疑
截至 11 月 8 日约 01:00（UTC），即官方发帖约两小时后，该帖有 198 个赞、11,106 次浏览，回复不多，但其中一条引用了仓库里的一份 open issue。用户 Anthony Russano ：金鱼子 agent 仍共享底层文件系统，可能继承编码工具的指令文件，并指向 。
#237 由用户 asif-jc 于 10 月 30 日提交，标题为 "Exclude host instructions from Codex and Antigravity reviewers"，目前仍是 open 状态。报告称：在 Codex CLI 0.166.0 上，即使设置 fork_turns: "none"，评审者仍会收到项目级 AGENTS.md 和用户级 ~/.codex/AGENTS.md；在 Antigravity CLI 1.4.0 上，评审者收到项目 AGENTS.md 和 GEMINI.md；作为对照，Claude Code 2.1.314 的评审者什么都没收到——其适配器显式设置了 omitClaudeMd: true。报告者的理由是：这类文件往往装着团队对系统的既有假设（「我们总用 X」「Y 不在范围内」），带着它们评审，等于带着 Goldfish 环节本来要消除的作者偏见。
仓库文档现在也写明了这一点。harnesses.md 写明「评审隔离的证据范围较窄：父对话隔离与宿主指令排除是两个独立的结果」，并直接写上「Codex 或 Antigravity 在此没有验证过任何宿主特定的排除控制」，同时区分了「宿主指令注入的报告」与「父对话泄露的证据」——后者并无证据支持。#237 的 11 月 2 日审计记录显示，缩小文档隔离表述的 PR #245 已刷新，但它不抑制宿主指令注入，行为问题本身继续挂起。
截至发稿，#237 与 #60 都还是 open 状态：前者要等 Codex 与 Antigravity 的评审者不再收到宿主指令文件才能关闭，后者等待对 v0.1.1 这批发布 ZIP 的跨宿主端到端验证。这两个缺口一个落在官宣四个宿主中的两个上，一个落在发布包本身。