agent-collaboration

Agent 协作

将多个 AI 模型编排为各有所长的专业 Agent——每个 Agent 都负责最擅长的工作。一个模型负责规划，另一个负责编码，还有一个负责审查。规划者始终参与其中，在每个阶段结束后重新介入，评估结果并调整方向。

---

适用场景

• 需要规划、实现和审查的复杂项目
• 单个模型的盲点可能带来风险的任务
• 希望通过对抗性审查发现自我审查无法发现的问题
• 需要网络搜索、综合和验证的研究密集型工作
• 需要专门推理能力的数学或科学任务
• 任何适合采用“规划 → 执行 → 审查 → 重新规划”循环的任务
• 用户明确要求多模型协作时

不适用场景

• 单行修复、拼写更正、简单问题
• 完全属于单个模型能力范围的任务
• 速度比周全性更重要时
• 没有明确交付成果的探索性对话

---

理念

没有一个模型能在所有方面都做到最好。 基准测试一再表明，不同模型系列各有所长。Claude Opus 擅长规划和抽象推理。GPT-5.4 在代码实现方面领先。Gemini 3.1 Pro 在数学、科学和知识检索方面表现出色。Grok 4 则带来不同寻常的视角。将这些模型作为专业 Agent 组合起来，在复杂任务上的表现优于任何单个模型。

规划者是指挥者。 它负责拆解任务、分派工作、评估结果并重新规划。所有其他 Agent 都向规划者汇报。规划者绝不编辑文件——它会读取代码以了解上下文，并启动子 Agent，但它的职责是指挥，而非亲自执行。

对抗性审查不可或缺。 由不同模型系列负责审查，可以发现自我审查无法发现的失败模式。对抗性审查者的任务是发现问题，而不是委婉客气。

Agent 可以替换，上下文不能丢失。 每个 Agent 都可以是无状态的，但 Agent 之间的交接必须保留所有相关上下文。规划者有责任确保不同阶段之间不丢失任何信息。

---

七个 Agent

1. 规划者

• 职责： 将复杂任务拆解为子任务，为每项任务分配合适的 Agent，定义成功标准，评估结果，并在需要时重新规划
• 主要模型： Claude Opus 4.6（扩展思考）
• 备用模型： Claude Opus 4.5、GPT-5.4（高推理能力）
• 选择 Opus 的原因： Arena 总排名第 1（1504 Elo），Hard Prompts 排名第 1，抽象推理能力最佳（ARC-AGI 2：68.8%）。扩展思考擅长结构化拆解和多步骤规划
• 工具： 不编辑文件。规划者会读取代码、运行只读 Shell 命令（git log、ls）并启动子 Agent，但绝不写入或编辑文件
• 输出： 采用 YAML 格式的结构化计划，包含子任务分配、依赖关系和成功标准

2. 编码者

• 职责： 实现代码变更、编写测试、修复 Bug、重构。严格遵循计划
• 主要模型： GPT-5.4（高推理能力）
• 备用模型： Claude Sonnet 4.5、Claude Sonnet 4.6
• 选择 GPT-5.4 的原因： 在 Aider 编码排行榜上领先（88%）。速度快、准确度高，擅长将计划转化为可运行的代码
• 选择 Sonnet 4.5 作为备用模型的原因： 在 SWE-bench Verified 上领先（82%）。擅长处理真实世界的软件工程任务
• 工具： 完整的文件系统访问权限——读取、写入、编辑、终端、包管理器
• 输出： 已变更文件、测试结果、实现摘要

3. 研究员

• 职责： 网页搜索、文档查找、API 探索、文献综述、竞品分析、总结
• 主要模型： Gemini 3.1 Pro
• 备用模型： Claude Opus 4.6
• 选择 Gemini 3.1 Pro 的原因： 在 Humanity's Last Exam 中排名领先（45.8%），MMMLU 得分位居前列（91.8%）。擅长在广泛的知识领域中查找和综合信息
• 选择 Opus 作为备用模型的原因： 在 BrowseComp（网页研究综合）中表现最佳。擅长关联不同来源的信息
• 工具： 网页搜索、网页抓取、文件读取。不编辑文件——研究员负责提供报告，不负责实现
• 输出： 附有来源归属的研究摘要、关键发现，以及与决策相关的权衡

4. 科学家

• 职责： 数学推理、形式证明、统计建模、数据分析、算法验证、科学计算
• 主要模型： Gemini 3 Pro
• 备用模型： GPT 5.2、Claude Opus 4.6
• 选择 Gemini 3 Pro 的原因： AIME 2025 得分 100%，GPQA Diamond 得分 94.3%。擅长逐步数学推理和形式证明
• 选择 GPT 5.2 作为备用模型的原因： AIME 2025 同样得分 100%，GPQA Diamond 得分 92.4%
• 工具： 代码执行（用于计算和验证）、文件读写（用于结果）。通常不需要网页访问
• 输出： 形式化分析、证明，以及附有方法说明的计算结果

5. 视觉分析师

• 职责： 图像分析、UI/UX 审查、图表解读、截图分析、视觉回归检测、设计系统合规性检查
• 主要模型： Claude Opus 4.6
• 备用模型： Gemini 3.1 Pro
• 选择 Opus 的原因： ARC-AGI 2：68.8%（在抽象视觉推理方面遥遥领先）。多模态理解能力出色，且能生成结构化输出
• 选择 Gemini 作为备用模型的原因： MMMU-Pro 得分 80.5%。擅长解读复杂的视觉内容
• 工具： 图像读取、截图捕获、文件读取。不编辑文件——仅报告视觉发现
• 输出： 视觉分析报告，列出具体观察结果、问题和建议

6. 对抗性审查员

• 职责： 查找缺陷、安全漏洞、边缘情况、逻辑错误、不正确的假设、竞态条件和性能问题。质疑每一项决策。在证明代码正确之前，先假定它存在问题
• 主要模型： Grok 4
• 备用模型： Gemini 3.1 Pro、Claude Opus 4.6
• 选择 Grok 4 的原因： Arena 综合排名第 4，沟通风格直接且善于质疑。采用与编码者根本不同的模型系列，可确保审查真正具有对抗性，而非自我肯定
• 采用不同模型系列的重要性： 同一系列的模型往往有相似的盲点。跨系列审查能发现同系列审查遗漏的问题
• 工具： 只读。对抗性审查员绝不编辑，只按严重程度排序列出问题
• 输出： 问题列表，包含严重程度（严重/高/中/低）、复现步骤和建议的修复方案

7. 同行评审员

• 职责： 质量评估、架构审查、风格一致性检查、最佳实践检查、文档审查、可维护性分析
• 主要模型： Claude Opus 4.6
• 备用模型： GPT-4o
• 选择 Opus 的原因： 擅长结构清晰、全面深入的分析，能兼顾实用性与质量标准
• 选择 GPT-4o 作为备用模型的原因： 在同行评审中表现出较低的正向偏见（据 Sakana AI 的 AI Scientist 研究）。诚实直率，但并不苛刻
• 工具： 只读。提供评审意见，并明确给出结论：批准、要求修改或拒绝
• 输出： 结构化评审，包含结论、对合理决策的肯定，以及具体的修改要求

---

工作原理

这是一种手动调度工作流——由你（或你的主 Agent 会话）担任调度者。各 Agent 不会自行协调。你需要按照下面的编排循环，在需要时调用各 Agent，并使用交接协议在它们之间传递上下文。该技能提供工作流模式、Agent 定义和交接格式；具体判断则由你负责。

