Agent 能上線，關鍵是把邊界寫進流程
看到 Cornerstone OnDemand 用 Amazon Bedrock 做資料庫診斷，我覺得最值得討論的不是診斷時間從 45 分鐘降到 10 分鐘，而是它終於把 agent 當成一個受約束的系統來設計。嚴格來說，讓模型多呼叫幾個工具，不等於建立了可部署的 agent workflow。真正困難的是，模型在什麼狀態可以做什麼事，以及它失敗時誰接手。
這個案例把工作拆成診斷、只讀查詢和修復提案三段，每一段都用結構化輸入與輸出交接。這個安排看似工程細節，其實是在處理 LLM 最麻煩的特性：它的文字很流暢，但不保證狀態一致，也不保證下一步真的適合目前的資料。若每個 agent 都只接收一段自然語言描述，前一段的誤判就可能被後一段當成事實繼續放大。結構化的交接格式，至少讓狀態、證據和缺漏資訊有機會被檢查。
第二個重點是權限必須成為 workflow 的一級設計。query agent 只能產生並執行通過驗證的只讀 SQL，remediation agent 面對破壞性操作則要求人工核准。這不是對模型不信任，而是把信任拆成可測試的範圍。模型可以協助找出可能原因，卻不應因為自己生成了一段看似合理的指令，就自動獲得修改生產資料庫的權力。權限邊界越清楚，評估也越具體，測試的不再是「模型聰不聰明」，而是它有沒有越權。
第三個重點是驗證和回退。Bedrock、Strands Agents、RDS、Lambda 與 EventBridge 負責串起執行環境，但工具清單本身不是可靠性設計。只讀 SQL 要先驗證，修復要留下審計軌跡，agent timeout 或資訊不足時回到人工。這些機制看起來會降低自動化比例，實際上卻提高了系統可操作性，因為團隊知道什麼情況下能自動走完，什麼情況下必須停下來。
我會把這種設計濃縮成四個問題：目前狀態是否明確，這一步的權限是否最小，輸出能否由外部規則驗證，失敗後是否有清楚的人工接手機制。少一個，agent 就可能只是把不確定性搬到下一個步驟。多 agent 的數量不是架構成熟度，能否把狀態、權限、驗證、審計和回退寫成邊界，才是從 demo 走到 production 的分水嶺。
這也是我對這個 78% 改善數字的看法。它很有吸引力，但真正可複製的成果不在單一模型或框架，而在工作流把風險切開了。對任何想把 agent 接到資料庫、付款或部署系統的團隊來說，先畫出不可自動化的線，再決定模型要做多少，通常比先追求全自動更接近工程現實。
作者：陳思維