🌐 한국어 | English | 日本語 | 中文

Polymeld

将多个 AI 编码代理编排为虚拟开发团队。

将 Claude Code、Gemini CLI、Codex CLI 分配给各个角色，自动化完成会议 → 设计 → 开发 → 代码评审 → QA → PR 创建的全流程。

✨ 核心特性

• 🤖 多 AI 团队 — 8 个角色（技术负责人、程序员、QA、设计师等）分别由 Claude、Gemini、Codex 驱动
• 🔄 8 阶段流水线 — 代码库分析 → 会议 → 任务分解 → 分配 → 开发 → 代码评审 → QA → PR
• 🛠️ CLI + API 双后端 — 每个模型通过 CLI 或 API SDK 运行 — 有哪个用哪个，或两者兼用
• ⚡ 并行开发 — 分析依赖关系，独立任务同时执行
• 🖼️ 图像生成 — 双引擎：Nano Banana 2（Gemini）+ GPT Image 1.5（OpenAI）— 透明背景素材自动路由到 GPT
• 📂 本地工作区 — 读取现有代码、直接创建文件、自动管理 git 分支/提交
• 🔁 自动修复循环 — 评审/QA 失败时自动修复 → 重新验证
• 💬 AI 会议 — 实时多模型讨论，通过 [PASS]/[CONCLUDE] 自主调节
• 📊 Token 用量追踪 — 每个操作后显示后端（CLI/API）、模型名称和 Token 数量
• 🔀 3 级 Rate Limit 回退 — CLI → API key → 备用模型 — rate limit 时自动切换
• 🌐 4 语言 i18n — 完整支持 English、한국어、日本語、中文
• 📌 GitHub 完整可追溯 — 全过程记录为 Issues、Comments、Commits 和 PR

🚀 快速开始

# 1. 安装 Polymeld
npm install -g polymeld

# 2. 安装 AI CLI（只需安装你要使用的）
npm install -g @anthropic-ai/claude-code   # Claude Code
npm install -g @google/gemini-cli           # Gemini CLI
npm install -g @openai/codex                # Codex CLI

# 3. 在项目文件夹中运行 — 引导向导自动启动
cd ~/projects/my-app
polymeld
# → 选择模型 → 设置 GitHub Token → 完成！
# → GITHUB_REPO 从 git remote 自动检测

📋 命令

| 命令 | 说明 | |------|------| | polymeld | 启动 REPL（首次运行时引导向导） | | polymeld run "需求" | 运行完整流水线 | | polymeld run "需求" --mode semi-auto | 每个 Phase 确认 | | polymeld meeting "主题" | 仅运行会议 | | polymeld start --resume | 恢复上一个会话 | | polymeld test-models | 测试模型连接 | | polymeld init --global | 初始化全局配置 | | polymeld auth | 交互式管理凭证 |

REPL 斜杠命令： /help /status /history /context /team /mode /resume /save /load /exit

⚙️ 流水线

Phase 0  代码库分析          分析现有代码结构（本地工作区时）
Phase 1  会议                多 AI 讨论 → 设计决策
Phase 2  任务分解            分解为 1-4 小时单元 → GitHub Issues
Phase 3  任务分配            将任务匹配到合适的角色
Phase 4  开发                并行编码 → feature 分支 → 提交
Phase 5  代码评审            组长评审 → 自动修复 → 重新评审 (×3)
Phase 6  QA                  验证 → 自动修复 → 重新验证 (×3)
Phase 7  PR 创建             自动创建包含所有记录链接的 PR

检查点：每个 Phase 完成时保存。使用 /resume 从任意 Phase 恢复。

📌 GitHub Issue & 看板

Polymeld 使用 GitHub Issues 和 GitHub Projects V2 看板自动追踪整个流水线过程。

自动创建 Issue

| Phase | 创建的 Issue | 标签 | |-------|-------------|------| | Phase 1 | 📝 Planning Issue — 会议结果记录 | meeting-notes, planning, polymeld | | Phase 2 | 🔧 Task Issue — 每个分解任务各一个 | backlog, polymeld, {{category}} |

