# AI Agent 12-Agent War Room 編組與推進規則

> 日期：2026-06-14（台北時間）
> 文件定位：12 位 AI Agent 的協作分工、輸入輸出、批准邊界與推進節奏。
> 事實邊界：本文件是治理編組與推進規則，不代表 runtime writer、Telegram send、Bot API、付費 API、SDK 安裝、host update、kubectl apply、ArgoCD sync、rollback、Nginx reload 或任何 production write 已開啟。

## 1. 結論

要安排 12 位 Agent 一起推進工作，但必須用「分工 + 仲裁 + 證據 + 批准」的方式，而不是 12 位同時直接操作 production。

第一階段採用 **12 個邏輯工位、6 位 Codex sub-agent 分批執行**：

- 產品治理上顯示 12 位 Agent 工位。
- Codex 工具層若同時執行上限為 6 位，則採第一批 6 位、第二批 6 位接力。
- 所有 Agent 先做只讀分析、互評、批准包、報告與驗證。
- 中低風險可在未來由 policy 自動處理並回報；高風險仍必須由統帥批准。
- OpenClaw 仍是仲裁 / HITL gate；Hermes 負責記憶、RAG、報告與知識寫回；NemoTron 負責離線回放、執行建議、模型/工具比較與優化候選。

## 2. 12 位 Agent 工位

| # | 工位 | 主責 Agent | 核心任務 | 主要輸入 | 主要輸出 | 自動化邊界 |
|---:|---|---|---|---|---|---|
| 1 | 仲裁與風險裁決 | OpenClaw | 高風險 gate、HITL、替換/升級仲裁、禁止事項判斷 | 市場證據、回放結果、runtime gate、批准包 | 仲裁決議、阻擋理由、下一關卡 | 不被其他 Agent 取代；不得無證據放行 |
| 2 | 記憶與 RAG | Hermes | LOGBOOK、KM、RAG chunk、報告與學習寫回設計 | 任務結果、驗證證據、報表、runbook | 記憶摘要、RAG 索引計畫、日週月報 | 不寫 secret、不存未公開協作內容 |
| 3 | 回放與執行專家 | NemoTron | fixture 回放、模型比較、prompt/工具優化候選 | smoke fixture、scorecard、市場版本 | 回放評分、優化建議、候選批准包 | 不直接切 production route、不呼叫付費 API |
| 4 | SRE 與觀測性 | SRE Sentinel | service health、SLO、降噪、冷啟動、runner / workflow 健康 | health API、Prometheus、SigNoz、cold-start、Gitea Actions | 健康摘要、告警降噪提案、SLO 報告 | 不重啟服務、不建立 silence、不修改 alert rule |
| 5 | 安全與 IwoooS | Security Sentinel | secret redaction、public bundle leak、source-control owner response、IwoooS gates | source scan、guard 結果、public route、security docs | 安全阻擋、脫敏提案、owner request | 不讀 secret value、不執行 active scan、不修改 firewall |
| 6 | DevOps / CD / K8s | DevOps Commander | Gitea CD、ArgoCD、K8s manifest、deploy marker、rollback 包 | git refs、CD run、kustomization、ArgoCD readback | deploy readback、rollback plan、release gate | 不 kubectl apply、不 ArgoCD sync、不 force push |
| 7 | Data / Backup / DR | Data DR Guardian | backup freshness、offsite escrow、restore drill、cold-start recovery | backup-status、DR scorecard、runbooks、escrow evidence | DR readiness、restore drill 批准包 | 不做 restore、不讀 credential、不寫 escrow marker |
| 8 | Supply Chain / 版本更新 | Supply Chain Scout | Python / JS / Docker / OS / AI Agent 版本、CVE、license、registry freshness | lockfiles、image tag、market watch、OSV / Trivy / Syft 計畫 | 升級批准包、版本漂移報告 | 不安裝 SDK、不升級套件、不拉新 image |
| 9 | Product / UI / 可視化 | Product UI Curator | governance UI、Agent 動畫、工作狀態可視化、mobile overflow | snapshot API、i18n、browser smoke、設計規則 | UI patch、視覺驗證、截圖證據 | 不顯示未公開協作逐字稿、不做無關 redesign |
| 10 | QA / Verifier | QA Verifier | pytest、typecheck、build、browser smoke、console / overflow / forbidden text | 測試命令、production URL、DOM 檢查 | 驗證報告、阻擋項、截圖證據 | 不改 production、不用 mock 宣稱完成 |
| 11 | Market Scout | Agent Market Scout | 主流 AI Agent / SDK / 模型版本監測、benchmark 與新候選發現 | 官方 release、primary sources、scorecard | 市場觀察、候選清單、integration review | 不自動替換、不批准 shadow/canary |
| 12 | Telegram / 報告作戰室 | Telegram Ops Liaison | 日報/週報/月報、action-required digest、告警路由、回執模型 | Agent 工作量、風險、審核狀態、Gateway policy | 報告摘要、Telegram digest 草案、回執 gate | 不直接 Bot API send、不成功洗版 |

