結論

Agent team context 隔離是 LLM-era review 工具設計的核心模式 — 用 N 個獨立 reviewer instance 各自跑 background、各自寫 output file、主 context 只接精煉摘要、不被 reviewer 細節污染。

跟 multi-pass review（#83）的差別：#83 是 同一 reviewer 換輪次 frame（生成 / 對意圖 / 機會成本 / grep / 反例）；本卡是 不同 reviewer instance 各自獨立（規範 / 案例準確 / 跨章一致 / compositional-writing 等）。兩者正交、可疊加。

跟 multi-pass review 的差別

兩軸正交、可疊加 — 同一 reviewer instance 內跑 multi-pass（#83）、跨 reviewer instance 各自獨立（本卡）。Case-first stage 3 設計同時用兩軸：3 個 reviewer instance 各自獨立 + 每個 reviewer 內部跑多輪 frame check。

為什麼這層設計重要

單一 reviewer 同時處理多維度有兩個限制：

1. 維度盲點：一個 reviewer 同時看寫作規範 + 案例準確性 + 跨章一致性、容易維度互相干擾、最後每個維度都看不深
2. Context 污染：reviewer 讀完整 commit + 所有案例 + 所有章節後、自身 context 被佔滿、給的建議也對應主 context 跟著沉重

Context 隔離解這兩個問題：

• 用 N 個專責 reviewer、各自只處理一個維度 → 維度深度提升
• Reviewer 各自 background、不污染主 context → 主 context 保留判讀空間
• Reviewer 寫 output file、不傳 raw 內容到主 context → 主 context 增量極少

設計紀律：何時用幾個 reviewer

Reviewer 數量決定取決於審查對象的維度複雜度：

維度設計要對審查對象客製、不要固定一套維度套所有任務。

平行 background 的具體實作

Case-first stage 3 的實作 pattern：

 1# Agent tool spawn 平行 background
 2for reviewer_id in ['A', 'B', 'C']:
 3    Agent({
 4        description: f"Reviewer {reviewer_id}: {dimension}",
 5        subagent_type: "general-purpose",
 6        run_in_background: True,
 7        prompt: get_reviewer_prompt(reviewer_id)
 8    })
 9
10# 主 context 不阻塞、繼續其他工作
11# Reviewer 完成時主 context 接通知（task-notification）
12# Reviewer 各自寫 output 到 /tmp/reviewer-{id}-report.md
13# 主 context 讀 output 彙整、不讀 raw conversation transcript

關鍵設計選擇：

1. run_in_background: true：平行跑、不阻塞
2. Reviewer 寫 output file：報告寫 /tmp/... 不污染主 conversation
3. 主 context 不讀 reviewer transcript：只讀 task-notification 的 summary + 最後讀 output file
4. Reviewer prompt 含「不要佔我主 context、報告寫進檔即可」明示：避免 reviewer 把 raw issue 都吐回主 conversation

Reviewer 維度設計：跟著任務客製化

Reviewer 維度不該固定 — backend/07 batch 1 案例驅動章節用「規範 / 案例 / 跨章一致」三維度、方法論審查用「規範 / 三方自一致 / 概念邊界 / compositional-writing」四維度。

設計原則：

• 拆 axis 不重疊：每個 reviewer 的維度跟其他 reviewer 互斥（如「規範」vs「案例準確性」是不同 axis）
• 覆蓋審查對象的關鍵風險：審查 case-driven 章節要 case fidelity reviewer、審查方法論要三方自一致性 reviewer
• 預期 issue baseline 設好：每 reviewer 給 prompt 預期數量、reviewer 不要過度抓 / 漏抓
• prompt 含主 context 保護指令：「報告寫到 /tmp/X-report.md、不要在主 conversation 吐 raw issue」

反模式

跟其他抽象層原則的關係

判讀徵兆

核心：Agent team context 隔離是 LLM-era review 工具的設計模式 — 用 instance 隔離換維度深度跟 context 保護。維度設計要對任務客製化、不要固定不變。