用多個 AI Agent 協作寫程式：從手動 Workflow 到自動 Orchestration

版本：2026年 9月 15日

如果你平時只係用一個 AI 幫你寫程式，通常流程會係：

我提出需求
   ↓
AI 分析
   ↓
AI 寫 Code
   ↓
我測試
   ↓
再叫 AI 修改

呢種方法已經可以提升開發速度，但仍然有一個問題：

同一個 AI 既設計、又寫程式、又 review 自己嘅 code，很容易有共同盲點。

一個更成熟嘅方法係建立一個 Multi-Agent Software Development Workflow。

你可以想像自己係一間小型 software company 嘅 Tech Lead，而幾個 AI 分別負責：

Product / Requirements
Software Architecture
Critical Review
Implementation
Testing
Verification

呢篇文章會由最簡單嘅手動方法開始，逐步講到點樣建立可以自動運作嘅 AI Agent workflow。

Multi-Agent Workflow 是什麼？
AI Model、AI Agent、AI Tool 有什麼分別？
為什麼不應該只用一個 AI？
最簡單的三個 Agent 架構
我應該用三個不同 AI，還是同一個 AI 開三個 Agent？
推薦的角色分工
第一階段：先不要寫 Code
建立 Shared Artifacts
Architect Agent
Reviewer / Critic Agent
Implementation Feasibility Agent
Feedback Loop 應該如何停止？
Spec Freeze
Implementation Agent
Code Review Agent
QA / Verification Agent
完整 Workflow
方案一：完全手動
方案二：只用 Cursor Subagents
方案三：跨平台 Hybrid Workflow
方案四：自己建立 Orchestrator
Orchestrator 的基本邏輯
如何避免 AI 無限討論？
如何控制 Token 和成本？
Git 在 Multi-Agent Workflow 中的角色
MCP 和 Multi-Agent Orchestration 的分別
推薦的起步方案
實戰 Checklist
下一步：逐步自動化

1. Multi-Agent Workflow 是什麼？

Multi-Agent Workflow 的意思係：

將一件複雜工作拆開，交俾多個有不同責任嘅 AI Agent，再由一個人或者一個 Orchestrator 管理佢哋之間嘅交接。

例如：

Requirement
    ↓
Architect
    ↓
Reviewer
    ↓
Architect Revision
    ↓
Implementation
    ↓
Code Review
    ↓
Testing
    ↓
Verification

你自己唔再只係「叫 AI 寫 Code」。

你開始扮演：

Product Owner
+
Tech Lead
+
AI Team Manager

2. AI Model、AI Agent、AI Tool 有什麼分別？

呢三個概念經常被混埋一齊。

AI Model

例如：

GPT
Claude
Gemini

Model 本身主要負責理解同生成內容。

AI Agent

Agent 通常係：

Model
+
Instructions
+
Tools
+
Context
+
Memory / State
+
Goal

例如：

Claude
+
"你係 Senior Code Reviewer"
+
Git / Filesystem
+
Project Context

就可以形成一個 Reviewer Agent。

AI Tool / Environment

例如：

ChatGPT
Cursor
Claude Code
Codex
OpenCode

呢啲係你同 AI 工作嘅平台或者開發環境。

所以：

Cursor 並唔等於一個特定 Model。

Cursor 可以使用不同模型，但 Cursor 本身負責提供：

Repository context
File editing
Terminal
Git
Agent workflow
Tool access

3. 為什麼不應該只用一個 AI？

假設同一個 AI：

設計 Architecture
↓
寫 Code
↓
Review 自己
↓
再話自己冇問題

最大問題係：

Correlated Errors

如果原本第一步已經有錯誤假設：

錯誤 Architecture
       ↓
錯誤 Implementation
       ↓
同一個 AI Review
       ↓
仍然認為正確

因此，多 Agent 最大價值唔係「多幾個 AI 一齊做嘢」。

真正價值係：

Separation of Responsibilities

即係：

一個提出方案
一個專門挑錯
一個真正落手實作
一個負責驗證

4. 最簡單的三個 Agent 架構

最簡單可以由三個角色開始：

Agent	角色	主要工作
Agent A	Architect	理解 requirement、設計 solution
Agent B	Reviewer / Critic	找問題、挑戰假設
Agent C	Implementer	實際修改 repository、寫 tests

你自己係：

Human Tech Lead