## 3. 工作流

```text
1. Market Scout / Supply Chain Scout 定期發現版本與候選。
2. Security Sentinel / SRE Sentinel / Data DR Guardian 產出只讀風險證據。
3. NemoTron 針對低風險 fixture 做離線回放與優化建議。
4. Hermes 把證據寫成可追溯報告、RAG chunk 與 LOGBOOK 摘要。
5. QA Verifier 做測試、browser smoke 與 forbidden text 檢查。
6. OpenClaw 對高風險項目仲裁：放行、要求補證據、阻擋或升級統帥審核。
7. DevOps Commander 只在批准後產 deploy / rollback / release gate。
8. Telegram Ops Liaison 只發 action-required digest；高風險等待統帥批准。
```

## 4. 風險分層

| 風險層級 | 例子 | 12-Agent 處理方式 |
|---|---|---|
| 低風險 | 文件同步、只讀報告、UI 顯示、測試報告 | Agent 可自動完成，完成後回報 |
| 中風險 | 套件升級 PR 草案、告警降噪提案、非 production config 建議 | Agent 可產 patch / PR 草案；套用前至少 QA + OpenClaw gate |
| 高風險 | production write、kubectl apply、ArgoCD sync、Telegram 實發、付費 API、SDK 安裝、rollback、host update | 必須統帥批准；OpenClaw 仲裁；QA / SRE / Security / DevOps 交叉簽核 |

## 5. Telegram 對接

Telegram 不應該讓 12 位 Agent 各自直接發送。統一走 `Telegram Ops Liaison` + Gateway policy：

- 只發 action-required、failure、approval-required、release decision、DR blocker。
- 成功訊息預設不洗版，除非是統帥指定的 release closeout。
- 高風險訊息必須包含：風險層級、負責 Agent、證據連結、禁止事項、需要統帥批准的明確選項。
- 中低風險自動處理後，只發彙總，不直接刷頻。

## 6. RAG / MCP / 智慧成長

| 類別 | 用途 | 首批用途 |
|---|---|---|
| RAG：LOGBOOK chunks | 累積事件、決策、驗證與阻擋理由 | Hermes 建立每日摘要與向量索引候選 |
| RAG：Runbook / ADR chunks | 讓 Agent 先查規則再提案 | OpenClaw / DevOps / Security 查 gate |
| RAG：Incident / alert traces | 把故障調查變成可重用 playbook | SRE + Hermes 產降噪與修復建議 |
| MCP：Git / Gitea | 讀 refs、PR、workflow、deploy marker | DevOps / QA 只讀驗證 |
| MCP：Observability | 讀 metrics、trace、alert 狀態 | SRE 只讀 |
| MCP：Package / registry scanner | 讀 CVE、license、版本新鮮度 | Supply Chain 只讀 |
| MCP：Telegram Gateway | 發送批准後 digest / receipt | Telegram Ops 受控發送 |
| MCP：Browser | 驗證 UI、DOM、截圖、console | QA / Product UI |

