本系列拆解企業導入 AI／Agent 時，工具明明做完了，工作卻沒有因此變好的決策現場。
Day 06：資料會變，不代表判斷需要交給模型。

第三週的 Sprint Review，架構師把流程圖投到螢幕上。

畫面中央是一個名為 Release Package Agent 的方框。左邊接檔案系統和產品資料庫；右邊接規範知識庫、版本查詢工具和報告產生器。方框下方還有一層 Memory，說是要記住使用者前幾次確認過的產品資訊。

User Request
↓
Agent Orchestrator
├─ Package Scanner
├─ Manifest Reader
├─ Version Lookup
├─ Rule Knowledge
└─ Result Generator

「第一階段可以跑完整流程了。」工程師說。「把 Package 路徑貼進去，Agent 會找必要檔案、讀 Manifest、查版本，再根據產品規範判斷能不能送到下一站。」

負責 Release 的工程師把一個資料夾路徑貼進輸入框。

Agent 先列出十四個檔案，然後跳出一個問題：

已辨識到多個產品系列。請確認本次 Package 所屬的產品。

Release 工程師看著畫面。

「產品名稱不是就在 Manifest 裡？」

「有。」開發者說。「但我們怕 Manifest 寫錯，所以讓 Agent 再確認一次。」

他從下拉選單選了一個產品系列。Agent 接著掃檔案、查資料庫、搜尋規範。四十多秒後，畫面出現一份很完整的報告。

已找到主要映像檔、Checksum 與 Manifest。
檔名大致符合產品命名規範。
目前未發現明顯阻擋問題，建議確認版本資訊後進行後續處理。

Release 工程師看完，沒有往下按。

「所以能送，還是不能送？」

開發者重新讀了一次報告。

「它的意思是目前沒有明顯阻擋問題。」

「那就是還要我自己判斷。」

他打開資料夾，指著其中一個檔案名稱。

「這個版本少一位。Manifest 寫 1.4.2，檔名是 1.4.1。這包不能送。」

規範知識庫確實有「版本必須一致」這條。Agent 也把版本資訊找出來了。它只是把這件事當成一個需要提醒的資訊，而不是阻擋條件。

專案經理在筆記裡寫下：

版本不一致時，必須直接輸出 Fail。

Release 工程師把自己的檢查表攤在桌上。

1. 必須存在 image、checksum、manifest
2. 檔名必須符合產品設定的格式
3. 產品名稱必須一致
4. 版本號必須一致
5. Checksum 必須驗證成功
6. 不得包含暫存檔
7. 任一項失敗，Package 不得進入下一站

架構師看著那張紙，問了幾個問題。

「不同產品會有不同規則嗎？」

「必要檔案和命名格式不同，但都在設定檔裡。」

「遇到不認識的檔案？」

「Fail，人工確認。」

「查不到版本？」

「也 Fail。」

「有沒有某種情況，要系統綜合判斷後自行決定放不放？」

Release 工程師想了一下。

「沒有。它只要告訴我哪一項沒過。」

會議室裡那張架構圖忽然變得有點尷尬。

原本的需求寫著：

自動分析 Release Package 是否符合不同產品規範，並針對異常提出處理建議。

這句話裡有「分析」、有「不同產品」、也有「提出建議」。很容易一路推到知識庫、Tool Calling、多輪對話和 Memory。

但真正要完成的工作沒有那麼多層。

它要做的是依產品設定檢查一組檔案；只要有一項不符合，就停止流程並指出原因。

產品不同，檔案名稱不同，版本也不同。變的是資料值，不是判斷邏輯。

資料有變化，判斷不一定有變化

很多任務會被做成 Agent，不是因為真的需要 Agent，而是它每次收到的資料都長得不一樣。

不同產品有不同的檔名規則。不同 Release 有不同版本。不同資料夾裡的檔案數量也不同。從畫面上看，這些都像是在處理複雜情境。

但先要分清楚兩件事。