看板 6 列

随着流水线推进，Issue 自动在看板列之间移动：

Backlog → Todo → In Progress → In Review → QA → Done

| 列 | 转换时机 | 标签变更 | |----|---------|---------| | Backlog | Phase 2：任务分解后 | backlog | | Todo | Phase 3：分配给角色 | todo, assigned:{{agent}} | | In Progress | Phase 4：开发开始 | in-progress | | In Review | Phase 5：代码评审中 | in-review | | QA | Phase 6：QA 进行中 | qa | | Done | Phase 6：QA 通过 → Issue 自动关闭 | done |

自动评论

每次 Phase 转换时，Issue 自动添加评论以完整追踪历史：

• 🧑‍💼 任务分配 — 负责人、分配原因
• 🚀 开发开始/完成 — 代理名称、模型、代码预览
• 🔍 代码评审 — 评审结果（含尝试次数）
• 🧪 QA 结果 — 验证结果、基于反馈的修复历史

PR 与 Issue 关联

Phase 7 创建的 PR 通过 Closes #N 引用所有已完成的 Task Issue，合并 PR 时相关 Issue 自动关闭。

没有 GitHub Token 也可以运行流水线，仅 GitHub 功能会被禁用。

👥 默认团队

| 角色 | 职责 | 模型 | 图像 | |------|------|------|------| | 林架构 | Tech Lead（组长） | Claude Opus 4.6 | — | | 韩码杰 | Ace Programmer | GPT-5.4 | — | | 刘创新 | Creative Programmer | Gemini 3.1 Pro | — | | 姜策远 | Ace Planner | Gemini 3.1 Pro | — | | 安盾强 | Security Expert | Claude Opus 4.6 | — | | 尹悦然 | UX/Visual Designer | Gemini 3.1 Pro | Nano Banana 2 / GPT Image 1.5 | | 画灵秀 | Illustrator | Gemini 3.1 Pro | Nano Banana 2 / GPT Image 1.5 | | 郑测安 | QA Engineer | GPT-5.4 | — |

所有角色参与会议。通过 [PASS]（跳过）和 [CONCLUDE]（提前结束）自主调节。

🔧 配置

后端优先级

每个模型支持自动切换的双后端：

| 优先级 | 后端 | 使用条件 | |--------|------|----------| | 第 1 | CLI（claude / gemini / codex） | 已安装且可用时 | | 第 2 | API SDK（Anthropic / Google GenAI / OpenAI） | CLI rate limit 或未安装 CLI 时 | | 第 3 | Fallback 模型 | CLI 和 API 均 rate limit 时 |

仅 CLI、仅 API、或两者兼有 — 有什么用什么。设置 api_model 可为 API 调用指定不同的模型。

凭证

polymeld auth                  # 交互式设置
polymeld auth --show           # 查看当前状态

或使用 .env / ~/.polymeld/credentials.yaml：

GITHUB_TOKEN=ghp_xxxxx        # 必需
# GITHUB_REPO=owner/repo      # 从 git remote 自动检测

# API 密钥（可选 — 按提供商启用 API 后端）
ANTHROPIC_API_KEY=sk-...       # Claude API
GOOGLE_API_KEY=AIzaSy...       # Gemini API（Nano Banana 2 图像生成）
OPENAI_API_KEY=sk-...          # OpenAI API（GPT Image 1.5 透明PNG生成）

config.yaml

配置文件按层级合并：-c 标志 > ~/.polymeld/config.yaml（全局）> .polymeld/config.yaml（项目）> .polymeld/config.local.yaml（本地）。

# 模型定义
models:
  claude:
    cli: claude
    model: claude-opus-4-6
    fallback: gemini             # rate limit 时切换
  gemini:
    cli: gemini
    model: gemini-3.1-pro-preview
    fallback: claude
  codex:
    cli: codex
    model: gpt-5.4
    fallback: claude
  gemini_image:
    cli: gemini
    model: gemini-3.1-flash-image-preview  # Nano Banana 2（需要 GOOGLE_API_KEY）
  gpt_image:
    cli: codex
    model: gpt-image-1.5                   # 透明PNG（需要 OPENAI_API_KEY）

