為什麼先用小型 agent 迭代、再放大到完整 19-agent 團隊，是 AI Agent 開發的關鍵策略。
我們在 OGSM v4 實作中建立了一支 19-agent 團隊，專門負責產出 AIA CEU 建築師教育課程。以 HSW-006（Twin Parks 案例，火災安全主題）為例，完整跑一次這個 fleet 需要 30 到 60 分鐘。
這帶來一個根本問題：迭代成本太高。每次發現 Writer A 的敘事語氣不對、Investigator B 引用的法規連結失效，或 Slide Composer 的字數超標，就必須重啟整個 pipeline。每一次「跑一次、找到問題、修一個地方、再跑一次」的循環，就是 30 分鐘起跳。
HSW-006 Phase 4 試跑時實際碰到的摩擦點：法規資料庫過期導致 Investigator 重跑、Writer 輸出字數不穩定（有時 200 字有時 800 字）、S（System Prompt）字數過長造成 context pressure 偏高、agent 之間的依賴時序不明確、quota 偶發性觸頂需要人工介入。這五個問題都是真實存在的——而每一個都要花 30 分鐘才能驗證修好了沒。
陷阱在於：當迭代成本高，你就會停止迭代。你會開始「差不多就好」，因為再跑一次代價太大。這是 AI Agent 開發最容易掉進去的坑。
先用 local 的機器人，做一個相對規模小的 AIA Agent。可以用很大量的 token 來 improve 他，因為這個 AIA agent 其實相對來說，體驗非常的小。就算迭代多次，也不會花太多的 token 跟時間。
當把這個 AI Agent 打磨得很好——上下文消耗大幅降低之後——再讓他去真實地寫 AIA 的文章。
這裡有一個表面上的矛盾，但其實完全合理：
| 階段 | 規模 | 每次迭代成本 | 允許的優化力道 |
|---|---|---|---|
| 開發期（Mini Agent） | 1 個 agent，1 張投影片 | 低 | 高——可以大量試錯 |
| Production（19-agent Fleet） | 19 個 agent，完整課程 | 高 | 低——每次修改都很貴 |
真正的槓桿點是：在開發期用掉大量上下文，換取 production 時的低上下文消耗。 你在 Mini Agent 上花的每一個 token 都在為 19-agent 團隊的可靠性買保險。
要在 production 消耗少，就要在開發期消耗多。這不是浪費，是投資。
測試驅動開發（Test-Driven Development）不是新概念。但把它套到 AI Agent 的 System Prompt 段落上，邏輯完全一致：
| 軟體工程 TDD | AI Agent 開發 |
|---|---|
| 寫一個會失敗的測試 | 寫 BDD scenario（Given / When / Then） |
| 讓測試通過（最小實作） | 迭代 agent 的 S（System Prompt）和 M（Message） |
| Refactor——清理程式，不破壞測試 | 把確定性動作抽進 scripts/，縮短 S+M 字數 |
| 跑 regression suite | 重跑所有 BDD scenarios，確認沒有 regression |
| 部署到 production | 把 pattern 放大到 19-agent 完整 fleet |
TDD 的精神在於：先定義「什麼是正確」，再去實作。用 BDD scenario 寫死預期行為，然後讓 agent 去達到它。達到之後，再重構讓它更乾淨。這個循環在 Mini Agent 上跑十次，比在 19-agent fleet 上跑一次還便宜。
以 HSW-006 第一張投影片（Twin Parks 火災事故開場）為例，具體步驟如下：
scripts/ 承擔的比例。目標：每次迭代讓數字往下走。
scripts/ 設計、briefing 格式，複製到完整 fleet 的對應 agent 身上。
這裡是一個 BDD scenario 的實際樣子：
# BDD Scenario: Writer A — HSW-006 Slide 1 Opening Narration
# Target: Twin Parks fire case, opening hook
Scenario: Slide 1 narration meets length and framing criteria
Given: Investigator A has produced a structured case summary
(building type, fire date, casualty count, door hardware failure point)
When: Writer A is dispatched with the briefing
Then: Slide 1 narration is 300–500 words
And: The opening sentence is a case hook (NOT a definition or regulatory citation)
And: The Bronx, New York location is mentioned in the first paragraph
And: Door hardware failure is named explicitly at least once
And: No footnotes in body text (all citations in source-note block)這個 scenario 是可以機器驗證的：字數、開場句型、地名出現、關鍵詞、footnote 位置。不需要人眼判斷。
把三個層次放在一起看：
相當於軟體工程的 unit test。範圍最小、最便宜、可以反覆跑。
相當於 test runner + refactorer。寫測試、跑測試、提出修改、重跑驗證。
相當於 shared test fixtures + best practices。從 Mini Agent 提煉出來，供 fleet 重用。
相當於 production system。第一次正式跑，就已經有充分信心。
HSW-006 Phase 4 原本的計畫是直接用 19-agent 團隊寫完整課程。這個方法的問題在前面講過了——每次迭代 30 分鐘起跳，五個摩擦點都要靠「跑一次看看」才能驗證修好了沒。
新的計畫拆成四個子階段：
| 子階段 | 目標 | 預期產出 |
|---|---|---|
| Phase 4a | 建立 Mini-AIA Agent + Iteration Team（5 機器人） | 可以跑 BDD scenario 的最小可用基礎設施 |
| Phase 4b | 用 Iteration Team 打磨 Mini-AIA Agent | context pressure 降低 70%，所有 BDD scenario 通過 |
| Phase 4c | 把 pattern 套回 HSW-006 19-agent fleet | Fleet 的 S/M 結構更新，scripts/ 補齊 |
| Phase 4d | 正式 dispatch HSW-006 完整 production | 整門課的 HTML，可送 AIA 審查 |
注意：Iteration Team（Phase 4a 要建的 5 個機器人）目前是設計階段，尚未實作。這篇文章記錄的是設計決策與背後的思考邏輯，不是已經完成的系統。
這個策略的根本邏輯，其實來自一個很樸素的心理學事實：迭代成本低，才能讓人有膽子做實驗。
當每次試錯只花五分鐘，你會大膽嘗試非常規的寫法。當每次試錯要花三十分鐘，你會開始「差不多就好」、「這樣應該可以吧」、「不用改了吧」。這不是意志力問題，是經濟學問題。
「先小後大」還有另一個好處：你會在問題還小的時候看見它。
你不需要「在 Titanic 行駛中途修引擎」。你需要的是「在船塢造船的時候，把每個零件測好」。
到真正 dispatch 完整 fleet 的時候，你已經親手見過並修過五個摩擦點了。不是靠假設，是靠實際跑過。這才是「把 AI Agent 打磨好」的意思。
Phase 4a：設計並實作 Iteration Team 的 5 個機器人。下一篇文章會記錄每個機器人的職責分工，以及 BDD scenario 的完整格式規範。