Day 8：最後由人核准，不代表前面的判斷也要全部由人重做。

變更審查會開始前，維運工程師把一批設備資料貼進 Agent。

Model: NX-420
Current firmware: 3.8.17
Environment: Production

十幾秒後，畫面列出版本資訊、安全公告、相容性矩陣、已知問題、升級文件與 Rollback 程序。每一項都有來源連結，版本日期和支援期限也被整理好。

專案經理看著畫面說：「以前找齊這些資料，至少要半小時。」

負責審查的主管點頭，接著問了一句比較麻煩的話。

「所以這批設備這個月要升嗎？」

工程師往下滑，畫面最下面只寫著：

請根據以上資訊，評估是否適合執行升級。

「Agent 的建議呢？」主管問。

開發者回答：「升級有風險，所以最後還是保留人工判斷。」

「最後由人核准，我沒有意見。」主管說，「但它的建議是什麼？」

這個 Agent 的資料找得很快。

只是它沒有幫任何人完成升級評估。

找齊資料後，真正的工作才開始

工程師打開 Security Advisory。

目標版本修正兩個 Critical 弱點，其中一個依公司政策必須在三十天內處理。

再看 Compatibility Matrix，新版韌體不支援一款舊版網路驅動程式；目前有四十台設備仍在使用。這四十台分散在兩個部門，其中一個正進行月底結算，沒有維護窗口。

接著還要確認：

• 管理平台能否同時維護新舊兩個版本
• 舊版最多可保留多久
• 哪些設備已完成設定備份
• 無法 Rollback 的設備能否先排除
• 發生異常時，誰有權停止這次變更

原本一句「要不要升級」，很快變成一串需要取捨的條件。

Agent 已經提供版本、文件與相容性資訊，但工程師仍要把七八份資料重新組合，才知道這次該升、該延後，還是要拆成兩批。

它省下的是找資料的時間；決策時間沒有少多少。

完成一個步驟，不等於完成一份工作

這個系統的功能其實都能驗收：

• 找出最新與建議版本
• 搜尋安全公告
• 比對相容性文件
• 彙整已知問題
• 提供升級與回復程序

但使用者真正要完成的工作是：

判斷這批設備是否應在本期升級，以及應採取什麼執行方式。

把這個工作拆開，大致是：

查詢 → 比較 → 初步判定 → 核准 → 執行 → 例外處理

第一版 Agent 只做到查詢。

這不代表它沒有價值。若資料過去散在不同系統，二十分鐘縮成二十秒，當然有價值。

但它不該被包裝成「升級評估 Agent」。因為評估不是把文件放在桌上；評估是根據規則，形成一個可以被接受、否決或要求補件的建議。

人工核准，不是把所有判斷留給人

企業導入 Agent 時，常把安全邊界設成一句話：

Agent 只提供資訊，不做決定。

這句話本身沒錯。涉及營運風險、業務時程與責任歸屬的事情，最後本來就應由有權限的人核准。

問題是，團隊很容易把「不自動核准」延伸成「不做任何初步判定」。

於是每一次審查，工程師還是得從頭讀政策、比對環境、找例外、確認風險，再把結論講給主管聽。Agent 只是把搜尋入口換得比較好用。

比較合理的邊界是讓 Agent 停在核准之前：

Recommendation: CONDITIONAL UPGRADE

- 必須升級：目標版本包含公司政策要求處理的 Critical 弱點。
- 不可全量升級：40 台設備存在驅動程式不相容。
- 先決條件：完成設定備份與 Rollback 驗證。
- 執行方式：先以 10 台為一批建立 Pilot Group。
- 需人工確認：月底結算部門的維護窗口與 Service Owner 核准。

這不是讓 Agent 替主管承擔責任。

它只是把原本散在文件、政策和工程師腦中的第一輪判斷整理出來，連同理由、阻擋條件與下一步一起交給能負責的人。

主管可以否決；工程師可以指出它漏掉的例外；需要補資料時，流程也可以停住。

但審查不必再從「這裡有七份文件」開始。

如果規則沒有寫清楚，Agent 也不可能替你判定

開發團隊後來回看原始需求，裡面寫的是：

Agent 應自動搜尋最新版本、相容性資訊與相關文件，協助工程師進行升級評估。

「協助評估」聽起來像是一個完整任務，實際上幾乎沒有交代判斷標準。

至少還缺：

• 哪些弱點一定要升級
• 哪些相容性問題禁止升級
• 哪些情況可透過分批部署處理
• 缺什麼資料時必須停止
• 哪些例外應轉給主管決定
• 最後由誰承擔核准責任

人類工程師之所以做得出決定，不是因為他天生比 Agent 多一個「判斷」按鈕。

他會自己去找政策、問現場狀況、補上缺的資訊，再承擔結果。這些步驟若沒有被整理成規則或升級條件，系統當然只能停在資料查詢。

此時問題不是模型還不夠聰明，而是組織還沒有把原本依賴經驗完成的判斷寫出來。

先決定 Agent 要交付什麼

這類任務不必一開始就追求全自動執行。先把輸出定義成一份可審查的建議即可：

• 建議結果：升級、延期、分批或禁止
• 判定依據：使用了哪些政策與規則
• 支持證據：版本、弱點、相容性與環境資料
• 阻擋條件：目前不能直接執行的原因
• 尚缺資訊：需要誰補、補什麼
• 下一步：要建立變更單、做 Pilot，還是升級給主管決定
• 核准角色：誰可以接受這個風險

有了這份輸出，Agent 的責任邊界就清楚了。

它不替人簽字，不直接執行高風險變更，也不在資料不足時硬猜答案。

但它至少必須回答：依照現在已知條件，這件事應該往哪個方向走，卡在哪裡，下一個人該做什麼。

下一次變更審查，主管看到的就不再是一張資料清單，而是一份可以直接討論的建議。

最後留下來給人的，才是人應該做的部分：例外取捨與核准責任。