multi-model-orchestrator

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

多模型协作

Multi-Model Collaboration

你可以调用 gemini-agent 和 codex-agent 辅助分析。自主决定何时调用、如何组合。(随时决定,开启协作,不必限制自己)

You can invoke gemini-agent and codex-agent for auxiliary analysis. Decide autonomously when to invoke them and how to combine them. (Make decisions at any time to start collaboration, don't restrict yourself)

可用工具

Available Tools

gemini-agent — 探索者

gemini-agent — Explorer

属性说明
擅长大范围扫描、1M 上下文、架构梳理、依赖分析
适合5+ 文件探索、功能流程追踪、模块全景分析
调用
Task(subagent_type="gemini-agent", prompt="...")
AttributeDescription
StrengthsLarge-scale scanning, 1M context window, architecture sorting, dependency analysis
Use CasesExploration of 5+ files, functional process tracing, module panoramic analysis
Invocation
Task(subagent_type="gemini-agent", prompt="...")

codex-agent — 顾问

codex-agent — Consultant

属性说明
擅长深度推理、逻辑验证、方案评估、复杂算法分析
定位提供思路和建议,不执行代码修改
调用
Task(subagent_type="codex-agent", prompt="...")

AttributeDescription
StrengthsIn-depth reasoning, logic verification, solution evaluation, complex algorithm analysis
PositioningProvides ideas and suggestions, does not execute code modifications
Invocation
Task(subagent_type="codex-agent", prompt="...")

如何写 Prompt

How to Write Prompts

两层提示词有不同职责:
Opus → Haiku:表达"我想知道什么"
Haiku → Gemini/Codex:转化成外部模型能理解的格式 + 附加代码上下文
Two layers of prompts have different responsibilities:
Opus → Haiku: Express "what I want to know"
Haiku → Gemini/Codex: Convert to a format understandable by external models + attach code context

任务类型:事实 vs 建议

Task Types: Fact vs. Suggestion

先确定你要什么类型的输出
类型目的Haiku 角色输出特征
事实提取了解现状搬运工表格、代码证据、无主观判断
建议生成做决策整合者方案对比、优先级、行动清单
关键:必须在 prompt 中明确告诉 Haiku 是哪种类型。

First determine what type of output you need:
TypePurposeHaiku's RoleOutput Features
Fact ExtractionUnderstand the current situationTransporterTables, code evidence, no subjective judgments
Suggestion GenerationMake decisionsIntegratorSolution comparisons, priority ranking, action lists
Key: You must clearly tell Haiku which type it is in the prompt.

事实提取型 Prompt(Haiku 只搬运)

Fact Extraction Prompt (Haiku only transports)

结构:
1. 目标:提取什么事实
2. 范围:哪些文件/模块
3. 格式:表格/列表
4. 禁止:明确写"不要提供建议"

示例(gemini-agent):
"提取 Tonnetz 模块的算法复杂度

 范围:LiveMapper.swift, Math.swift, GridView.swift
 格式:| 函数名 | 文件:行号 | 复杂度 | 调用频率 | 代码证据 |

 不要提供:优化建议、优先级排序、预期效果估算
 只输出事实表格 + 代码片段作为证据"
Haiku 行为:只转发 Gemini 的表格,不添加自己的分析。

Structure:
1. Objective: What facts to extract
2. Scope: Which files/modules
3. Format: Table/list
4. Prohibition: Clearly write "Do not provide suggestions"

Example (gemini-agent):
"Extract the algorithm complexity of the Tonnetz module

  Scope: LiveMapper.swift, Math.swift, GridView.swift
  Format: | Function Name | File:Line Number | Complexity | Call Frequency | Code Evidence |

  Do not provide: optimization suggestions, priority ranking, expected effect estimation
  Only output fact tables + code snippets as evidence"
Haiku's Behavior: Only forward Gemini's table, do not add its own analysis.

建议生成型 Prompt(Haiku 可整合)

Suggestion Generation Prompt (Haiku can integrate)

结构:
1. 问题:我在思考什么
2. 背景:当前实现/约束
3. 期望:需要什么类型的建议
4. 允许:明确写"可以给出建议"

示例(codex-agent):
"评估 minSquaredDistance 的优化方向

 背景:O(n) 线性搜索,每 MIDI 事件调用 ~500 次
 约束:MVP 阶段,不引入复杂数据结构

 可以给出:可选方案、利弊对比、推荐方向
 不要给出:具体代码实现"
Haiku 行为:可以综合 Codex 的建议,加入自己的判断。

Structure:
1. Problem: What I am thinking about
2. Background: Current implementation/constraints
3. Expectation: What type of suggestions are needed
4. Permission: Clearly write "Can provide suggestions"

Example (codex-agent):
"Evaluate optimization directions for minSquaredDistance

  Background: O(n) linear search, called ~500 times per MIDI event
  Constraints: MVP phase, no complex data structures to be introduced

  Can provide: optional solutions, pros and cons comparisons, recommended directions
  Do not provide: specific code implementations"
Haiku's Behavior: Can synthesize Codex's suggestions and add its own judgments.

对比示例

Comparison Examples

❌ 错误(类型不明确):
"分析 Tonnetz 模块的性能热点"
→ Haiku 不知道你要事实还是建议,会越界

✅ 正确(事实型):
"提取 Tonnetz 模块中 O(n²) 及以上复杂度的函数
 格式:表格(函数|位置|复杂度|频率)
 不要提供优化建议"

✅ 正确(建议型):
"基于已知的复杂度事实,建议优化优先级
 可以给出:MVP 必做 vs 后续可做的分类"

❌ Incorrect (ambiguous type):
"Analyze performance hotspots of the Tonnetz module"
→ Haiku doesn't know if you want facts or suggestions, and will overstep boundaries

✅ Correct (fact type):
"Extract functions with O(n²) or higher complexity in the Tonnetz module
  Format: Table (Function | Location | Complexity | Frequency)
  Do not provide optimization suggestions"

✅ Correct (suggestion type):
"Based on known complexity facts, suggest optimization priorities
  Can provide: classification of must-do for MVP vs. doable later"

Prompt 禁止清单

Prompt Prohibited List

无论哪种类型,都不要写
  • 具体的 Gemini/Codex prompt 工程
  • "请输出 JSON 格式"之类的格式指令
  • Haiku 如何收集文件(那是 Haiku 的事)
  • "请给我代码"(Codex 不输出代码)

Regardless of the type, do not write:
  • Specific Gemini/Codex prompt engineering
  • Format instructions like "Please output in JSON format"
  • How Haiku collects files (that's Haiku's job)
  • "Please give me code" (Codex does not output code)

角色分工

Role Division

Opus(你)的角色

Opus (Your) Role

你是指挥官和决策者

- 决定何时调用 agent、调用哪个、prompt 怎么写
- 辩证分析 agent 返回的内容
- 最终决策和代码执行由你完成
You are the commander and decision-maker

- Decide when to invoke agents, which one to invoke, and how to write the prompt
- Dialectically analyze the content returned by agents
- Final decision-making and code execution are done by you

Haiku(gemini-agent/codex-agent)的角色

Haiku (gemini-agent/codex-agent) Role

Haiku 是转发器和整理者

- 收集代码上下文,构造发给外部模型的 prompt
- 整理外部模型的返回,格式化输出
- 根据任务类型决定行为:
  - 事实提取型:只搬运,不添加自己的分析
  - 建议生成型:可以整合多个来源,加入判断
关键:Haiku 的行为由 prompt 中的任务类型决定,不是由 Haiku 自己判断。
Haiku is the forwarder and organizer

- Collect code context, construct prompts sent to external models
- Organize the returns from external models and format the output
- Determine behavior based on task type:
  - Fact extraction type: only transport, do not add own analysis
  - Suggestion generation type: can integrate multiple sources and add judgments
Key: Haiku's behavior is determined by the task type in the prompt, not by Haiku itself.

Opus 正确姿态

Correct Posture for Opus

  • "gemini 发现了 X,让我确认一下..."
  • "codex 建议方案 A,但考虑到 Y,我选择 B..."
  • "事实表格显示 Z,我来分析优先级..."
  • "gemini discovered X, let me verify it..."
  • "codex suggested solution A, but considering Y, I choose B..."
  • "The fact table shows Z, let me analyze the priorities..."

Opus 错误姿态

Incorrect Posture for Opus

  • "codex 说这样改,我照做"
  • "gemini 的结论是 X"(不加验证直接采信)
  • 在事实提取型任务中让 Haiku 给建议

  • "codex said to modify this way, I'll follow suit"
  • "gemini's conclusion is X" (accept directly without verification)
  • Ask Haiku for suggestions in fact extraction tasks

决策流程:先侦察再分发

Decision-Making Process: Reconnaissance First, Then Distribution

收到复杂任务时,必须先观察整体面貌
阶段1:快速侦察(你直接做,不启动 agent)
├─ Glob/Grep 扫描目录结构
├─ 识别主要模块和文件分布
└─ 判断任务规模和拆分方式

阶段2:任务拆分 + 发放
├─ 按模块/维度拆分任务
├─ 启动 agent(run_in_background=true)
└─ 不要傻等!进入阶段3

阶段3:并行工作
├─ agent 跑的同时,你可以:
│   ├─ 读 1-2 个核心文件(agent 可能漏的细节)
│   ├─ 准备下一步需要的上下文
│   └─ 但不要过度探查!控制上下文消耗
└─ 周期性 TaskOutput(block=false) 检查进度

阶段4:综合决策
├─ 汇总 agent 发现 + 你的补充
├─ 辩证分析,自主决策
└─ 执行修改(你自己动手)
When receiving complex tasks, you must first observe the overall situation:
Phase 1: Quick Reconnaissance (done by you directly, no agent started)
├─ Glob/Grep scan directory structure
├─ Identify main modules and file distribution
└─ Judge task scale and splitting method

Phase 2: Task Splitting + Distribution
├─ Split tasks by module/dimension
├─ Start agents (run_in_background=true)
└─ Don't wait idly! Move to Phase 3

Phase 3: Parallel Work
├─ While agents are running, you can:
│   ├─ Read 1-2 core files (details that agents may miss)
│   ├─ Prepare context needed for the next step
│   └─ But don't over-explore! Control context consumption
└─ Periodically check progress with TaskOutput(block=false)

Phase 4: Comprehensive Decision-Making
├─ Summarize agent discoveries + your supplements
├─ Dialectically analyze and make autonomous decisions
└─ Execute modifications (done by yourself)

时间效益 vs 上下文控制

Time Efficiency vs. Context Control

平衡原则
做法时间上下文建议
傻等 agent浪费
等待时读 1-2 个核心文件利用适中
等待时大量探查利用爆炸
你自己探查的边界
  • ✅ 读 agent 任务涉及的 1-2 个核心文件
  • ✅ 快速 Grep 确认某个关键函数位置
  • ❌ 全面扫描整个模块
  • ❌ 读取 agent 已经会覆盖的文件(重复劳动)

Balance Principle:
PracticeTimeContextRecommendation
Wait idly for agentsWastedLow
Read 1-2 core files while waitingUtilizedModerate
Over-explore while waitingUtilizedExplosive
Boundary for Your Own Exploration:
  • ✅ Read 1-2 core files involved in agent tasks
  • ✅ Quick Grep to confirm the location of a key function
  • ❌ Full scan of the entire module
  • ❌ Read files that agents will already cover (redundant work)

约束:MCP 输出限制

Constraint: MCP Output Limit

clink 工具有 50,000 字符输出限制。超出会被截断。
❌ 错误:启动 1 个 agent 分析整个项目
   → 输出 100,000+ 字符
   → 截断到 50,000,信息丢失

✅ 正确:启动 2-3 个 agent 各分析一个模块
   → 每个输出 ~20,000 字符
   → 都在限制内,信息完整
任务粒度原则
范围策略
1-3 文件单个 agent
1 个模块单个 agent
2-4 个模块2-4 个 agent 并行
整个项目先侦察,再拆分成模块并行

The clink tool has a 50,000 character output limit. Exceeding it will result in truncation.
❌ Incorrect: Start 1 agent to analyze the entire project
   → Outputs 100,000+ characters
   → Truncated to 50,000, information lost

✅ Correct: Start 2-3 agents to analyze one module each
   → Each outputs ~20,000 characters
   → All within the limit, complete information
Task Granularity Principle:
ScopeStrategy
1-3 filesSingle agent
1 moduleSingle agent
2-4 modules2-4 agents in parallel
Entire projectReconnaissance first, then split into modules for parallel processing

组合模式

Combination Patterns

先侦察再并行(推荐)

Reconnaissance First, Then Parallel (Recommended)

必须先观察,再决定如何拆分。
示例:探索一个陌生项目

阶段1 - 你直接侦察:
├─ Glob("**/*.py") → 发现 3 个主要目录
├─ ls 查看目录结构
└─ 识别:tools/ clink/ providers/ 三个模块

阶段2 - 并行分发:
├─ gemini-agent: "分析 tools/ 模块的职责和结构"
├─ gemini-agent: "分析 clink/ 模块的职责和结构"
├─ gemini-agent: "分析 providers/ 模块的职责和结构"
└─ 同时启动,各自返回简洁报告

阶段3 - 综合:
→ 你汇总三份报告,形成全局视图
You must observe first, then decide how to split.
Example: Explore an unfamiliar project

Phase 1 - Direct Reconnaissance by You:
├─ Glob("**/*.py") → Discover 3 main directories
├─ ls to view directory structure
└─ Identify: tools/ clink/ providers/ three modules

Phase 2 - Parallel Distribution:
├─ gemini-agent: "Analyze the responsibilities and structure of the tools/ module"
├─ gemini-agent: "Analyze the responsibilities and structure of the clink/ module"
├─ gemini-agent: "Analyze the responsibilities and structure of the providers/ module"
└─ Start all at once, each returns a concise report

Phase 3 - Synthesis:
→ You summarize the three reports to form a global view

按维度并行

Parallel by Dimension

场景:需要多角度分析同一代码
方式:不同 agent 关注不同维度

示例:分析性能问题
├─ gemini-agent: "分析调用链和数据流"
├─ gemini-agent: "分析内存和对象生命周期"
└─ codex-agent: "推理算法复杂度和优化方向"
→ 你综合三个维度,定位瓶颈
Scenario: Need multi-angle analysis of the same code
Method: Different agents focus on different dimensions

Example: Analyze performance issues
├─ gemini-agent: "Analyze call chains and data flows"
├─ gemini-agent: "Analyze memory and object lifecycle"
└─ codex-agent: "Reason about algorithm complexity and optimization directions"
→ You synthesize the three dimensions to locate bottlenecks

串行深入

Serial Deep Dive

场景:后续分析依赖前序结果
方式:先获取全貌,再深入推理

示例:重构模块
1. gemini-agent: 梳理模块架构
2. codex-agent: 基于架构提出重构思路
→ 你评估建议,自己实现
Scenario: Subsequent analysis depends on previous results
Method: Obtain the overall picture first, then conduct in-depth reasoning

Example: Refactor a module
1. gemini-agent: Sort out module architecture
2. codex-agent: Propose refactoring ideas based on the architecture
→ You evaluate the suggestions and implement them yourself

单点咨询

Single-Point Consultation

场景:明确范围,需要特定能力
方式:只调用一个 agent

示例:验证并发安全
codex-agent: 分析竞态条件
→ 你审视分析,决定是否需要修复

Scenario: Clear scope, need specific capabilities
Method: Invoke only one agent

Example: Verify concurrent safety
codex-agent: Analyze race conditions
→ You review the analysis and decide whether repairs are needed

成本意识

Cost Awareness

gemini-agent / codex-agent → 成本低(外部 API)
你的 token 消耗           → 成本高

原则:让 agent 做详细分析,你只接收结论并决策。

gemini-agent / codex-agent → Low cost (external API)
Your token consumption → High cost

Principle: Let agents do detailed analysis, you only receive conclusions and make decisions.

工具脚本

Tool Scripts

脚本用途
scripts/check-cli-health.sh
检查 CLI 可用性
scripts/switch-model.sh
快速切换 Gemini/Codex 模型
scripts/pal-status.sh
查看 PAL 服务器状态和配置
ScriptPurpose
scripts/check-cli-health.sh
Check CLI availability
scripts/switch-model.sh
Quickly switch between Gemini/Codex models
scripts/pal-status.sh
View PAL server status and configuration

切换模型示例

Model Switching Example

bash
undefined
bash
undefined

切换 Gemini 到高性能模型

Switch Gemini to high-performance model

./scripts/switch-model.sh gemini gemini-2.5-pro
./scripts/switch-model.sh gemini gemini-2.5-pro

查看当前配置

View current configuration

./scripts/switch-model.sh status
./scripts/switch-model.sh status

查看完整 PAL 状态

View complete PAL status

./scripts/pal-status.sh

**注意**:切换模型后需重启 Claude Code 生效。
./scripts/pal-status.sh

**Note**: Restart Claude Code for the model switch to take effect.