架構：

             YOU
              │
              ▼
         Requirement
              │
              ▼
        ┌───────────┐
        │ Architect │
        └─────┬─────┘
              │
              ▼
         Architecture
              │
              ▼
        ┌───────────┐
        │ Reviewer  │
        └─────┬─────┘
              │
              ▼
           Review
              │
              ▼
        ┌───────────┐
        │ Architect │
        │  Revision │
        └─────┬─────┘
              │
              ▼
          APPROVED
              │
              ▼
       ┌─────────────┐
       │ Implementer │
       └─────────────┘

5. 我應該用三個不同 AI，還是同一個 AI 開三個 Agent？

兩種都可以。

方法 A：同一個平台開三個 Agent

例如：

Cursor
 ├── Architect
 ├── Reviewer
 └── Tester

優點：

Repository context 容易共享
操作簡單
不需要自己寫 API integration
Agent handoff 容易管理

缺點：

如果三個 Agent 使用同一 Model，可能有相似盲點

方法 B：三個不同 AI

例如：

ChatGPT → Architect
Claude   → Reviewer
Cursor   → Implementer

優點：

Reasoning style 不同
較容易發現彼此盲點
Reviewer 比較獨立

缺點：

Context handoff 麻煩
容易不停 Copy / Paste
自動化難度較高

方法 C：Hybrid

6. 推薦的角色分工

一開始唔需要十個 Agent。

推薦由以下四個角色開始：

1. Architect

負責：

理解需求
找現有 architecture
找可重用 module
設計 data flow
拆 implementation steps
找主要風險

2. Reviewer / Critic

負責：

挑戰 Architect 假設
找 bug risk
找 over-engineering
找 duplicated logic
找 security issues
找 missing tests

3. Implementer

負責：

修改 repository
寫 tests
執行 tests
修正 compilation errors
按 approved spec 實作

4. Verifier / QA

負責：

嘗試打破功能
Edge cases
Regression
Test coverage
驗證 acceptance criteria

7. 第一階段：先不要寫 Code

Multi-Agent workflow 最容易失敗嘅地方就係：

Requirement
↓
AI 即刻開始寫 Code

比較好嘅方法係：

Requirement
↓
Understanding
↓
Architecture
↓
Review
↓
Revision
↓
Approval
↓
Implementation

即係：

Design first, code second.

8. 建立 Shared Artifacts

Agent 之間最好唔好靠巨大 chat history 傳遞資訊。

建立一個 project folder：

.ai/
├── REQUIREMENTS.md
├── ARCHITECTURE.md
├── REVIEW.md
├── IMPLEMENTATION_PLAN.md
├── TEST_PLAN.md
├── TEST_RESULTS.md
├── CODE_REVIEW.md
└── DECISIONS.md

例如：

REQUIREMENTS.md

# Feature

Add VCP scanner.

## Requirements

- Detect price contractions
- Detect volume dry-up
- Avoid look-ahead bias
- Support historical backtesting
- Reuse existing market data service

所有 Agent 都以呢啲檔案作共同資訊來源。

9. Architect Agent

Architect 嘅 prompt 可以係：

You are the software architect for this project.

Read:
- REQUIREMENTS.md
- existing repository
- existing architecture

Do not write production code.

Produce:

1. Understanding of the requirement
2. Existing components that can be reused
3. Proposed architecture
4. Data flow
5. Files/modules affected
6. Risks
7. Testing strategy
8. Implementation plan

Avoid unnecessary abstractions.

Write the result to ARCHITECTURE.md.

重點：

Do not write production code.

避免佢未設計清楚就開始實作。

10. Reviewer / Critic Agent

Reviewer 唔係第二個 Architect。

佢嘅主要責任係：

找問題，而唔係重新發明整個 system。

Prompt：

You are a skeptical senior software engineer.

Review:
- REQUIREMENTS.md
- ARCHITECTURE.md
- existing repository

Do not redesign the entire system unless necessary.

Find:

- incorrect assumptions
- missing requirements
- duplicate logic
- unnecessary abstractions
- performance risks
- concurrency risks
- security problems
- data leakage
- look-ahead bias
- missing tests
- regression risks

Classify findings:

P0 = blocking / unsafe
P1 = serious issue
P2 = improvement
P3 = optional

Write findings to REVIEW.md.

11. Implementation Feasibility Agent

第三個 Agent 可以先唔寫 Code。

先叫佢確認：

呢個設計喺實際 repository 入面係咪真係做得到？

Prompt：

You are the engineer who will implement this feature.

Read:
- REQUIREMENTS.md
- ARCHITECTURE.md
- REVIEW.md
- the actual repository

Do not write code yet.

Determine:

1. Whether the architecture is implementable
2. Which existing functions/modules can be reused
3. Which assumptions are wrong
4. Exact files likely to change
5. Tests required
6. Compatibility risks
7. Estimated complexity