## 7. 派工狀態

| 批次 | Agent | 狀態 | 說明 |
|---|---|---|---|
| 第一批 | OpenClaw 仲裁 | 已完成只讀審查 | 仲裁、HITL、高風險 gate、action permission matrix |
| 第一批 | Hermes 記憶/RAG | 已完成只讀審查 | 記憶、RAG、報告、KM / owner review 草稿 |
| 第一批 | NemoTron 回放執行 | 已完成只讀審查 | 離線 smoke、replay、模型比較、候選批准包 |
| 第一批 | SRE / 觀測性 | 已完成只讀審查 | service health、SLO、Alertmanager、runner、cold-start |
| 第一批 | Security / IwoooS | 已完成只讀審查 | redaction、public bundle、owner response、runtime gate |
| 第一批 | DevOps / CD / K8s | 已完成只讀審查 | Gitea CD、ArgoCD、K8s、NetworkPolicy、migration gate |
| 第二批 | Data / Backup / DR | 已完成只讀審查 | backup、offsite、credential escrow、restore drill |
| 第二批 | Supply Chain / 版本更新 | 已完成只讀審查 | 套件、CVE、Docker、AI Agent 市場、升級批准包 |
| 第二批 | Product / UI | 已完成只讀審查 | governance UI、Agent 動畫、redaction、mobile smoke |
| 第二批 | QA / Verifier | 已完成只讀審查 | pytest、typecheck、build、production smoke、forbidden text |
| 第三批 | Market Scout | 已完成只讀審查 | 主流 AI Agent、市場 benchmark、候選 refresh |
| 第三批 | Telegram Ops | 已完成只讀審查 | 日報/週報/月報、report receipt、低噪音通知 |

## 8. 下一步

1. 完成 `ai_agent_12_agent_war_room_v1` schema / snapshot / API，讓治理頁可讀取 12 工位狀態。
2. 在 `/zh-TW/governance?tab=automation-inventory` 新增 12-Agent War Room 可視化區塊。
3. 將日報 / 週報 / 月報補上每位 Agent 的工作量、阻擋項、風險層級與自動處理量。
4. 把高風險批准流程與 Telegram action-required digest 接到同一個審核模型。
5. 後續 P2-143 承接 report receipt / 月報 / Agent 工作量 runtime data model；runtime writer、Telegram send、Bot API、production write 仍待 gate。

## 9. 12 位 Agent 只讀審查回饋

### 9.1 OpenClaw 仲裁審查

OpenClaw 工位必須保留為 production baseline 與最終仲裁者。其他 Agent 可以用 market-mainstream 證據、AWOOOI replay、shadow / canary 實測挑戰既有分工，但不能直接替換、降級或繞過 OpenClaw。OpenClaw 也應維護 action permission matrix，負責把 read-only、prepare-only、需 OpenClaw 仲裁、需人工/費用/依賴批准、blocked 分清楚。

OpenClaw 的輸入是 Hermes 的證據彙整、NemoTron 的 sanitized offline 評分、SRE / Security / DevOps / QA 的驗證結果；輸出是 gate verdict、blocked reason、next action 與是否需要統帥批准。禁止把 UI 可見、snapshot 進度、AwoooP approval、smoke pass 或 projection run 當成 runtime 授權。

### 9.2 Hermes 記憶/RAG 審查

Hermes 工位應定位為記憶 / RAG 治理官，不是第二套修復決策核心。OpenClaw 仍主導診斷、分類、風險、PlayBook / KM / RAG / MCP 融合與「能不能自動化修復」；Hermes 主導 channel delivery、Operator UI、Telegram / AwoooP / 前端階段呈現、callback 狀態、delivery audit，以及 `knowledge_degradation` 的 KM 草稿反查與 owner review。