编排循环

每个复杂任务都遵循此循环。规划器始终是入口和出口。

┌──────────────────────────────────────────────┐
│                  PLANNER                      │
│           Claude Opus 4.6 (thinking)          │
│                                               │
│  1. Analyze the full task and constraints      │
│  2. Break into concrete subtasks              │
│  3. Assign each subtask to an agent role      │
│  4. Define success criteria per subtask       │
│  5. Specify execution order and dependencies  │
│  6. Identify which subtasks can run parallel  │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│             EXECUTION PHASE                   │
│     (parallel where no dependencies)          │
│                                               │
│  ┌──────────┐ ┌───────────┐ ┌──────────┐    │
│  │  Coder   │ │Researcher │ │Scientist │    │
│  │ GPT-5.4  │ │Gemini 3.1 │ │Gemini 3  │    │
│  └────┬─────┘ └─────┬─────┘ └────┬─────┘    │
│       │             │             │           │
│       ▼             ▼             ▼           │
│  ┌────────────────────────────────────────┐  │
│  │       Results + Artifacts               │  │
│  └────────────────────────────────────────┘  │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│              REVIEW PHASE                     │
│  (both reviewers in parallel for Patterns A-D)│
│                                               │
│  ┌───────────────┐  ┌───────────────┐        │
│  │  Adversarial  │  │     Peer      │        │
│  │    Grok 4     │  │  Claude Opus  │        │
│  └───────┬───────┘  └───────┬───────┘        │
│          │                  │                 │
│          ▼                  ▼                 │
│  ┌────────────────────────────────────────┐  │
│  │     Review Verdicts + Issue Lists       │  │
│  └────────────────────────────────────────┘  │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│            PLANNER RE-ENTERS                  │
│                                               │
│  Evaluates all review feedback:               │
│                                               │
│  • All clear → Accept and complete            │
│  • Minor issues → Send back to coder          │
│  • Major issues → Replan from scratch         │
│  • Reviewers disagree → Planner adjudicates   │
│  • New information → Update plan, re-execute  │
└──────────────────────────────────────────────┘

最大迭代次数

为防止无限循环，请遵守以下限制：

• 编码 → 审查循环： 最多 3 次迭代。如果编码者经过 3 轮后仍未满足审查者的要求，规划器必须简化方案或向用户升级处理
• 完整重新规划： 每项任务最多重新规划 2 次。超过 2 次后，规划器应提交现有成果并记录已知问题
• 单个 Agent 超时： 如果任何 Agent 经过合理努力后仍未产出有用结果，规划器应将任务重新分配给备用模型或简化子任务

---

交接协议

Agent 之间传递工作时，交接必须采用结构化格式。每次交接都由规划器构建，Agent 之间不会直接通信。

实用说明： 以下 YAML 格式是理想化模板，而非严格约定。实际模型不一定总能输出完美的 YAML。规划器应从 Agent 产出的任何格式中提取相关信息，无论是结构化 YAML、Markdown 还是自由文本。重要的是信息能在各阶段之间正确传递，而不是格式完全一致。如果 Agent 返回的是自由文本而非 YAML，规划器应提取关键字段（状态、摘要、变更的文件、发现的问题），并手动构建下一次交接。

规划器 → 执行 Agent

handoff:
  to: coder                           # agent role
  task_id: 2
  description: "Implement OAuth2 PKCE flow"
  context: |
    The codebase uses JWT tokens stored in httpOnly cookies.
    Middleware at /api/auth/middleware.ts validates tokens on every request.
    The researcher found 3 existing auth patterns (see research summary below).
    Extend the JWT pattern — do not replace it.
  dependencies_resolved:
    - task_id: 1
      agent: researcher
      summary: "Found JWT, session, and API key auth patterns. JWT is most recent."
      key_files:
        - /api/auth/jwt.ts (lines 1-45)
        - /api/auth/middleware.ts (lines 12-30)
  constraints:
    - "Must extend existing JWT pattern, not replace it"
    - "Must be backward-compatible with existing middleware"
    - "Must include tests"
  success_criteria:
    - "OAuth2 PKCE flow works end-to-end"
    - "Existing auth tests still pass"
    - "New tests cover PKCE-specific scenarios"

执行 Agent → 规划器（结果）

result:
  from: coder
  task_id: 2
  status: complete                     # complete | partial | failed | blocked
  summary: "Implemented PKCE flow in 3 files, added 8 tests"
  artifacts:
    files_changed:
      - /api/auth/pkce.ts (new, 120 lines)
      - /api/auth/middleware.ts (modified, added PKCE validation)
      - /api/auth/__tests__/pkce.test.ts (new, 85 lines)
    test_results: "8 passed, 0 failed"
  notes: |
    Used crypto.subtle for code verifier generation (Web Crypto API).
    The middleware change is backward-compatible — existing JWT auth still works.
  concerns:
    - "Code verifier storage uses session — may need Redis for horizontal scaling"

规划器 → 审查 Agent

handoff:
  to: adversarial_reviewer
  task_id: 4
  description: "Security audit of OAuth2 PKCE implementation"
  context: |
    The coder implemented a PKCE flow. Review for security vulnerabilities,
    edge cases, and correctness. Be especially critical of:
    - Cryptographic operations (code verifier, code challenge)
    - Token storage and transmission
    - CSRF and replay attack vectors
    - Error handling in auth flows
  artifacts_to_review:
    - /api/auth/pkce.ts
    - /api/auth/middleware.ts
    - /api/auth/__tests__/pkce.test.ts
  implementation_summary: |
    Uses crypto.subtle for code verifier. Session-based storage.
    Middleware validates PKCE alongside existing JWT.

审查 Agent → 规划器（结论）

verdict:
  from: adversarial_reviewer
  task_id: 4
  decision: request_changes            # approve | request_changes | reject
  critical_issues:
    - severity: high
      location: /api/auth/pkce.ts:45
      issue: "Code verifier stored in plaintext session — if session is compromised, PKCE is defeated"
      suggestion: "Hash the verifier before storage, compare hashes on validation"
    - severity: medium
      location: /api/auth/pkce.ts:78
      issue: "No expiration on code challenge — replay attack window is unlimited"
      suggestion: "Add 10-minute TTL on challenge, clean up expired entries"
  minor_issues:
    - severity: low
      location: /api/auth/__tests__/pkce.test.ts
      issue: "No test for expired challenge scenario"
  positive_observations:
    - "Good use of crypto.subtle over Math.random for verifier generation"
    - "Backward compatibility with existing JWT flow is well-handled"

---

工作流模式

模式 A：规划 → 编码 → 审查（默认）

适用于大多数开发任务的常用模式。

Planner → Coder → [Adversarial + Peer Review] → Planner

适用场景： 添加功能、修复错误、重构代码。大多数任务都从这里开始。

规划器行为： 制定一份包含清晰子任务的计划。审查后，决定接受、修改还是重新开始。

模式 B：研究 → 规划 → 编码 → 审查

适用于需要先理解再实施的任务。

Planner → Researcher → Planner (replan) → Coder → [Review] → Planner

适用场景： 使用不熟悉的 API、在不同架构方案之间做选择、集成任务，以及任何需要先获取信息才能制定计划的工作。