Write the findings to IMPLEMENTATION_PLAN.md.

呢一步可以減少 AI hallucination。

例如 Architect 可能話：

Reuse EdgeCalculatorService

但 repository 根本冇呢個 class。

Implementer 就可以即刻指出。

12. Feedback Loop 應該如何停止？

唔好用：

Keep reviewing until perfect.

因為「perfect」冇清晰定義。

應該設定：

P0 = 0
P1 = 0

就可以進入 implementation。

例如：

Round 1
Architect
↓
Reviewer
↓
2 × P1

Round 2
Architect revision
↓
Reviewer
↓
0 × P0
0 × P1

APPROVED

同時設定：

MAX_REVIEW_ROUNDS = 3

避免無限 loop。

13. Spec Freeze

當 architecture 被批准：

P0 = 0
P1 = 0

就進行：

SPEC FREEZE

意思係：

Implementation Agent 唔可以因為「覺得另一個設計更靚」而自己重新設計 system。

只有以下情況可以 reopen architecture：

發現 blocker
Requirement 本身矛盾
Existing repository 不支援原方案
Security / correctness issue

呢個規則可以避免：

Architect A
↓
Reviewer B
↓
Implementer 又自行創造 Architecture C

14. Implementation Agent

Implementation prompt：

You are the implementation engineer.

Read:

- REQUIREMENTS.md
- ARCHITECTURE.md
- IMPLEMENTATION_PLAN.md

The specification is frozen.

Implement Task 1 only.

Rules:

- Follow the approved architecture
- Reuse existing project patterns
- Avoid unrelated refactoring
- Add tests
- Run relevant tests
- Do not implement future tasks

Report:

- files changed
- tests added
- tests executed
- failures
- unresolved issues

最好：

Task 1
↓
Review
↓
Task 2
↓
Review

而唔係一次過叫 AI 改 50 個 files。

15. Code Review Agent

完成 implementation 後：

git diff

交俾 Reviewer。

Prompt：

You are a senior code reviewer.

Review:

- REQUIREMENTS.md
- ARCHITECTURE.md
- git diff
- test results

Check:

- correctness
- regression risk
- readability
- unnecessary complexity
- duplicate logic
- performance
- security
- missing tests

Do not modify the code.

Return only actionable findings.

Classify:
P0
P1
P2
P3

16. QA / Verification Agent

QA Agent 嘅目的係：

Try to break the feature.

Prompt：

You are the QA and verification engineer.

Try to break this feature.

Do not modify production code.

Check:

- boundary conditions
- invalid input
- missing data
- duplicate data
- race conditions
- timezone issues
- numerical precision
- large datasets
- regression behaviour

Verify every acceptance criterion.

Return PASS or FAIL for each criterion.

17. 完整 Workflow

完整流程：

                     YOU
                      │
                      ▼
                REQUIREMENT
                      │
                      ▼
              ┌─────────────┐
              │  Architect  │
              └──────┬──────┘
                     │
                     ▼
              ARCHITECTURE.md
                     │
                     ▼
              ┌─────────────┐
              │   Critic    │
              └──────┬──────┘
                     │
                     ▼
                  REVIEW
                     │
               P0/P1 exists?
                 │       │
                YES      NO
                 │       │
                 ▼       ▼
            Architect   SPEC
             Revision   FREEZE
                           │
                           ▼
                   ┌─────────────┐
                   │ Implementer │
                   └──────┬──────┘
                          │
                          ▼
                     CODE + TEST
                          │
                          ▼
                   ┌────────────┐
                   │Code Review │
                   └─────┬──────┘
                         │
                    Issue?
                    │    │
                   YES   NO
                    │    │
                    ▼    ▼
                  FIX   QA
                         │
                         ▼
                    VERIFICATION
                         │
                         ▼
                        DONE

18. 方案一：完全手動

最簡單完全唔需要 coding。

例如：

ChatGPT

角色：

Architect

Claude

角色：

Reviewer

Cursor

角色：

Implementer

手動流程：

ChatGPT output
↓
save ARCHITECTURE.md

Claude reads ARCHITECTURE.md
↓
save REVIEW.md

ChatGPT reads REVIEW.md
↓
update ARCHITECTURE.md

Cursor reads approved files
↓
implement

優點：

最容易理解
完全透明
容易 debug workflow

缺點：

Copy / Paste 比較多

19. 方案二：只用 Cursor Subagents

如果你主要用 Cursor，可以建立：

.cursor/
└── agents/
    ├── architect.md
    ├── critic.md
    └── verifier.md

概念：

YOU
 │
 ▼
