星期一早上九點二十分，群組裡出現一則訊息。

Kevin 今天臨時請假，這週的 Firmware Exception Review 有人可以代嗎？

這份 Review 每週兩次。產品團隊送來例外申請：舊版本延長支援、特殊客戶暫時不能升級、測試設備要跳過標準更新流程。

表單看起來不複雜：產品、目前版本、目標版本、例外理由與截止日期。最後只要選 Approve、Reject 或 Need More Information。

但過去一年，幾乎都是 Kevin 處理。

主管問：「之前不是在做 Exception Review Agent？」

專案經理回答：「還在等平台團隊開 Tool 權限，下個 Sprint 才能做整合測試。」

這時 Amy 傳了一份檔案。

firmware_exception_review.md

「我可以先試。」她說。

她從沒做過這份工作。

SOP 告訴她流程，Markdown 告訴她怎麼停下來

正式 SOP 有兩頁：誰提出申請、哪些角色依序核准、案件最後放到哪個系統。

Markdown 的開頭卻是幾條不能省略的條件：

• 沒有目前 production version，不開始 Review。
• 沒有設備數量與例外期限，退回補件。
• Security 狀態不清楚，先查 Bulletin，不從 release note 猜。
• 客戶要求不等於相容性理由；必須有 Driver、認證、硬體或法規限制的證據。

最下面還記著幾個容易被忽略的例外：Lab Device 若與 production network 隔離，處理方式不同；Strategic Customer 的商業急迫性不能直接跨過 Critical Security Deadline。

這些內容不像正式政策。有些甚至是很具體的提醒：不要只看申請人填的期限，曾經有人直接填了一年。

Amy 處理第一筆申請時，理由只有「客戶環境目前無法升級」。表單欄位已填完，照 SOP 可以繼續走；但 Markdown 要求相容性限制要有證據。

她退回補件。十五分鐘後，申請人補上第三方軟體的認證文件。

文件證明舊版 Firmware 才被支援；Security Bulletin 同時顯示，四個月後有一項 Critical Issue 必須修正。Amy 因此只核准四個月，並要求到期前重新 Review。

中午前，她處理完七筆。只有一筆因為商業要求與安全期限衝突而停在 Escalation。

Kevin 那天沒有上線。

Agent 專案卡住的，其實不是 Tool

Exception Review Agent 已討論一個多月。功能清單也很完整：讀申請表、查版本資訊、搜尋 Security Bulletin、比對政策、產生風險摘要，最後建議核准或拒絕。

但設計規格時，團隊一直問不完。

什麼情況可以核准？Kevin 說要看原因。

哪些原因？相容性通常可以。

客戶說不能升算嗎？不一定，要有證據。

什麼證據？

每往下追一層，就多一個只有執行者知道的條件。

SOP 描述的是案件怎麼流動；Kevin 做的則是判斷哪些資料可信、哪些情況先停止、兩份規定衝突時不能照一般規則處理。

這些東西散在舊 Ticket、信件、事故紀錄和他的記憶裡。把政策文件集中後接進 RAG，能讓 Agent 找到資料；不會自動讓它知道這份資料在工作裡應該怎麼被採用。

Markdown 讓隱藏的做法第一次能被接手

團隊一開始寫這份 Markdown，只是因為平台還沒準備好。

後來它變成另一種東西：每當 Kevin 說「這個通常不算」，大家不再急著把那句話加進 Prompt，而是先追問條件、反例與依據。

有些整理成固定 Rule；有些明確標成需要人工判斷；還有一些發現只是早年留下的習慣，現在已經不必要。

這份 Markdown 不會自己查資料，也不會自動做 Recommendation。它的價值不在於取代 Agent，而在於把一個人的工作方法變成另一個人可以閱讀、質疑、修改的東西。

這也是為什麼它比平台更早開始工作：Agent 還沒上線時，Amy 已經能用它完成大部分案件；而她卡住的地方，正好就是下一版規格需要補的地方。

隔天 Kevin 回來，Review Queue 是空的。Amy 留下七筆紀錄，並在 Markdown 補上一條新發現的 Stop Condition：商業要求若與 Critical Security Deadline 衝突，不能由 Review 者自行核准。

那份檔案多了一位 Contributor。

平台下週才會完成測試，但這份工作已經不再只存在 Kevin 的腦中。