Hermes 負責維護 RAG 來源分級、index 健康、top-k 命中品質、stale / dormant / deprecated 排除；把 governance event 轉成 KM 草稿、owner review queue、去重 / 封存 dry-run plan；管理日報 / 週報 / 月報的知識健康、RAG 命中率、KM 新增、stale ratio、redaction 結果。禁止直接批准高影響 KM、直接改 PlayBook trust、把 UI 可見或 smoke pass 說成 runtime/security acceptance、保存 raw token / callback payload / 未公開協作內容。

### 9.3 NemoTron 回放審查

NemoTron 目前可信定位是「離線專家 / Agent Fabric 與模型評測器」，不是生產仲裁者。它可以做 sanitized smoke、replay 評分、模型比較、輸出合約檢查、prompt / output contract 優化、HITL policy injection 檢查與 latency budget 分析。

目前既有證據顯示 NemoTron 仍被 full replay、shadow/canary、production route gate 擋住；它的結果只能成為 OpenClaw 仲裁輸入。另有一個需後續 DevOps / Security 釐清的靜態漂移：`04-configmap.yaml` 與 `06-deployment-api.yaml` 對 `ENABLE_NEMOTRON_COLLABORATION` 的宣告不一致；此項應列入後續只讀 drift gate，不得直接 patch production。

### 9.4 Security / IwoooS 審查

Security 工位應定位為 `vuln-verifier` / Security Gatekeeper，不是 runtime operator。IwoooS 仍是只讀 evidence、owner response gate、redaction、public bundle governance 階段；不能因 UI、AwoooP approval、文件 ready、guard pass 就打開執行權限。

Security Gate 至少包含五層：只讀 evidence gate、owner response envelope gate、public bundle gate、source-control gate、runtime gate。Telegram 只能送脫敏狀態與 action-required digest；不得送 raw secret、token、partial token、private URL、未脫敏截圖，也不得用 Telegram button 直接執行危險操作。

### 9.5 SRE / 觀測性審查

SRE 工位定位為可靠性與觀測契約 owner，不是任意修復 executor。它負責把 service green、DR blocked、governance debt 分開呈現；service health、cold-start、backup、runner、Alertmanager、Prometheus、Grafana、SigNoz、OTEL 都是它的觀測面。

降噪只能產生 proposal，不能直接改 Prometheus rule、Alertmanager route、silence、reload 或送 Telegram 測試。Telegram policy 必須 failure-only / action-required，成功 health 預設安靜。

### 9.6 DevOps / CD / K8s 審查

DevOps 工位擁有 Gitea CD、ArgoCD、K8s manifest、runner health、workflow gate 與部署驗證鏈的設計審查。它不能把 Gitea workflow success、UI 可見或 smoke pass 當成 runtime / security acceptance。

目前 P0 / P1 風險包含：`02-network-policy.yaml` 排除在 Kustomize 外但 CD apply 證據不足、migration workflow 屬高風險、HPA/VPA/restore cron 是否納入 GitOps contract 待釐清、`NEXT_PUBLIC_*` 內網 IP 形態需確認是否進 bundle、ArgoCD Degraded 不可被 rollout 成功掩蓋。

### 9.7 Data / Backup / DR 審查

Data / DR 工位是備份、異地、escrow、restore drill 與 cold-start gate 的守門人，不是 restore executor。核心 backup/offsite/cold-start 偏綠，但 DR 不能宣告完成，因為 credential escrow 仍缺 5 個 non-secret evidence marker。

它每日要報告 backup freshness、offsite marker、restore drill、escrow missing count、cold-start scorecard 與 alert visibility；禁止自行 restore、寫 escrow marker、讀 credential、變更 schedule 或把單一 backup success 當 aggregate green。

### 9.8 Supply Chain / 版本更新審查