Main Cursor Agent
 │
 ├── Architect
 ├── Critic
 └── Verifier

Main Agent 做 Orchestrator。

例如你可以畀 Main Agent：

For this feature:

1. Ask architect to create the design.
2. Ask critic to review the design.
3. Return P0/P1 findings to architect.
4. Maximum 3 review rounds.
5. Freeze the specification when P0 = 0 and P1 = 0.
6. Implement the feature.
7. Ask verifier to check acceptance criteria.
8. Fix blocking findings.
9. Run all relevant tests.
10. Stop when verification passes.

呢個係最適合第一次實踐 Multi-Agent Workflow 嘅方法之一。

20. 方案三：跨平台 Hybrid Workflow

例如：

ChatGPT
   ↓
Architect

Claude
   ↓
Reviewer

Cursor
   ↓
Implementer

完整架構：

                 YOU
                  │
                  ▼
            Requirement
                  │
                  ▼
        ┌─────────────────┐
        │ ChatGPT / GPT   │
        │   Architect     │
        └────────┬────────┘
                 │
                 ▼
          ARCHITECTURE.md
                 │
                 ▼
        ┌─────────────────┐
        │ Claude          │
        │ Critical Review │
        └────────┬────────┘
                 │
                 ▼
             REVIEW.md
                 │
                 ▼
          Architecture Fix
                 │
                 ▼
             APPROVED
                 │
                 ▼
        ┌─────────────────┐
        │ Cursor          │
        │ Implementer     │
        └────────┬────────┘
                 │
                 ▼
              git diff
                 │
                 ▼
              Claude
            Code Review
                 │
                 ▼
             Cursor Fix
                 │
                 ▼
               Tests

21. 方案四：自己建立 Orchestrator

當手動 workflow 穩定之後，可以建立：

ai-team/
├── orchestrator.py
├── agents/
│   ├── architect.py
│   ├── reviewer.py
│   ├── implementer.py
│   └── verifier.py
│
├── prompts/
│   ├── architect.md
│   ├── reviewer.md
│   ├── implementer.md
│   └── verifier.md
│
└── state/
    ├── requirements.md
    ├── architecture.md
    ├── review.md
    └── status.json

Orchestrator 負責：

Agent A output
↓
Agent B input
↓
Agent B output
↓
Agent A revision
↓
approval
↓
Agent C implementation

22. Orchestrator 的基本邏輯

Conceptual pseudo-code：

requirements = load_requirements()

architecture = architect(requirements)

for round in range(3):

    review = reviewer(
        requirements,
        architecture
    )

    if review.p0 == 0 and review.p1 == 0:
        break

    architecture = architect.revise(
        architecture,
        review
    )

freeze_spec(architecture)

implementation = implementer(
    requirements,
    architecture
)

diff = git_diff()

code_review = reviewer.review_code(
    requirements,
    architecture,
    diff
)

if code_review.has_blockers:
    implementer.fix(code_review)

verification = verifier()

if verification.pass_all:
    finish()

真正實作時可以：

call OpenAI API
call Anthropic API
call Cursor SDK / CLI
call Git
call test commands

23. 如何避免 AI 無限討論？

一定要有停止條件。

例如：

MAX_ARCHITECTURE_ROUNDS = 3
MAX_CODE_REVIEW_ROUNDS = 2

以及：

P0 = 0
P1 = 0

就停止 architecture discussion。

不要設定：

Continue until everyone agrees the solution is perfect.

因為：

perfect

係冇客觀標準。

24. 如何控制 Token 和成本？

Multi-Agent 最大風險之一係：

每一輪都將整個 repository
+
全部 conversation
+
全部文件

重新送俾 Model。

比較好：

只傳需要嘅 artifact

例如 Reviewer 只需要：

REQUIREMENTS.md
ARCHITECTURE.md
relevant source files

Code reviewer 只需要：

APPROVED SPEC
git diff
test results

使用 summary

唔好每次傳：

50,000 tokens conversation history

改用：

DECISIONS.md

例如：

# Decisions

- Reuse MarketDataService
- No new database
- Avoid Redis
- Scanner must remain stateless
- Backtest must prevent look-ahead bias

25. Git 在 Multi-Agent Workflow 中的角色

Git 唔只係 version control。

喺 Multi-Agent Workflow 裏面，Git 可以係：

Shared source of truth

例如：

Agent A
↓
changes ARCHITECTURE.md

Agent B
↓
reviews commit

Agent C
↓
implements code

Reviewer
↓
reviews git diff

最好每個 feature 使用：

feature branch

例如：

feature/vcp-scanner

如果多個 implementation agents parallel 工作，可以再考慮：

Git worktree

