---
title: "07 - 實戰工作流範例：多代理 + 中央驗證"
type: note
specialty: Programming
tags: [codex從0開始使用教學, 07-實戰工作流範例]
---

# 07 - 實戰工作流範例：多代理 + 中央驗證

← [[06-進階功能-Skills-Automations-多代理]] | [[00-Index]] | 下一篇 → [[08-術語速查表]]

---

## 這篇要幹嘛

前面幾篇講原理（[[06-進階功能-Skills-Automations-多代理|多代理]]、[[05-實戰提示詞與上手流程|prompt 與 review]]、[[04-權限與安全設定|權限]]）。這篇用**真實跑過的工作流**把它們串起來，讓你看到「平行產出 + 中央驗證」到底長什麼樣。

核心心法只有一句，先記住：

> **平行產出，中央驗證。** agent 可以一次很多個同時做事，但「對不對」這關必須收回到一個中央點統一檢查——不能外包給正在產出的那批 agent。

---

## 案例 A：用多代理平行處理大規模知識庫維護

### 背景

一個 Obsidian 醫學筆記庫，**13 科、約 190 篇**臨床筆記。目標是做「全庫品質稽核」並強化偏弱的篇章。190 篇若一篇一篇順著做，又慢又無聊；但它**剛好是適合平行的任務**——各篇之間互相獨立，符合 [[06-進階功能-Skills-Automations-多代理]] 講的「可切成獨立子任務」。

### 流程設計（兩階段 + 一個收斂關卡）

**階段一：平行稽核評分**

- 用平行 subagents **逐科**處理，每批 **5–9 篇**。
- 每個 agent 對自己那批筆記用固定 rubric 評等（A / B / C / D），產出評分與「弱在哪」的理由。
- 重點：rubric 固定 → 評分標準一致、結果可比較、可被中央 review。

**階段二：針對偏弱篇平行強化**

- 把評到偏弱（C / D）的篇章挑出來，再開一批 subagents 平行強化。
- **關鍵紀律：每篇 agent 只改自己那一檔。** 這樣多個 agent 同時寫檔也不會互相覆蓋（呼應 [[06-進階功能-Skills-Automations-多代理]] 的 worktree / 一 agent 一檔原則）。
- **反向連結（cross-link）與 wiki 維護（index / log）不交給各 agent 做**，而是由**協調者最後統一處理**。原因：這些是跨檔的一致性工作，分散給各 agent 會互相踩（大家都要改同一個 index 檔）→ 衝突。集中到一個收斂點做最乾淨。

### 中央驗證關卡（這步是整套的安全核心）

每批強化完，**協調者用 PubMed MCP 逐筆抽驗新增的引用**——檢查 PMID metadata 真偽（這篇 PMID 是否真的存在、作者期刊年份對不對）。

這關實際抓到過：

- **引用到 retracted paper**（已撤稿論文）
- **期刊年份誤植**
- **概念錯誤**

這就是為什麼「平行產出 + 中央驗證」是**關鍵安全設計**：subagent 為了補強內容，可能很自信地塞進看似合理、其實是錯的引用。如果沒有一個中央關卡逐筆查證，這些錯誤會直接進庫、之後很難發現。**產出可以快、可以平行；驗證必須慢、必須集中。**

### 為什麼這樣切是對的

- 任務**可拆**（各篇獨立）→ 值得平行。
- 每個 agent **範圍窄**（只改一檔）→ 不衝突。
- 產出**可被中央驗證**（rubric 一致 + PubMed 抽驗 + 協調者收斂）→ 安全。

三個條件都滿足，正是 [[06-進階功能-Skills-Automations-多代理]] 說的「該平行才平行」。

---

## 案例 B：量產型 subagent（刷題網頁的考題詳解）

另一個專案是一個內科考古題刷題網頁（純前端），需要為大量考題**量產詳解**。這是另一種「大批同質工作」的平行場景，但踩到的雷不一樣。

### 實戰參數（用 token / 時間換出來的經驗）

- **一個 agent 約 10–12 題最穩。**
- **超過 ~16 題容易 stream idle timeout**——題目特別長或混合多個次專科時更明顯，要**切小批**。
- agent 常在 token / 用量上限之間擺盪，而且**多數會「寫完檔案才回報達到上限」**。