规划器行为： 第一份计划仅包含“研究阶段”。研究完成后，规划器会制定一份新的、充分了解情况的实施计划。

模式 C：深度分析

适用于数学密集型、科学或视觉推理任务。

Planner → [Scientist + Visual Analyst + Researcher] → Planner → Coder → [Review] → Planner

适用场景： 数据管道、ML 模型、算法实现、视觉回归测试，以及任何需要形式化正确性的工作。

规划器行为： 在制定实施计划前，收集多位专业 Agent 的分析结果。科学家的输出会直接约束编码者的工作范围。

模式 D：完整流程

适用于大型复杂任务的完整工作流。

Planner → Researcher → Planner (replan) → [Coder + Scientist] → Visual Analyst → [Adversarial + Peer Review] → Planner

适用场景： 重要功能、系统设计、架构变更，以及任何风险较高的工作。

规划器行为： 多轮重新规划。实施后由视觉分析师检查 UI。验收前进行完整审查。

模式 E：快速迭代

适用于无需完整审查的快速修复。

Planner → Coder → Adversarial Reviewer → Planner

适用场景： 小型错误修复、小幅重构、文档更新。跳过同行审查者——对抗性检查能够发现安全性和正确性问题，对小幅变更来说已经足够。

规划器行为： 轻量级计划、单轮审查、快速完成。

模式 F：仅研究

适用于只需获取信息而无需实施的情况。

Planner → [Researcher + Scientist] → Planner → Summary

适用场景： 技术调查、可行性研究、竞品分析、决策支持。

规划器行为： 将研究和分析综合成可直接用于决策的摘要。不编写代码。

---

规划器输出格式

规划器会生成结构化计划，供其他 Agent 遵循。请使用以下格式：

plan:
  task: "Description of the overall task"
  pattern: A                             # Which workflow pattern (A-F)
  
  subtasks:
    - id: 1
      description: "Research existing auth patterns in the codebase"
      agent: researcher
      depends_on: []
      success_criteria: "Summary of auth patterns with file locations and recommendations"
    
    - id: 2
      description: "Implement OAuth2 PKCE flow extending existing JWT auth"
      agent: coder
      depends_on: [1]
      success_criteria: "Working OAuth2 PKCE flow with tests passing, backward-compatible"
    
    - id: 3
      description: "Verify cryptographic correctness of PKCE implementation"
      agent: scientist
      depends_on: [2]
      success_criteria: "Formal verification that entropy, hashing, and timing are correct"
    
    - id: 4
      description: "Security audit — find vulnerabilities and edge cases"
      agent: adversarial_reviewer
      depends_on: [2]
      success_criteria: "Security audit with no unaddressed critical or high issues"
    
    - id: 5
      description: "Architecture and quality review"
      agent: peer_reviewer
      depends_on: [2]
      success_criteria: "Approved or specific changes requested"
  
  execution_order:
    - phase: 1
      parallel: [1]
    - phase: 2
      parallel: [2]
    - phase: 3
      parallel: [3, 4, 5]
  
  notes: |
    Subtasks 3, 4, 5 can run in parallel since they all review the same output.
    If review finds critical issues, we loop back to subtask 2 with fixes.

---

按工具设置

OpenCode（推荐用于多提供商）

OpenCode 原生支持 75+ 个大模型提供商，并支持为每个 Agent 单独覆盖模型。无需网关——OpenCode 本身就是网关。

API 密钥

将提供商 API 密钥设置为环境变量。你只需要为计划使用的提供商设置密钥——选择直接提供商或云提供商（Bedrock/Azure），也可以混合搭配：

# --- Direct providers ---
export ANTHROPIC_API_KEY="sk-ant-..."
export OPENAI_API_KEY="sk-..."
export GOOGLE_API_KEY="..."            # or GOOGLE_GENERATIVE_AI_API_KEY
export XAI_API_KEY="..."

# --- Amazon Bedrock (alternative for Claude + other models) ---
export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."
export AWS_REGION="us-east-1"          # or us-west-2, eu-west-1, etc.

# --- Microsoft Azure OpenAI (alternative for GPT models) ---
export AZURE_API_KEY="..."
export AZURE_RESOURCE_NAME="your-resource"
export AZURE_DEPLOYMENT_NAME="your-deployment"
export AZURE_API_VERSION="2024-12-01-preview"

# --- Google Vertex AI (alternative for Gemini models) ---
export GOOGLE_CLOUD_PROJECT="your-project"
export GOOGLE_APPLICATION_CREDENTIALS="/path/to/service-account.json"
# export GOOGLE_GENAI_USE_VERTEXAI=true

提供商配置（opencode.json）

配置你要使用的提供商。无需全部配置——根据你的基础设施选择合适的提供商：

{
  "provider": {
    "anthropic": {
      "api_key": "{env:ANTHROPIC_API_KEY}"
    },
    "openai": {
      "api_key": "{env:OPENAI_API_KEY}"
    },
    "google": {
      "api_key": "{env:GOOGLE_API_KEY}"
    },
    "xai": {
      "api_key": "{env:XAI_API_KEY}"
    },
    "bedrock": {
      "aws_access_key_id": "{env:AWS_ACCESS_KEY_ID}",
      "aws_secret_access_key": "{env:AWS_SECRET_ACCESS_KEY}",
      "aws_region": "{env:AWS_REGION}"
    },
    "azure": {
      "api_key": "{env:AZURE_API_KEY}",
      "resource_name": "{env:AZURE_RESOURCE_NAME}"
    },
    "vertex": {
      "project": "{env:GOOGLE_CLOUD_PROJECT}"
    }
  }
}

Agent 定义

Agent 定义由规范模板通过设置脚本生成。请在技能目录中运行：

# Project-level (recommended)
sh agents/setup.sh opencode

# Or specify a custom target directory
sh agents/setup.sh opencode ~/.config/opencode/agents

这会生成 7 个 .md Agent 文件，并在 .opencode/agents/ 中设置正确的 OpenCode frontmatter（model: provider/id、permission: edit: deny）。

每个 Agent 使用不同的提供商/模型。OpenCode 会根据模型前缀自动路由到正确的提供商。

默认分配（直接提供商）：

Agent	模型 ID	提供商
规划器	anthropic/claude-opus-4-6	Anthropic
编码器	openai/gpt-5.4	OpenAI
研究员	google/gemini-3.1-pro	Google
科学家	google/gemini-3-pro	Google
视觉分析师	anthropic/claude-opus-4-6	Anthropic
对抗性审查员	xai/grok-4	xAI
同行审查员	anthropic/claude-opus-4-6	Anthropic

Amazon Bedrock 替代方案——在 Agent 的 .md 文件中替换模型 ID，即可改为通过 Bedrock 路由：

Agent	Bedrock 模型 ID
规划器	bedrock/anthropic.claude-opus-4-6-v1
编码器	bedrock/anthropic.claude-sonnet-4-5-v1
研究员	bedrock/amazon.nova-pro-v1
科学家	bedrock/anthropic.claude-opus-4-6-v1
视觉分析师	bedrock/anthropic.claude-opus-4-6-v1
对抗性审查员	bedrock/amazon.nova-pro-v1
同行审查员	bedrock/anthropic.claude-opus-4-6-v1

注意：使用 Bedrock 可调用 Claude 模型，无需单独的 Anthropic API 密钥（费用通过 AWS 结算）。Bedrock 不提供 Gemini 和 Grok——可改用 Amazon Nova 或 Claude，或将 Bedrock 与直接提供商混合使用。

