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+ 文件探索、功能流程追踪、模块全景分析 |
| 调用 | |
| Attribute | Description |
|---|---|
| Strengths | Large-scale scanning, 1M context window, architecture sorting, dependency analysis |
| Use Cases | Exploration of 5+ files, functional process tracing, module panoramic analysis |
| Invocation | |
codex-agent — 顾问
codex-agent — Consultant
| 属性 | 说明 |
|---|---|
| 擅长 | 深度推理、逻辑验证、方案评估、复杂算法分析 |
| 定位 | 提供思路和建议,不执行代码修改 |
| 调用 | |
| Attribute | Description |
|---|---|
| Strengths | In-depth reasoning, logic verification, solution evaluation, complex algorithm analysis |
| Positioning | Provides ideas and suggestions, does not execute code modifications |
| Invocation | |
如何写 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:
| Type | Purpose | Haiku's Role | Output Features |
|---|---|---|---|
| Fact Extraction | Understand the current situation | Transporter | Tables, code evidence, no subjective judgments |
| Suggestion Generation | Make decisions | Integrator | Solution 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 youHaiku(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 judgmentsKey: 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:
| Practice | Time | Context | Recommendation |
|---|---|---|---|
| Wait idly for agents | Wasted | Low | ❌ |
| Read 1-2 core files while waiting | Utilized | Moderate | ✅ |
| Over-explore while waiting | Utilized | Explosive | ❌ |
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 informationTask Granularity Principle:
| Scope | Strategy |
|---|---|
| 1-3 files | Single agent |
| 1 module | Single agent |
| 2-4 modules | 2-4 agents in parallel |
| Entire project | Reconnaissance 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
| 脚本 | 用途 |
|---|---|
| 检查 CLI 可用性 |
| 快速切换 Gemini/Codex 模型 |
| 查看 PAL 服务器状态和配置 |
| Script | Purpose |
|---|---|
| Check CLI availability |
| Quickly switch between Gemini/Codex models |
| View PAL server status and configuration |
切换模型示例
Model Switching Example
bash
undefinedbash
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.