# 角色分配
personas:
  tech_lead:
    name: 林架构
    model: claude
    thinking_budget: 50          # AI 思考深度（0-100）
  designer:
    name: 尹悦然
    model: gemini
    image_model: gemini_image    # 启用图像生成

# 流水线设置
pipeline:
  parallel_development: true     # 并行 LLM 调用
  thinking_budget: 25            # 全局默认值（0-100）
  max_review_retries: 3
  max_qa_retries: 3

自定义角色

personas:
  devops:
    name: 云运维
    role: DevOps Engineer
    model: codex
    description: "CI/CD 和基础设施自动化专家"
    expertise:
      - CI/CD 流水线构建
      - 容器编排

🌐 多语言支持

| 语言 | 标志 | 自动检测 | |------|------|----------| | English | --lang en | OS 区域设置 | | 한국어 | --lang ko | OS 区域设置 | | 日本語 | --lang ja | OS 区域设置 | | 中文(简体) | --lang zh-CN | OS 区域设置 |

AI 响应解析也支持多语言 — APPROVED/승인/承認/批准 等判定可跨语言识别。

Claude Code 集成

polymeld run "需求" --no-interactive

注册到 CLAUDE.md 即可实现自动调用。

🧠 智能体通信架构

智能体之间不会直接对话。所有通信都通过 PipelineState（共享状态）和 PromptAssembler（上下文中介）进行。

架构

┌─────────────────────────────────────────────────────────┐
│                     PipelineState                       │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌───────────┐  │
│  │ messages  │ │  tasks   │ │  design  │ │ codebase  │  │
│  │   []      │ │   []     │ │ Decisions│ │ Analysis  │  │
│  └──────────┘ └──────────┘ └──────────┘ └───────────┘  │
└────────────────────┬────────────────────────────────────┘
                     │ read
              ┌──────┴──────┐
              │   Prompt    │  在 token 预算内
              │  Assembler  │  筛选相关上下文
              └──────┬──────┘
          ┌──────────┼──────────┐
          ▼          ▼          ▼
     ┌─────────┐ ┌─────────┐ ┌─────────┐
     │技术主管  │ │ 开发者  │ │   QA    │
     │ (Claude)│ │(Gemini) │ │(Codex)  │
     └────┬────┘ └────┬────┘ └────┬────┘
          │ write      │ write     │ write
          └────────────┴───────────┘
                       │
              写回 PipelineState

通信模式

| 模式 | 流向 | 说明 | |------|------|------| | 会议发言 | 智能体 → messages[] → 下一个智能体 | 轮询讨论，每个智能体看到之前的发言后再回应 | | 设计 → 代码 | designDecisions → 开发者 | 会议成果成为编码上下文 | | 代码 → 评审 | task.code → 技术主管 | 编写的代码传递给评审者 | | 评审 → 修复 | task.review → 开发者 | 评审反馈触发修复周期 | | QA → 修复 | task.qa → 技术主管 | QA 失败时主管直接修复 |

消息流示例

Phase 1 — 会议
  Archie 发言 → 消息保存 → Nova 读取 → 发言 → ...
  最终产出: designDecisions, techStack

Phase 4 — 开发
  PromptAssembler.forCoding()
    → designDecisions (30%)
    → codebaseAnalysis (50%)      ← token 预算分配
    → techStack (剩余)
  开发者编写代码 → task.code + task.filePaths

Phase 5–6 — 评审 & QA 修复周期
  Lead.reviewCode(task.code)
    → 判定: "approved" | "changes_requested"
    → changes_requested → Lead.writeCode(评审 + 代码)
  QA.runQA(task.filePaths)
    → 判定: "pass" | "fail"
    → fail → Lead.writeCode(QA结果 + 代码) → 重新QA（最多×3）

每个智能体只能看到 PromptAssembler 提供的上下文，无法直接访问完整状态。这确保了提示词的针对性，并保持在模型上下文限制之内。

许可证

MIT