Microsoft Azure OpenAI 替代方案——适用于使用 Azure 的组织：

Agent	Azure 模型 ID
规划器	azure/claude-opus-4-6
编码器	azure/gpt-5.4
研究员	azure/gpt-5.4
科学家	azure/gpt-5.4
视觉分析师	azure/claude-opus-4-6
对抗性审查员	azure/gpt-4o
同行审查员	azure/claude-opus-4-6

注意：Azure OpenAI 模型 ID 取决于你的部署名称。上面的 ID 假设部署名称与模型名称一致。Azure 可通过 Azure AI Foundry 提供 GPT 和 Claude 模型，费用通过 Azure 订阅结算。Azure 不提供 Gemini 和 Grok——可改用 GPT-4o 或 Claude，或将 Azure 与直接提供商混合使用。

Google Vertex AI 替代方案——适用于使用 GCP 的组织：

Agent	Vertex AI 模型 ID
研究员	vertex/gemini-3.1-pro
科学家	vertex/gemini-3-pro
视觉分析师	vertex/gemini-3.1-pro

注意：Vertex AI 可提供 Gemini 模型，费用通过 GCP 结算。也可通过 Vertex AI Model Garden 使用 Claude。

**建议混合使用多个提供商。**你不必只选择一个云平台——可以通过 Bedrock 使用 Claude、通过 Azure 使用 GPT，并直接使用 Gemini 和 Grok。只需更改每个 Agent .md 文件中的模型前缀。

调用 Agent

在 OpenCode 中，按名称调用 Agent。编排 Agent（即你这个主 Agent）遵循上述工作流模式：

@planner Break down this task: implement user authentication with OAuth2 PKCE

然后按计划执行，并根据指示调用各个 Agent：

@researcher Find existing auth patterns in this codebase
@coder Implement PKCE flow based on the research findings: [paste context]
@adversarial-reviewer Review this PKCE implementation for security issues: [paste context]
@peer-reviewer Review code quality and architecture: [paste context]

---

Claude Code

Claude Code 拥有成熟的子 Agent 架构，但子 Agent 仅限使用 Anthropic 模型。根据你是否需要跨提供商访问，可选择以下三种方案：

方法 1：仅使用 Anthropic（无网关）

所有 Agent 都使用 Anthropic 模型。你会失去跨系列对抗性审查的能力，但配置更简单。

Agent	Claude Code 模型	说明
规划者	opus	扩展思考，不编辑文件
编码者	sonnet	速度快，擅长编写代码
研究者	opus	擅长综合分析，搭配网络工具使用
科学家	opus	数学能力尚可
视觉分析师	opus	Anthropic 系列中多模态能力最佳
对抗性审查者	sonnet	与 opus 不同，但属于同一系列——对抗性审查效果较弱
同行评审者	opus	结构化分析

局限性： 同一模型系列的对抗性审查效果较差。让使用 Sonnet 的对抗性审查者采用强有力的对抗性提示词，可以部分弥补这一点，但同系列模型的盲点依然存在。

Agent 定义文件： 使用设置脚本从规范模板生成：

sh agents/setup.sh claude-code

这会在 .claude/agents/ 中生成 7 个 Agent .md 文件，其中包含 Anthropic 专用的 frontmatter（model: opus/sonnet、allowed-tools、effort）。

方法 2：搭配 OpenRouter 网关

使用 MCP 服务或脚本，为特定 Agent 调用外部模型。这样即可进行真正的跨系列对抗性审查。

步骤 1： 设置 OpenRouter API 密钥：

export OPENROUTER_API_KEY="sk-or-..."

步骤 2： 创建网关脚本目录和脚本：

mkdir -p .claude/scripts
cat > .claude/scripts/call-model.sh << 'SCRIPT'
#!/bin/bash
# Usage: call-model.sh <model> <prompt-file>
# Reads prompt from a file to avoid shell argument length limits.
# If no file given, reads from stdin.
MODEL="$1"
PROMPT_FILE="$2"

if [ -z "$OPENROUTER_API_KEY" ]; then
  echo "Error: OPENROUTER_API_KEY not set" >&2
  exit 1
fi

if [ -n "$PROMPT_FILE" ] && [ -f "$PROMPT_FILE" ]; then
  PROMPT=$(cat "$PROMPT_FILE")
elif [ ! -t 0 ]; then
  PROMPT=$(cat)
else
  PROMPT="$2"
fi

RESPONSE=$(curl -s https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{
    \"model\": \"$MODEL\",
    \"messages\": [{\"role\": \"user\", \"content\": $(echo "$PROMPT" | jq -Rs .)}]
  }")

ERROR=$(echo "$RESPONSE" | jq -r '.error.message // empty')
if [ -n "$ERROR" ]; then
  echo "API Error: $ERROR" >&2
  exit 1
fi

echo "$RESPONSE" | jq -r '.choices[0].message.content'
SCRIPT
chmod +x .claude/scripts/call-model.sh

步骤 3： 在 Claude Code 中，负责协调的 Agent 可以使用此脚本进行跨提供商调用：

# Call Grok for adversarial review (short prompt as argument)
bash .claude/scripts/call-model.sh "xai/grok-4" "Review this code for security issues: ..."

# Call Gemini for research (long prompt via stdin)
echo "Research the best approach for implementing OAuth2 PKCE..." | \
  bash .claude/scripts/call-model.sh "google/gemini-3.1-pro"

这种混合方案使用 Claude Code 的原生子 Agent 调用 Anthropic 模型，并使用网关脚本调用其他提供商的模型。

方法 3：搭配 Vercel AI Gateway

与 OpenRouter 方案相同，但使用 Vercel 的网关端点：

#!/bin/bash
# .claude/scripts/call-model.sh (Vercel AI Gateway version)
MODEL="$1"
PROMPT="$2"

curl -s https://ai-gateway.vercel.sh/v1/chat/completions \
  -H "Authorization: Bearer $AI_GATEWAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{
    \"model\": \"$MODEL\",
    \"messages\": [{\"role\": \"user\", \"content\": $(echo "$PROMPT" | jq -Rs .)}]
  }" | jq -r '.choices[0].message.content'

Vercel AI Gateway 的优势： 不加收 Token 费用，支持 40 多家提供商，为部署在 Vercel 上的应用提供 OIDC 身份验证（无需管理密钥）。

---

Cursor

Cursor 不支持以编程方式启动子 Agent。请按顺序切换模型：

1. 在模型选择器中选择 Claude Opus → 规划任务
2. 切换到 GPT-5.4 → 执行计划
3. 切换到 Grok 4 或 Gemini → 审查实现
4. 切回 Claude Opus → 评估审查结果并决定后续步骤

Cursor 规则（.cursor/rules/）

创建指导各阶段的规则。将其放在 .cursor/rules/ 中：

.cursor/rules/agent-collaboration.mdc

---
description: Multi-model agent collaboration workflow
globs: ["**/*"]
---

# Agent Collaboration Workflow

When working on complex tasks, follow this workflow:

## Planning Phase (use Claude Opus)
- Break the task into subtasks with clear success criteria
- Identify dependencies between subtasks
- Assign each subtask to an execution phase

## Implementation Phase (use GPT-5.4 or Claude Sonnet)
- Follow the plan exactly
- Write tests for new functionality
- Report what changed and why