第一種是資料變了，但處理方式固定。例如把產品名稱、必要檔案、版本格式放進設定檔後，程式每次都照同一套條件執行。

第二種才是規則本身不完整，或同一個條件在不同情境下需要不同解讀。這才會出現語意理解、權衡、例外判定，或必須由人補充脈絡的需求。

Release Package 屬於前者。

同一個 Package 若今天檢查是 Fail，明天用同一份資料再跑一次，也應該還是 Fail。這不是「模型要怎麼理解」的問題，而是規則有沒有被明確寫出來的問題。

把這種工作交給模型，通常會多出原本沒有的事情：

• 規則是放在 Prompt、知識庫，還是程式裡？
• 模型把「版本不一致」當成警告還是阻擋，誰負責確認？
• 同一份 Package 前後兩次得到不同說法，要採用哪一次？
• 模型或 Prompt 更新後，原本的 Pass／Fail 是否改變？
• 不確定時，系統是停止、猜一個答案，還是產出一段語氣保守的文字？

這不是模型不夠好，而是工具邊界不對。

對 Release 工程師來說，版本可能有問題，建議確認 並沒有替他少做任何判斷。他還是得打開 Manifest、比對檔名，最後決定這包能不能送。

一個真正能減少工作量的輸出，反而會長得很簡單：

FAIL

- Version mismatch
  manifest: 1.4.2
  filename: 1.4.1

它沒有比較像 AI，也不需要像 AI。

問題不只是「能不能做」，還有「值不值得這樣做」

專案最初的效益估算很直覺：人工檢查一次大約十分鐘；若自動化，就能省下人力。

這個算法少了一段。

十分鐘是每次執行工作時的成本。把這十分鐘的工作轉成一個能部署、能維護、能處理例外的系統，則是另一筆成本。

這裡暫時可以把前者叫作 Operation Cost，後者叫作 Engineering Conversion Cost。

做選型時，不能只問「人工要花多久」，還要先看：

• 一年會跑幾次？
• 這個產品線還會維護多久？
• 規則多久變一次？
• 誰能修改設定或程式？
• 判錯一次的影響多大？
• 除了 Agent 之外，有沒有成本更低的選項？

假設一年只有四十次 Release，每次人工少花十分鐘，整年大約省七個小時。若為此花三週做 Agent，還加上模型、Prompt、監控與權限維護，這個案子可能很久都不會回收。

但同一份規則若整理成設定檔，用一天寫成 Script，隔天接進既有 Pipeline，結論就不同了。

這裡不是說所有低頻工作都不值得自動化。真正該比的是：為了可靠完成這份工作，哪一種做法的總成本最低，而且在出錯時最容易看見問題。

Agent 能做，不是它該被選上的理由。

選 Agent 前，先過一次最小工具 Gate

這類工作在立項時，不必先討論模型、平台或架構。先把下面幾項問完即可。

這個 Gate 不是要把 Agent 排除在外，而是避免先把工作升級到最高複雜度，再花時間關掉它根本不需要的能力。

如果規則還沒穩定，先用一張 Checklist 跑幾輪；如果規則已經固定，就把它寫進 Script 或 Workflow；只有當工作真的留下無法列舉的語意判斷，才需要討論 Agent 應該接到哪一段。

順序反過來，通常就會得到一張很漂亮的架構圖，以及一個仍然要人自己判斷 Pass／Fail 的工具。

隔天上線的是那支 Script

Sprint Review 結束後，一位工程師把七條規則整理成設定檔。

下午完成第一版程式，隔天接進原本的 Pipeline。Package 上傳後，系統幾秒內就回傳 Fail 原因；遇到沒有設定的新產品，流程直接停止，要求維護者先補上規則。

Release 工程師不再逐一打開檔名和 Manifest。

三週前完成的 Agent 架構圖沒有被刪掉，仍留在專案簡報最後一頁。它證明團隊做得出 Agent。

只是最後開始工作的，是一支不到一百行的 Script。