### 因此衍生的處理紀律

- **失敗先檢查產出檔，再決定重派。** 因為它常常是「做完了才喊上限」，盲目重派 = 做白工、又燒一次 token。先看 `tmp_drafts/`（暫存產出）有沒有東西，再決定是補沒做完的、還是整批重來。
- **批量抓在甜蜜點**：寧可多開幾批小的（每批 ~10 題），也不要貪心一批塞 20 題然後 timeout 整批重來。

這呼應 [[04-權限與安全設定]] 的「失敗與中斷怎麼處理」：**先看產出、再決定重派**，是省時省 token 的鐵則。

---

## 案例 C：多個 agent / 工具同時推同一個 repo

同一個刷題網頁專案，是**Codex 持續推進 main、Claude 也並行**的並行開發。兩邊都在動同一個 repo。

處理方式：

- **合併前必須 reconcile**：把遠端最新（對方剛推的 commit）先拉下來對齊，再合併自己的改動。
- 降低衝突的天然分工：盡量讓不同 agent / 工具改**不同檔**，附加式的改動（各自加各自的東西）幾乎都能乾淨合併。

這就是 [[06-進階功能-Skills-Automations-多代理]] 講的 worktree / 多源並行：**隔離產出、合併前對齊**。

---

## 案例 D：把固定流程包成 Skill / Automation

當同一套流程跑很多次（例如「產生一篇筆記 → 維護 wiki 層」），就值得把它**包成可重複調用的 skill pipeline**，而不是每次重講一遍 prompt。

實際做法是把流程拆成有分工的幾個 skill：

```
orchestrator  →  writer  →  wiki-maintain
（協調入口）     （產內容）   （維護索引/連結）
```

- `orchestrator`：唯一入口，解析意圖、決定要做什麼、dispatch 給下游、最後做**唯一一次** commit。
- `writer`：只負責產內容，不碰 wiki、不 commit。
- `wiki-maintain`：只維護 index / log / 反向連結，不改筆記主體、不 commit。

好處：

- 職責單一 → 每個 skill 都好 review、好除錯。
- **commit / 收斂集中在 orchestrator**（中央點）→ 不會多個環節各自亂 commit。
- 流程穩定後可掛 [[06-進階功能-Skills-Automations-多代理|Automation]] 定期跑。

這跟案例 A 是同一個原則的不同形態：**產出分散、收斂集中。**

---

## 把四個案例濃縮成可帶走的心法

1. **只在任務真的可拆時才平行化**——強順序依賴、高歧義、共享狀態的任務，乖乖用單一 thread。
2. **每個 agent 範圍要窄**——最好「一個 agent 只改一個檔」，並行寫檔才不會衝突。
3. **產出要可被中央 review / 驗證**——平行產出越多，中央驗證關卡越不能省（PubMed 逐筆查 PMID 就是活教材）。
4. **失敗先看產出再重派**——agent 常「寫完才喊上限」，盲目重派浪費 token。
5. **跨檔一致性（連結 / 索引 / commit）集中到協調者做**——分散給各 agent 會互相踩。
6. **多源並行同 repo → 合併前先 reconcile**——隔離產出、對齊後再合。

---

## 重點整理

- 真實世界的多代理不是「開很多 agent 就好」，而是**產出分散、驗證與收斂集中**。
- 大規模知識庫維護（190 篇 / 13 科）靠「平行稽核 → 平行強化 → 中央 PubMed 驗證」跑得又快又安全。
- 量產型 subagent 有甜蜜點（~10–12 題/agent）與雷區（>16 題易 timeout、常寫完才喊上限）。
- 固定流程值得包成 skill pipeline，把 commit / 收斂集中在 orchestrator 這個中央點。

## 參考資料

- [Introducing the Codex app](https://openai.com/index/introducing-the-codex-app/)
- [Working with Codex](https://openai.com/academy/working-with-codex/)
- [Automations](https://openai.com/academy/codex-automations)
- [Codex | OpenAI Academy](https://openai.com/academy/codex/)

---

← [[06-進階功能-Skills-Automations-多代理]] | [[00-Index]] | 下一篇 → [[08-術語速查表]]