## Review Phase (switch model for fresh perspective)
- Review for security vulnerabilities, edge cases, and logical errors
- Check architecture, style, and best practices
- Provide explicit verdict: approve or request changes

## Replan Phase (use Claude Opus)
- Evaluate review feedback
- Decide: accept, revise, or restart
- If revising, specify exact changes for the coder

---

Codex CLI

Codex CLI 支持 Agent Skills 标准，主要使用 OpenAI 模型。要使用多模型：

1. 由 Codex 负责实现（原生使用 GPT-5.4）
2. 使用网关脚本调用其他模型（采用与 Claude Code 相同的 call-model.sh 方案）

按照标准格式将 Agent 技能放在 .codex/skills/ 中。

环境设置

# Codex uses your ChatGPT account or API key
export OPENAI_API_KEY="sk-..."

# For cross-provider calls via gateway
export OPENROUTER_API_KEY="sk-or-..."

---

Gemini CLI

Gemini CLI 仅支持单 Agent 和 Gemini 模型。请使用顺序模式：

1. 使用 Gemini 3.1 Pro 进行规划和研究（它两方面都很擅长）
2. 使用网关脚本 编写代码（通过 OpenRouter 调用 GPT-5.4）
3. 使用 Gemini 3.1 Pro 进行审查（擅长对抗性分析）

集成 GEMINI.md

将工作流说明添加到 GEMINI.md：

# Agent Collaboration

For complex tasks, follow this multi-phase workflow:

1. PLAN: Break the task into subtasks with success criteria
2. RESEARCH: Search the web and documentation for relevant context
3. IMPLEMENT: Write code following the plan (call external model if needed)
4. REVIEW: Critically review the implementation for flaws
5. REPLAN: Evaluate and decide next steps

---

Aider

Aider 内置了双模型工作流，很适合映射为规划者 + 编码者：

.aider.conf.yml

# Architect model = Planner (proposes the approach)
model: anthropic/claude-opus-4-6

# Editor model = Coder (implements the changes)
editor-model: openai/gpt-5.4

# Weak model = Fast tasks (commit messages, summaries)
weak-model: google/gemini-3-flash

# Enable architect mode
edit-format: architect

可实现的效果： Claude Opus 规划方案，GPT-5.4 执行编辑。这原生支持模式 A（规划 → 编码）。

无法实现的效果： 审查阶段。要进行审查，请单独运行一个 aider 会话：

# Review session with a different model
aider --model xai/grok-4 --no-auto-commits --message "Review the recent changes for security issues and edge cases"

提供商支持： Aider 底层使用 LiteLLM，支持 100 多家提供商。任何 provider/model-id 格式都可使用。

---

网关配置

无网关：直接使用提供商 API

对于原生支持多提供商的工具（OpenCode），或仅使用单个提供商时：

# --- Direct providers ---
export ANTHROPIC_API_KEY="sk-ant-..."    # Claude models
export OPENAI_API_KEY="sk-..."           # GPT models
export GOOGLE_API_KEY="..."              # Gemini models
export XAI_API_KEY="..."                 # Grok models

# --- Cloud providers (alternative or additional) ---
# Amazon Bedrock — Claude, Amazon Nova, Mistral, Llama, etc.
export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."
export AWS_REGION="us-east-1"

# Microsoft Azure OpenAI — GPT, Claude (via AI Foundry)
export AZURE_API_KEY="..."
export AZURE_RESOURCE_NAME="your-resource"
export AZURE_API_VERSION="2024-12-01-preview"

# Google Vertex AI — Gemini, Claude (via Model Garden)
export GOOGLE_CLOUD_PROJECT="your-project"
export GOOGLE_APPLICATION_CREDENTIALS="/path/to/service-account.json"

# --- Other direct providers ---
export MISTRAL_API_KEY="..."
export DEEPSEEK_API_KEY="..."
export GROQ_API_KEY="..."

最适合： OpenCode（原生路由）、Aider（LiteLLM 路由），以及任何可直接访问提供商 API 的工具。

混用提供商很正常。 使用 bedrock/ 调用 Claude（通过 AWS 计费）、使用 azure/ 调用 GPT（通过 Azure 计费），并直接使用 google/ 或 vertex/ 调用 Gemini。每个 Agent 的模型 ID 前缀决定使用哪个提供商——无需网关。

OpenRouter：统一 API

单个 API 密钥、单个端点，提供来自所有提供商的 100 多种模型：

export OPENROUTER_API_KEY="sk-or-..."

端点： https://openrouter.ai/api/v1/chat/completions

模型格式： provider/model-name

• anthropic/claude-opus-4-6
• openai/gpt-5.4
• google/gemini-3.1-pro
• xai/grok-4
• google/gemini-3-pro
• openai/gpt-4o

适用于 CLI 工具的网关脚本：

#!/bin/bash
# gateway-openrouter.sh — call any model via OpenRouter
# Usage: gateway-openrouter.sh <model> <system_prompt> <user_prompt>

MODEL="$1"
SYSTEM="$2"
PROMPT="$3"

if [ -z "$OPENROUTER_API_KEY" ]; then
  echo "Error: OPENROUTER_API_KEY not set" >&2
  exit 1
fi

