Gemini-GPT Hybrid
为 Claude Code 增加 Gemini 与 GPT 子代理：按任务规模分派，再由 Claude 统一复核。
- Star 数
- ★ 153
- 最近更新
- 3 个月前
- License
- MIT
- FA 评分
- 30/100 · 缺口较多
30 秒速览
- 可在哪里用
- 平台专用Claude Code
- 开始前需要
- 典型场景
- 接手陌生仓库，想让 Gemini 一次性读完整个代码库做安全审计或架构评审的开发者。
- 主要局限
- 强绑定 Claude Code 这一运行时，代理以 Claude Code 子代理 Markdown 形式分发，无法直接用于其他客户端。
这个 Agent 能做什么，适合哪些场景？
Gemini-GPT Hybrid 是一个面向 Claude Code 的多模型编排子代理仓库，核心交付物是 agents/ 目录下的两个 Markdown 代理定义：gemini-gpt-hybrid-soft.md 与 gemini-gpt-hybrid-hard.md。用户在 Claude Code 对话中用 @gemini-gpt-hybrid 触发后，代理先判断请求规模：整仓审计、架构评审、大范围重构交给 Gemini（依托 1M+ token 上下文），单文件调试、聚焦功能交给 GPT（迭代更快），混合任务则按顺序两者并用。区别在于写权限——soft 模式下外部模型只做分析，所有代码由 Claude 写入并经过安全与质量复核；hard 模式允许外部模型直接改文件。运行依赖 Claude Code、Gemini CLI 和 Cursor Agent（用于 GPT 集成），Windows 需 WSL。项目采用 MIT 许可。
代理读取用户请求的范围信号，据此选择路由目标：大范围任务交给 Gemini 引擎，窄范围任务交给 GPT 引擎；产出代码的请求会追加 Claude 复核环节——依次做安全审计（注入面、认证路径、数据暴露、输入校验）与质量检查（结构内聚、错误处理、性能特征），通过后写入磁盘，不通过则进入 Refinement Loop 重做。soft 代理中 Gemini 与 GPT 从不直接写文件，只输出分析；hard 代理则跳过 Claude 写入前的把关，由外部模型直接修改代码库。整个链路以 Markdown 代理文件形式部署到 ~/.claude/agents/。
- 接手陌生仓库，想让 Gemini 一次性读完整个代码库做安全审计或架构评审的开发者。
- 在一个具体文件里定位登录认证缺陷、希望快速迭代修复的工程师。
- 需要先做架构分析、再落地改造的混合型任务。
- 在实验分支或一次性原型上追求速度、愿意用 Git 提交作为回滚手段的团队。
- 对生产代码有严格规范、要求所有写入都经过 Claude 复核与人工读 diff 的团队。
如何安装或部署这个 Agent？
前置条件：已安装 Claude Code；通过 npm 安装 Gemini CLI；安装 Cursor Agent 用于 GPT 集成；Windows 用户需在 WSL 中操作。
安装 Gemini CLI：
npm install -g @google/gemini-cli克隆仓库并把代理文件复制到 Claude Code 的代理目录（macOS / Linux）：
git clone https://github.com/NEWBIE0413/gemini-gpt-hybrid.git
cd gemini-gpt-hybrid
cp -r agents ~/.claude/Windows 下使用：
xcopy agents %USERPROFILE%\.claude\agents\ /E /I验证安装：
ls ~/.claude/agents/应能看到 soft 与 hard 两个代理文件。
如何使用这个 Agent？
在 Claude Code 对话中用 @ 提及代理，并按任务规模描述需求。
大范围任务（委派给 Gemini）：
@gemini-gpt-hybrid perform a security audit on the entire codebase窄范围任务（委派给 GPT）：
@gemini-gpt-hybrid debug the authentication issue in login.js混合任务（两者按序使用）：
@gemini-gpt-hybrid analyze the architecture and implement improvements使用 hard 模式前先备份并开分支：
git add -A && git commit -m "Backup before hard mode"
git checkout -b experimental这个 Agent 有哪些优点和局限？
- 把“什么任务用什么模型”变成显式路由表：整仓分析走 Gemini 的 1M+ token 上下文，窄范围修复走 GPT。
- 提供 soft / hard 两种写权限档位，soft 模式下外部模型不碰文件，所有写入经 Claude 安全与质量复核。
- 安装方式简单：把 agents/ 下的 Markdown 文件复制到 ~/.claude/agents/ 即可，无服务端、无数据库。
- 复核环节列明了具体检查项（注入面、认证路径、数据暴露、输入校验、结构内聚、错误处理、性能）。
- 强绑定 Claude Code 这一运行时，代理以 Claude Code 子代理 Markdown 形式分发，无法直接用于其他客户端。
- GPT 集成依赖 Cursor Agent，等于再叠加一个第三方产品，链路依赖较深。
- hard 模式允许外部模型直接覆盖文件，README 明确只有 Git 提交才是可靠回滚手段。
- 复核层被作者定位为“并非保证”，只覆盖常见问题类别，不能替代人工阅读 diff。
- Windows 需 WSL，无原生 Windows 路径说明。
这个 Agent 与同类方案有什么区别？
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | 形态 / 费用 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|---|
| Gemini-GPT Hybrid 当前 | 30 · 缺口较多 | — | ★ 153 | 3 个月前 | — | Claude Code |
| Maestro 编排平台 | 75 · 存在缺口 | Agent 插件 / 技能免费 + 模型费 | ★ 486 | 16 天前 | JavaScript | Codex · Claude Code |
| Pilotfish 多模型編排層 | 81 · 表现良好 | Agent 插件 / 技能免费 + 模型费 | ★ 715 | 26 天前 | Python | Claude Code |
| Crewplane | 73 · 存在缺口 | 命令行工具免费 + 模型费 | ★ 48 | 2 天前 | Python | Codex · Claude Code |
FollowAgents 如何评估这个 Agent？
查看各维度的扣分理由
README 明确区分 soft/hard 两种模式，soft 模式由 Claude 写入、hard 模式外部模型直接改文件，体现了对写入权限的区分（least_privilege 得 1 分，但 hard 模式默认授予外部模型直接写权限，未在代码层面看到权限约束，故未给更高）。用户确认方面仅以文档建议“先 commit”提示，无强制确认机制（1 分）。数据流透明度仅靠 mermaid 图与表格描述路由，未说明发送给 Gemini/GPT 的具体数据内容与第三方传输细节（1 分）。敏感数据处理完全缺失，未提及密钥、凭据或代码外泄风险（0 分）。依赖安全仅列出 peerDependencies 且版本为 *，无锁定或审计（0 分）。外部效应方面 hard 模式可覆盖文件，仅以文档警告，无技术护栏（1 分）。回滚仅建议 git commit，无自动回滚机制（1 分）。来源归属在 README 中标注作者与所用模型，但 LICENSE 版权署名与 README 作者不一致（“Claude AI Agents Contributors” vs Seol Seunghyeon），削弱归属可信度（1 分）。
README 的路由表与 mermaid 图基本自洽，但 agents/ 目录下实际文件内容未提供，无法验证 soft/hard 描述与实现一致（self_consistency 1 分）。依赖可用性方面 peerDependencies 使用通配符 *，且 Cursor Agent 作为 GPT 集成前提描述模糊，安装可行性存疑（1 分）。失败信息完全缺失，无错误处理或失败提示说明（0 分）。
README 给出生产/实验等场景与 soft/hard 选择表，受众与场景覆盖较好（2 分）。能力边界仅以“review layer, not a guarantee”一句带过，未界定模型能力或路由失败情形（1 分）。触发精度依赖自然语言 scope 判断，无明确阈值或规则（1 分）。环境适配提到 WSL、macOS/Linux/Windows 安装命令，但未验证（1 分）。
信息架构有 README、AGENT_SELECTION_GUIDE、CONTRIBUTING 等链接，但多数文件未在证据中提供（1 分）。安装说明较完整，含前置条件与多平台命令（2 分）。命名稳定性方面 package.json 名称与 README 一致，但仓库 URL 指向 NEWBIE0413 而对象为 oesoll，存在不一致（1 分）。示例有基本用法示例但无 FAQ（1 分）。已知限制仅提及 hard 模式风险与 review 非保证（1 分）。LICENSE 为完整 MIT 文本（2 分）。无 CHANGELOG 或版本历史，package.json 仅 1.0.0（0 分）。维护责任未明确，作者署名不一致（1 分）。
输出可用性方面描述了 Claude 审查后写入的流程，但无实际产物示例（1 分）。边际价值主张多模型路由有吸引力，但缺乏对比证据或基准（1 分）。成本效益提到速度与风险权衡，但未量化 token 成本或延迟（1 分）。
claim_traceability 缺失，README 的 1M token、速度等主张无引用来源（0 分）。cross_source_corroboration 无法进行，因 agents 文件与脚本未提供（0 分）。fact_inference_separation 方面 README 区分了“review layer, not a guarantee”等推断与事实，略有体现（1 分）。
- 源码中未见：敏感信息处理使用专用、低权限、可随时吊销的 API 密钥，不要复用生产凭据，也不要让密钥出现在日志里。
- 源码中未见：依赖安全审查安装前固定版本并做一次依赖扫描（如 npm audit、pip-audit）；优先放在容器里运行。
- hard 模式允许外部模型直接改写代码库，仅以文档建议先 commit，无技术护栏，存在覆盖工作风险。
- peerDependencies 使用通配符 *，无锁定版本或依赖审计，安装可复现性存疑。
- LICENSE 版权署名与 README 作者不一致，且仓库 URL 指向 NEWBIE0413 而非 oesoll，归属与维护责任不清晰。
- agents/ 目录文件与脚本未在证据中提供，无法验证路由逻辑与 soft/hard 描述是否与实现一致。
- 未说明发送给 Gemini/GPT 的数据范围与第三方传输细节，敏感代码外泄风险未处理。