避免多個 Agent 同時修改同一 working directory。

26. MCP 和 Multi-Agent Orchestration 的分別

MCP 同 Multi-Agent orchestration 唔係同一樣嘢。

MCP

主要係：

AI
 │
 ├── GitHub
 ├── Jira
 ├── Database
 ├── Browser
 ├── Filesystem
 └── Internal API

用途：

俾 AI 使用外部工具同資料。

Agent Orchestration

主要係：

Agent A
  ↓
Agent B
  ↓
Agent C

用途：

管理 Agent 之間嘅工作流程。

兩者可以一齊使用：

Orchestrator
   │
   ├── Architect Agent
   │      └── GitHub MCP
   │
   ├── Reviewer Agent
   │      └── Filesystem
   │
   └── Implementer Agent
          ├── Git
          └── Terminal

27. 推薦的起步方案

如果你係第一次建立 Multi-Agent coding workflow：

Stage 1

只用三個角色：

Architect
Reviewer
Implementer

Stage 2

加入：

Verifier

Stage 3

將佢哋放喺同一個 Agent environment，例如 Cursor subagents。

Stage 4

當流程穩定之後：

OpenAI
+
Anthropic
+
Cursor

建立 Hybrid workflow。

Stage 5

最後先寫：

orchestrator.py

自動管理：

Architecture
↓
Review
↓
Revision
↓
Implementation
↓
Verification

最重要：

先將 workflow 跑順，先至 automate workflow。

唔好掉轉次序。

28. 實戰 Checklist

開始一個新 feature 前：

29. 下一步：逐步自動化

Multi-Agent AI development 最容易令人興奮嘅地方係：

我可唔可以一次過起十個 AI Agent？

但真正有效嘅做法通常係由：

Human-controlled workflow

開始。

再逐步變成：

Human
  ↓
Manager Agent
  ↓
Specialist Agents

最後先變成：

Human
  ↓
Orchestrator
  ├── Architect
  ├── Reviewer
  ├── Implementer
  └── Verifier

你嘅角色亦會慢慢由：

Developer who asks AI to write code

變成：

Engineer who designs and manages AI development systems

而呢個轉變，可能比單純學識更多 prompt 技巧更加重要。

建議實踐方式

第一次實驗可以揀一個細 feature。

例如：

Add one small API endpoint

或者：

Add one scanner rule

不要一開始揀：

Rewrite the entire application

完成一次完整流程：

Requirement
↓
Architecture
↓
Review
↓
Spec Freeze
↓
Implementation
↓
Code Review
↓
Verification

之後記錄：

邊個步驟有價值？
邊個步驟浪費 token？
邊個 Agent 經常重複？
邊啲步驟可以 automate？

當你重複做過幾次，就可以開始設計自己真正嘅：

AI Software Development Team

用多個 AI Agent 協作寫程式：從手動 Workflow 到自動 Orchestration

Table of Contents

1. Multi-Agent Workflow 是什麼？

2. AI Model、AI Agent、AI Tool 有什麼分別？

AI Model

AI Agent

AI Tool / Environment

3. 為什麼不應該只用一個 AI？

Correlated Errors

4. 最簡單的三個 Agent 架構

5. 我應該用三個不同 AI，還是同一個 AI 開三個 Agent？

方法 A：同一個平台開三個 Agent

方法 B：三個不同 AI

方法 C：Hybrid

6. 推薦的角色分工

1. Architect

2. Reviewer / Critic

3. Implementer

4. Verifier / QA

7. 第一階段：先不要寫 Code

8. 建立 Shared Artifacts

REQUIREMENTS.md

9. Architect Agent

10. Reviewer / Critic Agent

11. Implementation Feasibility Agent

12. Feedback Loop 應該如何停止？

13. Spec Freeze

14. Implementation Agent

15. Code Review Agent

16. QA / Verification Agent

17. 完整 Workflow

18. 方案一：完全手動

ChatGPT

Claude

Cursor

19. 方案二：只用 Cursor Subagents

20. 方案三：跨平台 Hybrid Workflow

21. 方案四：自己建立 Orchestrator

22. Orchestrator 的基本邏輯

23. 如何避免 AI 無限討論？

24. 如何控制 Token 和成本？

只傳需要嘅 artifact

使用 summary

25. Git 在 Multi-Agent Workflow 中的角色

26. MCP 和 Multi-Agent Orchestration 的分別

MCP

Agent Orchestration

27. 推薦的起步方案

Stage 1

Stage 2

Stage 3

Stage 4

Stage 5

28. 實戰 Checklist

29. 下一步：逐步自動化

建議實踐方式