RESPONSE=$(curl -s https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -H "HTTP-Referer: https://skills.sh/pascalorg" \
  -H "X-OpenRouter-Title: Agent Collaboration" \
  -d "{
    \"model\": \"$MODEL\",
    \"messages\": [
      {\"role\": \"system\", \"content\": $(echo "$SYSTEM" | jq -Rs .)},
      {\"role\": \"user\", \"content\": $(echo "$PROMPT" | jq -Rs .)}
    ],
    \"temperature\": 0.3
  }")

echo "$RESPONSE" | jq -r '.choices[0].message.content'

最适合： Claude Code、Codex CLI、Gemini CLI——以及任何只能使用单个提供商、需要通过脚本访问其他提供商的工具。

Vercel AI Gateway：零加价

40 多个提供商、令牌零加价、托管基础设施：

export AI_GATEWAY_API_KEY="..."    # From Vercel Dashboard

端点： https://ai-gateway.vercel.sh/v1/chat/completions

模型格式： 与 OpenRouter 相同——provider/model-name

提供商排序与回退（使用 Vercel AI SDK 时）：

import { gateway } from '@ai-sdk/gateway';
import { generateText } from 'ai';

const result = await generateText({
  model: gateway('anthropic/claude-opus-4-6'),
  prompt: 'Plan this task...',
  providerOptions: {
    gateway: {
      order: ['anthropic', 'bedrock'],     // Try Anthropic first, fall back to Bedrock
      caching: 'auto',                     // Automatic provider-appropriate caching
    }
  }
});

适用于 CLI 工具的网关脚本（与 OpenRouter 使用相同模式，但端点不同）：

#!/bin/bash
# gateway-vercel.sh — call any model via Vercel AI Gateway
# Usage: gateway-vercel.sh <model> <system_prompt> <user_prompt>

MODEL="$1"
SYSTEM="$2"
PROMPT="$3"

if [ -z "$AI_GATEWAY_API_KEY" ]; then
  echo "Error: AI_GATEWAY_API_KEY not set" >&2
  exit 1
fi

RESPONSE=$(curl -s https://ai-gateway.vercel.sh/v1/chat/completions \
  -H "Authorization: Bearer $AI_GATEWAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{
    \"model\": \"$MODEL\",
    \"messages\": [
      {\"role\": \"system\", \"content\": $(echo "$SYSTEM" | jq -Rs .)},
      {\"role\": \"user\", \"content\": $(echo "$PROMPT" | jq -Rs .)}
    ],
    \"temperature\": 0.3
  }")

echo "$RESPONSE" | jq -r '.choices[0].message.content'

最适合： Vercel 项目、使用 AI SDK 的 TypeScript 代码库，以及希望使用无令牌加价托管网关的团队。

---

升级规则

规划器会在指定检查点重新进入循环。以下规则不可妥协：

规划器必须重新进入的时机

1. 每个执行阶段之后——规划器会评估所有结果，然后再提交审核
2. 每个审核阶段之后——规划器会综合审核反馈并决定后续步骤
3. 任何 Agent 失败时——规划器会决定：使用相同模型重试、改派给备用模型，或简化子任务
4. 审核者意见不一致时——规划器会评估双方观点、审视证据并作出最终决定
5. 出现新信息时——如果任何 Agent 发现了会使计划失效的情况，规划器会重新制定计划
6. 范围变更时——用户需求发生变化，规划器会重新分解任务

规划器应退居一旁的时机

1. 执行期间——Agent 在各自的分配范围内独立执行
2. 审核期间——审核者独立形成意见，不受规划器影响
3. 简单任务——模式 E（快速迭代）会尽量减少规划器的参与

规划器绝不做的事

• 编写代码（这是编码者的工作）
• 开展研究（这是研究者的工作）
• 在没有科学家的情况下提出数学结论
• 批准自己的计划（这是审核者的工作）
• 同时推翻两位审核者的意见（如果两位都表示反对，就说明代码需要修改）

---

反模式

所有任务都使用同一个模型

问题所在： 你会失去对抗性审查带来的优势。相同的模型意味着相同的盲点。让模型审核自己的代码，就像让作者校对自己的手稿——他们会漏掉同样的错误。

解决方法： 至少为对抗性审核者使用不同模型系列的模型。

跳过对抗性审核

问题所在： 同行审核通常以建设性为主——它能找到改进之处，却会漏掉安全问题和逻辑缺陷。对抗性审核者正是为了发现那些因礼貌而被忽略的问题。

解决方法： 始终加入对抗性审核。小任务可使用模式 E（快速迭代），其中仍包含对抗性审核环节。

让编码者审核自己的代码

问题所在： 编码者编写代码时没发现的错误，审核时也不会发现。上下文相同、假设相同、错误也相同。

解决方法： 始终使用不同的模型（最好来自不同系列）进行审核。

过度编排简单任务

为什么不妥： 一行代码的修复不需要 7 个 Agent。对于微不足道的更改，全面编排的开销超过了它带来的收益。

改进方法： 小任务使用模式 E。自行判断——如果修复显而易见且风险低，就直接完成。

忽视成功标准

为什么不妥： 没有标准，Agent 就不知道何时算完成。它们要么交付不足，要么过度打磨。规划者制定的成功标准就是约定。

改进方法： 规划者必须为每个子任务定义成功标准。Agent 在报告完成前，必须根据标准验证自己的工作。

允许规划者编辑文件

为什么不妥： 如果规划者编写代码，就无法客观评估结果。职责分离是此工作流的基础。

改进方法： 规划者绝不编辑文件。它会读取代码并运行只读命令（git log、ls）以了解背景，然后派生子 Agent 执行实际工作。

交接时提供的背景信息不足

为什么不妥： 如果编码者不知道研究者发现了什么，就会重复研究或凭空猜测。如果审查者不了解约束条件，就会把有意为之的取舍当作错误。

改进方法： 遵循交接协议。规划者有责任确保每个 Agent 都获得所需的背景信息。

让 Agent 直接争论

为什么不妥： Agent 没有共享背景信息。没有规划者居中协调的 Agent 间“辩论”，会导致循环争论和 token 浪费。

改进方法： 所有沟通都通过规划者进行。规划者负责综合信息、做出决定并指派任务。

---

模型映射

根据截至 2026 年 4 月的基准测试结果，推荐的模型分配方案。随着新模型发布，这些方案也会调整。

主要分配方案

角色	模型	提供商 ID	基准证据
规划者	Claude Opus 4.6 (thinking)	anthropic/claude-opus-4-6	Arena 排名第 1（1504 Elo），ARC-AGI 2 得分 68.8%
编码者	GPT-5.4 (high)	openai/gpt-5.4	Aider 排行榜排名第 1（88%），SWE-bench 表现强劲
研究者	Gemini 3.1 Pro	google/gemini-3.1-pro	HLE 得分 45.8%，MMMLU 得分 91.8%
科学家	Gemini 3 Pro	google/gemini-3-pro	AIME 2025 得分 100%，GPQA Diamond 得分 94.3%
视觉分析师	Claude Opus 4.6	anthropic/claude-opus-4-6	ARC-AGI 2 得分 68.8%，MMMU 表现强劲
对抗性审查者	Grok 4	xai/grok-4	Arena 排名第 4，持异议的风格，所属模型系列不同
同行审查者	Claude Opus 4.6	anthropic/claude-opus-4-6	分析结构清晰，正面偏见较低

后备分配方案

角色	后备方案 1	后备方案 2
规划者	anthropic/claude-opus-4-5	openai/gpt-5.4
编码者	anthropic/claude-sonnet-4-5	anthropic/claude-sonnet-4-6
研究者	anthropic/claude-opus-4-6	openai/gpt-5.4
科学家	openai/gpt-5.2	anthropic/claude-opus-4-6
视觉分析师	google/gemini-3.1-pro	openai/gpt-5.4
对抗性审查者	google/gemini-3.1-pro	anthropic/claude-opus-4-6
同行审查者	openai/gpt-4o	google/gemini-3.1-pro

注重预算的分配方案

适用于希望优化成本，同时保留多模型优势的团队：

角色	预算型模型	提供商 ID	取舍
规划者	Claude Sonnet 4.6	anthropic/claude-sonnet-4-6	规划的细致程度略低
编码者	GPT-4.1	openai/gpt-4.1	编码能力良好，成本更低
研究者	Gemini 3 Flash	google/gemini-3-flash	研究速度快，深度较浅
科学家	Gemini 3 Flash	google/gemini-3-flash	数学能力良好，形式严谨性较弱
视觉分析师	Gemini 3.1 Pro	google/gemini-3.1-pro	视觉能力强，成本低于 Opus
对抗性审查者	Grok 4	xai/grok-4	保留此项——对抗性审查至关重要
同行审查者	Claude Sonnet 4.6	anthropic/claude-sonnet-4-6	审查能力良好，成本更低

云服务提供商分配

对于通过 Amazon Bedrock、Microsoft Azure 或 Google Vertex AI 路由，而非直接使用提供商 API 的组织：

Amazon Bedrock：

角色	Bedrock 模型 ID	备注
规划器	bedrock/anthropic.claude-opus-4-6-v1	通过 AWS 计费使用 Claude
编码器	bedrock/anthropic.claude-sonnet-4-5-v1	Claude Sonnet 擅长编写代码
研究员	bedrock/amazon.nova-pro-v1	Nova Pro 适用于知识类任务
科学家	bedrock/anthropic.claude-opus-4-6-v1	Opus 擅长数学推理
视觉分析师	bedrock/anthropic.claude-opus-4-6-v1	Opus 擅长多模态任务
对抗性审查员	bedrock/amazon.nova-pro-v1	使用不同模型系列有利于对抗性审查
同行审查员	bedrock/anthropic.claude-opus-4-6-v1	结构化分析

注意：Bedrock 不提供 GPT、Gemini 或 Grok。要覆盖所有模型，可将 Bedrock 与直接使用的提供商搭配：Claude Agent 使用 bedrock/，编码器使用 openai/，研究和科学任务使用 google/，对抗性审查使用 xai/。

Microsoft Azure OpenAI：

角色	Azure 模型 ID	备注
规划器	azure/claude-opus-4-6	通过 Azure AI Foundry 使用 Claude
编码器	azure/gpt-5.4	通过 Azure OpenAI 使用 GPT
研究员	azure/gpt-5.4	GPT 适用于知识类任务
科学家	azure/gpt-5.4	GPT 适用于数学推理
视觉分析师	azure/claude-opus-4-6	通过 Foundry 使用 Claude 多模态能力
对抗性审查员	azure/gpt-4o	使用不同模型有利于对抗性审查
同行审查员	azure/claude-opus-4-6	结构化分析

注意：Azure 模型 ID 取决于你的部署名称；上表假设部署名称与模型名称一致。Azure 原生不提供 Gemini 或 Grok。可将 Azure 与直接使用的提供商搭配：GPT/Claude Agent 使用 azure/，研究和科学任务使用 google/，对抗性审查使用 xai/。

Google Vertex AI：

角色	Vertex AI 模型 ID	备注
规划器	vertex/claude-opus-4-6	通过 Model Garden 使用 Claude
编码器	vertex/gemini-3.1-pro	Gemini 擅长编写代码
研究员	vertex/gemini-3.1-pro	Gemini 的原生优势
科学家	vertex/gemini-3-pro	Gemini 擅长数学
视觉分析师	vertex/gemini-3.1-pro	Gemini 擅长多模态任务
对抗性审查员	vertex/claude-opus-4-6	通过 Model Garden 使用不同模型系列
同行审查员	vertex/gemini-3.1-pro	结构化分析

注意：Vertex AI 原生提供 Gemini，也可通过 Model Garden 使用 Claude。不提供 GPT 或 Grok。要覆盖所有模型，可搭配使用直接提供商。

推荐的企业混合方案——将云服务提供商与一到两个直接 API 搭配，以实现最大的模型多样性：

角色	企业混合方案	原因
规划器	bedrock/anthropic.claude-opus-4-6-v1	通过 AWS 计费使用 Claude
编码器	azure/gpt-5.4	通过 Azure 计费使用 GPT
研究员	vertex/gemini-3.1-pro	通过 GCP 计费使用 Gemini
科学家	vertex/gemini-3-pro	通过 GCP 计费使用 Gemini
视觉分析师	bedrock/anthropic.claude-opus-4-6-v1	通过 AWS 计费使用 Claude
对抗性审查员	xai/grok-4	直接使用——云平台不提供 Grok
同行审查员	bedrock/anthropic.claude-opus-4-6-v1	通过 AWS 计费使用 Claude

此方案通过你现有的云服务协议进行计费，同时保持模型的多样性。由于 xAI 尚未登陆任何云服务市场，只有 Grok 需要直接 API 密钥。

跨提供商模型 ID 参考

同一模型会根据提供商使用不同的 ID 格式。使用此表在 Agent 定义中切换提供商：

模型	直接接入	Bedrock	Azure	Vertex AI	OpenRouter
Claude Opus 4.6	anthropic/claude-opus-4-6	bedrock/anthropic.claude-opus-4-6-v1	azure/claude-opus-4-6	vertex/claude-opus-4-6	anthropic/claude-opus-4-6
Claude Sonnet 4.5	anthropic/claude-sonnet-4-5	bedrock/anthropic.claude-sonnet-4-5-v1	azure/claude-sonnet-4-5	vertex/claude-sonnet-4-5	anthropic/claude-sonnet-4-5
Claude Sonnet 4.6	anthropic/claude-sonnet-4-6	bedrock/anthropic.claude-sonnet-4-6-v1	azure/claude-sonnet-4-6	vertex/claude-sonnet-4-6	anthropic/claude-sonnet-4-6
GPT-5.4	openai/gpt-5.4	—	azure/gpt-5.4	—	openai/gpt-5.4
GPT-5.2	openai/gpt-5.2	—	azure/gpt-5.2	—	openai/gpt-5.2
GPT-4o	openai/gpt-4o	—	azure/gpt-4o	—	openai/gpt-4o
Gemini 3.1 Pro	google/gemini-3.1-pro	—	—	vertex/gemini-3.1-pro	google/gemini-3.1-pro
Gemini 3 Pro	google/gemini-3-pro	—	—	vertex/gemini-3-pro	google/gemini-3-pro
Gemini 3 Flash	google/gemini-3-flash	—	—	vertex/gemini-3-flash	google/gemini-3-flash
Grok 4	xai/grok-4	—	—	—	xai/grok-4
Amazon Nova Pro	—	bedrock/amazon.nova-pro-v1	—	—	—

“—”表示该提供商不提供此模型。可按需混用提供商。

单一提供商的备选方案

如果只能使用一个提供商：

仅 Anthropic（Claude Code 默认）：

角色	模型	备注
规划器	Opus（思考）	能力全面
编码器	Sonnet	速度快，擅长编程
研究员	Opus	综合能力强
科学家	Opus	数学能力尚可
视觉分析师	Opus	多模态能力强
对抗性审查员	Sonnet	模型不同，但属于同一系列——应增加对抗性提示
同行审查员	Opus	结构化分析

仅 OpenAI（Codex 默认）：

角色	模型	备注
规划器	GPT-5.4（high）	规划能力强
编码器	GPT-5.4	原生优势
研究员	GPT-5.4	研究能力良好
科学家	GPT-5.2	数学能力强
视觉分析师	GPT-5.4	多模态能力良好
对抗性审查员	GPT-4o	模型不同，风格也不同
同行审查员	GPT-5.4（high）	结构化分析

仅 Google（Gemini CLI 默认）：

角色	模型	备注
规划器	Gemini 3.1 Pro	规划能力强
编码器	Gemini 3.1 Pro	编程能力良好
研究员	Gemini 3.1 Pro	原生优势
科学家	Gemini 3 Pro	原生优势
视觉分析师	Gemini 3.1 Pro	多模态能力强
对抗性审查员	Gemini 3 Flash	使用不同模型，兼顾成本与视角
同行审查员	Gemini 3.1 Pro	结构化分析

---

持续更新模型映射

模型能力会随着每次发布而变化。以上分配基于截至 2026 年 4 月的基准测试。

主要基准测试来源

关注以下来源以保持信息更新：

来源	URL	跟踪内容	更新频率
Chatbot Arena	arena.ai	总体质量、各类别排名	持续
SWE-bench	swebench.com	真实世界的软件工程能力	提交时
Aider Leaderboard	aider.chat/docs/leaderboards/	实用代码编辑能力	发布时
Artificial Analysis	artificialanalysis.ai	智能/速度/成本指数	每周
LiveBench	livebench.ai	抗污染的月度评估	每月
GPQA Diamond	—	博士级科学知识	静态
ARC-AGI 2	arcprize.org	抽象视觉推理	定期
Humanity's Last Exam	—	前沿知识	定期

重新评估的时机

• 有重要新模型发布（新版本的 Claude、GPT、Gemini、Grok）
• 相关类别的 Arena 排名变动超过 50 Elo
• SWE-bench 或 Aider 排行榜出现新的第 1 名
• 你发现某个 Agent 的质量持续下降

未来：基准测试追踪技能

目前计划开发一项用于自动追踪基准测试的配套技能。它将从可编程数据源（HuggingFace 数据集、Arena Hard Auto）获取最新排名，并生成更新后的模型映射。在此之前，重大模型发布时请查看上述来源。

角色与基准测试映射

通过下表了解不同 Agent 角色应关注哪些基准测试：

Agent 角色	主要基准测试	关注点
规划者	Arena（总体、困难提示词）、ARC-AGI 2	抽象推理、复杂指令遵循
编码者	Aider、SWE-bench Verified	实用代码编辑、真实世界的 Bug 修复
研究员	Arena（知识）、HLE、MMMLU、BrowseComp	知识广度、研究综合能力
科学家	AIME、GPQA Diamond、MATH Level 5	数学推理、科学知识
视觉分析员	ARC-AGI 2、MMMU-Pro	视觉推理、多模态理解
对抗性评审员	Arena（困难提示词）、PropensityBench	批判性思维、较低的正面偏见
同行评审员	Arena（总体）、AI Scientist 评审分数	结构化分析、诚实评估

---

快速参考

工作流选择

任务规模	模式	使用的 Agent
极简单（单行）	跳过编排	直接执行
小型（单文件）	E（快速）	规划者 → 编码者 → 对抗性评审员
中型（多文件）	A（默认）	规划者 → 编码者 → 两位评审员
中型 + API 未知	B（先研究）	规划者 → 研究员 → 规划者 → 编码者 → 评审
大型	D（完整流程）	所有 Agent，多个阶段
仅研究	F（研究）	规划者 → 研究员 + 科学家
数学/科学密集型	C（深入分析）	规划者 → 科学家 + 视觉分析员 + 研究员 → 编码者 → 评审

工具选择

你的工具	多模型	子 Agent	最佳方案
OpenCode	原生（75+ 提供商）	是	完整多模型，无需网关
Claude Code	仅限 Anthropic	是	使用网关脚本实现跨提供商，或仅使用 Anthropic
Cursor	UI 模型选择器	否	按阶段依次切换模型
Codex CLI	仅限 OpenAI	正在发展	使用网关脚本实现跨提供商
Gemini CLI	仅限 Google	否	依次使用模型 + 网关脚本
Aider	任意（通过 LiteLLM）	否	架构师/编辑器双模型 + 评审会话

网关选择

场景	推荐网关
OpenCode 用户	无需网关 — 原生支持多提供商
所有服务使用一个 API 密钥	OpenRouter
Vercel 项目 / TypeScript	Vercel AI Gateway
可自托管 / 完全控制	LiteLLM proxy
预算追踪很重要	Vercel AI Gateway 或 OpenRouter（两者都提供仪表板）
企业合规	Portkey（SOC 2、HIPAA）

---

成本预期

多模型编排会使用前沿模型，并非免费。每项任务的大致成本如下（因复杂程度和 Token 数量而异）：

模式	使用的模型	预估成本范围
E（快速）	3 次调用（规划器 + 编码器 + 对抗式审查器）	$0.50 – $2
A（默认）	4-5 次调用（规划器 + 编码器 + 2 位审查器 + 重新规划）	$2 – $8
B（先研究）	6-7 次调用（+ 研究员 + 重新规划）	$3 – $10
D（完整流程）	8-12 次调用（所有 Agent，多个阶段）	$5 – $20

以上估算基于前沿模型（Opus、GPT-5.4、Gemini 3.1 Pro）。注重预算的任务分配（参见 Model Map）可将成本降低 50-70%，但会适度牺牲质量。

值得付出额外成本的情况： 复杂任务中，缺陷或遗漏需求会导致数小时的返工。一次 $10 的多 Agent 审查若能发现安全漏洞，节省的成本远不止 $10。

不值得付出额外成本的情况： 微不足道的更改。如果你能在 5 分钟内编写并验证修复，就跳过编排。

---

故障排除

未找到 Agent

症状： 调用 @planner 或 Agent 时，返回“agent not found”或类似错误。

修复方法： 确保 Agent 定义文件位于正确的目录中：

• OpenCode：.opencode/agents/planner.md（项目级）或 ~/.config/opencode/agents/planner.md（全局）
• Claude Code：.claude/agents/planner.md（项目级）或 ~/.claude/agents/planner.md（全局）

确认文件已正确复制：ls .opencode/agents/ 或 ls .claude/agents/

模型不可用 / API 错误

症状： Agent 运行时出现“Model not found”、“Invalid model”或 404 错误。

修复方法：

• 确认模型 ID 与你的提供商相符。不同提供商的模型 ID 各不相同，请查看 Cross-Provider Model ID Reference 表格
• 确认已设置 API 密钥：echo $ANTHROPIC_API_KEY | head -c 10（应显示前 10 个字符）
• 对于 Bedrock：确保你的 IAM 角色对指定模型拥有 bedrock:InvokeModel 权限
• 对于 Azure：确保模型 ID 中的部署名称与 Azure 部署名称一致

Agent 输出内容混乱

症状： Agent 忽略自身角色，在本应只进行审查时编写代码，或生成无结构的输出。

修复方法：

• 确保 Agent 定义文件包含完整的系统提示词（Markdown 正文）。如果文件只有 frontmatter，Agent 就没有指令
• 对于只读 Agent，确认已设置 permission: edit: deny（OpenCode）或受限的 allowed-tools（Claude Code）
• 如果使用网关脚本，请检查是否传入了完整提示词——Shell 参数截断是常见问题。对于较长的上下文，请使用标准输入或基于文件的提示词

上下文窗口溢出

症状： Agent 在大型代码库上运行时出错或输出被截断。

修复方法：

• 规划器应在交接内容中总结上下文，而不是粘贴整个文件。请提供文件路径和相关行范围，而非完整内容
• 研究交接内容应将发现总结在 500 词以内——编码器不需要完整的研究输出
• 审查交接内容只需包含已更改的文件，无需包含整个代码库
• 如果单个文件过大，让规划器将任务拆分为范围更小、针对特定文件的子任务

网关脚本静默失败

症状： 网关脚本返回空输出或 null。

修复方法：

• 检查 API 密钥：echo $OPENROUTER_API_KEY | head -c 10
• 直接测试端点：curl -s https://openrouter.ai/api/v1/models | jq '.data[0].id'
• 检查是否已安装 jq：which jq——若未安装，请安装（brew install jq 或 apt install jq）
• 使用详细模式运行脚本：临时将 curl -s 替换为 curl -v，以查看 HTTP 错误

审查者总是批准（走过场）

症状： 对抗性审查者批准所有内容，导致审查失去意义。

修复方法：

• 检查对抗性审查者使用的模型系列是否与编码者不同。同一系列的审查往往倾向于批准
• 强化对抗性提示词：添加“你必须至少找出 3 个问题。如果你在没有发现任何问题的情况下批准，就说明你没有做好本职工作”
• 如果只使用单一提供商（仅限 Anthropic），请使用 Sonnet 进行对抗性审查，并采用非常强硬的提示词——这可以部分弥补同一系列带来的偏差