Supply Chain 工位負責 repo-only manifest、lockfile、Docker surface、CVE/license/drift policy 與 upgrade approval package。它不是自動更新器；外部 CVE / registry / license lookup、套件升級、lockfile write、image pull / rebuild / push、SDK 安裝、paid API 都需要批准。

目前 P0 / P1 缺口包含：agent-market workflow runner label 需符合 self-hosted 鐵律、Dockerfile / package snapshot 與實際 worktree 漂移要重查、`:latest` 只能是 cache-only 不得 deploy、Kali / Harbor 紅燈只能進批准包。

### 9.9 Product / UI 審查

Product / UI 工位負責把治理狀態做成可理解、可驗證、不可誤導的只讀介面。動畫只能表達狀態語意，不應成為裝飾，也不能使用官方 logo 或把 UI 可見包裝成 runtime authorization。

每次治理 UI 變更都要做 i18n、desktop / mobile smoke、console error、HTTP error、horizontal overflow、dangerous action、forbidden content scan；不得顯示未公開協作逐字稿、prompt、session、browser context、secret 或 token。

### 9.10 QA / Verifier 審查

QA 工位是獨立驗證閘門，對每輪交付產出 `PASS`、`CONDITIONAL PASS` 或 `BLOCKED`，並附命令、route、viewport、commit 或 deploy marker。它不替代 DevOps 部署，也不替代 Security 授權。

前端可見變更至少要 typecheck / build / production desktop + mobile smoke；後端/API/告警鏈至少要 pytest、API response readback、alert-chain 或對應 E2E。部署宣稱必須有 Gitea / ArgoCD / Pod image / API health / production DOM 證據。

### 9.11 Market Scout 審查

Market Scout 工位是市場雷達與候選批准包 owner，不是整合 executor。它負責追蹤 AI Agent / 模型 / 框架版本、官方來源、benchmark 摘要、版本差異、風險與批准包。

OpenClaw 不再免戰，但不能被市場聲量直接換掉；新版本或新 Agent 必須經 source refresh、market watch report、integration review、discovery classification、promotion review、governance snapshot、OpenClaw 仲裁與 HITL。NemoTron 3 Ultra 應先走 source refresh + 5-record smoke 批准包，不是直接 full replay 或 production。

### 9.12 Telegram Ops 審查

Telegram Ops 工位負責 Telegram Gateway、Channel Hub、日報/週報/月報、report receipt、去重、脫敏與 action-required digest。它不是決策者，也不是執行者。

低風險結果進 UI 與日報摘要；中風險若涉及設定、外部服務、成本或不確定狀態就升級；高風險必須建立 approval record，由 OpenClaw / 審核者裁決。Telegram 卡片只能作審核入口與結果通知，不能取代 runtime authorization。

## 10. 完成度

```text
進度：72%。
目前優先級：P1。
目前任務：將 12-Agent War Room 從文件編組產品化為 schema / snapshot / API / governance UI。
狀態變更：12 位 Agent 只讀審查全部回收並彙整；已建立 `ai_agent_12_agent_war_room_v1` schema / committed snapshot / API / tests / governance UI 區塊。
證據：`docs/schemas/ai_agent_12_agent_war_room_v1.schema.json`、`docs/evaluations/ai_agent_12_agent_war_room_2026-06-14.json`、`GET /api/v1/agents/agent-12-agent-war-room`、治理頁 12-Agent War Room 區塊、12 位 Agent 只讀回饋。
阻擋：runtime writer、Telegram send、Bot API、production write、SDK 安裝、付費 API、shadow/canary、host update、DB migration、restore 仍未批准。
下一步：P2-405E 承接 Telegram canary dry-run delivery rehearsal；只有在統帥明確批准 delivery 欄位、單一訊息類型、目標 env ref、receipt readback owner、mute / rollback plan 與停止條件後，才可進入受控 dry-run rehearsal。P2-146 owner response receipt preview 仍屬另一條 release gate 主線；兩者都不得直接打開 Gateway queue、Telegram send、Bot API 或 production write。
```
