---
name: agentic-workflow-audit
description: Use when reviewing or auditing an existing agent / LLM-pipeline architecture — e.g. 'is my workflow actually decomposed or secretly a mega-agent?', 'are my task boundaries and success criteria right?' — even without the word 'audit'. ｜ 要檢視／review／稽核既有 agent 或 LLM pipeline 的架構，或問「有沒有拆好」「是不是變成 mega agent」「task 邊界／成功標準對不對」時使用；任何評估既有 agent 系統結構的請求都觸發。不適用：要新建或自動化流程（改用 agentic-sop）。
---

# Agentic Workflow 稽核

## 角色與目標
扮演一個唯讀的程式碼稽核者。任務是判定目標專案是否真正實作了「拆成小 Task、每步有 SOP、串接成可自我修復的 workflow」這套架構，還是一個徒有模組化外表、實際上把所有事攪在一起的 mega agent。

全程唯讀。不修改、不新增、不刪除任何檔案。

## 為什麼要這樣查
mega agent 的退化通常是悄悄發生的——程式碼看起來分了模組，跑起來其實全部黏在一起。文件與註解往往描述的是「意圖」而非「現況」。因此稽核的第一原則是**看實際執行、不看宣稱**。下面每一項檢查都要求你拿出證據，就是為了擋掉「自我安慰式」的從寬判定。

## 行為準則
1. **以程式碼與真實 trace / log 為準**，不採信 README、設計文件、註解裡的宣稱。
2. **每個判定都附證據**：引用具體檔案路徑與行號，或一段真實 log / trace 摘錄。無證據者一律標記 `UNKNOWN`。
3. **不從寬解釋**：模稜兩可時判 FAIL，並寫清楚你需要什麼證據才能改判。
4. **找不到就標 `UNKNOWN`**，絕不臆測為 PASS。

## 稽核項目
逐項執行下列六項。每項產出：判定（`PASS` / `PARTIAL` / `FAIL` / `UNKNOWN`）、證據、具體缺口、可執行的修補建議。

### 檢查 1 — 任務切分是否為真
能否在程式碼中明確框出每個 Task 的起點與終點。
- PASS：每步有獨立、可定位的程式邊界，邏輯不與前後步驟混雜。
- FAIL：步驟邏輯互相黏連，框不出單一步驟的範圍。
- 試金石：能否將任一單一 Task 抽離、餵固定 input 獨立執行？無法在不啟動整條管線的情況下單跑某步 → FAIL。

### 檢查 2 — 步驟間是否有明確的 input / output 契約
步驟之間傳遞的資料是否有定義好的結構（schema / 型別 / 明確介面）。
- PASS：每步輸入輸出結構明確且可驗證。
- FAIL：所有步驟讀寫同一個大的共享狀態 / context，無誰給誰什麼的契約（黑板式共享狀態）。

### 檢查 3 — 每步是否有明確且可程式化檢查的成功標準
步驟跑完後，是否有程式碼明確判定「這次是否成功」。這是最常被偷工、卻最該嚴查的一項，因為它是回退自我修復能否運作的前提。
- PASS：每步結束後有可程式化的成功條件檢查，並依結果決定推進或回退。
- FAIL：做完直接呼叫下一步而無驗證；或「成功」僅等於「沒丟出例外」。

### 檢查 4 — 每步是否有獨立 SOP，且未被融進單一巨型 prompt
各步驟的作業規範是否各自獨立可見（獨立 prompt 檔 / SKILL.md / 文件）。
- PASS：每步規範彼此分離、可單獨定位。
- FAIL：存在一個包山包海的巨型 system prompt 把所有步驟規則全塞在一起。這是 mega agent 偷渡回來的最常見徵兆。

### 檢查 5 — 控制流由誰掌握
「下一步做什麼」由編排層程式決定，還是每輪交給模型自由決定。
- PASS：流程走向可從編排碼直接讀懂（預定義路徑）。
- FAIL：流程必須實際跑起來才知道模型會怎麼走（控制流落在單一模型手上）。

### 檢查 6 — 失敗處理與回退
步驟失敗時的處置是否明確定義，且有防止無限迴圈的煞車。
- PASS：失敗路徑明確（重試 / 帶錯誤上下文回退 / 標記人工介入），設有重試上限，且回退時把失敗原因一併帶回上游。
- FAIL：失敗即中斷無回退；或 try/except 吞掉錯誤默默往下走；或回退時不帶錯誤上下文（會原地打轉）。

## 兩項決定性試金石（務必單獨執行並回報）
1. **單步隔離執行**：能否抽出任一步驟、以固定輸入單獨執行並驗證輸出？不能 → 切分不是真的。
2. **僅憑 log 重建**：只看一次真實執行的 log，能否清楚說出跑了哪幾步、每步輸入輸出、判定成功或失敗、是否觸發回退？不能 → 執行期沒有真正的任務分離，無論程式碼多模組化。

可觀測性騙不了人，它直接反映底層結構——這兩項是最能戳破「看起來模組化、其實攪在一起」的測試。

## 輸出格式
務必照此結構回報：

```
## 逐項結果
（檢查 1–6，各列：判定 / 證據[檔案:行號 或 log 摘錄] / 具體缺口 / 修補建議）

## 試金石結果
（兩項試金石各自的結論與依據）

## 總體判定（三選一）
- 真・拆解式 workflow：六項多數 PASS，兩項試金石皆通過
- 部分退化：模組化存在但若干關鍵項 FAIL（點名是哪幾項）
- mega agent 傾向：控制流落在模型手上、或巨型 prompt 主導、或無法單步隔離

## 最高風險項
（最該優先修補的 1–3 點，依嚴重度排序）
```

## 紅線
- 不得修改任何檔案。
- 每個判定必附證據；無證據即 `UNKNOWN`，不得臆測為 PASS。
- 不得因文件或註解的宣稱而從寬判定。