我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。

AI Agent 接上 Tools 後，為什麼 Production 變得更複雜？

Day 28 我談到 AI Security 不能只依靠 Prompt，而必須透過真正的 Authorization 與 Infrastructure 建立安全邊界。

但當 LLM 進一步變成 AI Agent，我發現問題又更複雜了。

一般聊天模型產生錯誤答案，影響通常停留在「內容」；但當 Agent 接上資料庫、API、檔案系統、Email，甚至程式執行工具之後，模型的輸出就可能進一步變成真實的「行動」。開始有能力產生真的高風險行動。

我自己在研究 AI Agent 架構時，越來越重視一件事情：Agent 能做到什麼，不能只由模型自己決定，而應該由系統決定它被允許做到什麼。

OWASP 目前也把 Excessive Agency 列為重要的 LLM Application 風險。當 Agent 擁有過多功能、權限或自主性時，一次 Hallucination、Prompt Injection 或錯誤判斷，都可能進一步變成真正的系統操作。

因此 Tool Access 應該遵循 Least Privilege。需要讀取資料，就不一定需要寫入權限；需要查詢檔案，也不代表應該允許刪除檔案。對高風險操作，更應該加入明確授權或 Human Approval。敏感操作明確授權、外部資料視為不可信，以及高風險操作加入 Human-in-the-loop。Google Cloud 在 2026 年也正在把 Agent Identity、Agent Access Management、Guardrails 與 Runtime Defense 當成 Agentic Enterprise 的重要安全基礎。

這讓我開始理解：

AI Agent 的 Production 問題，不只是「模型回答得好不好」，而是「模型做錯決定時，系統允許它造成多大的影響」。

所以問題來了：

如果 Agent 判斷錯誤，我們的 Architecture 能不能讓錯誤停在模型，而不是一路擴散到真實系統？

這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》中，我認為 Agent 時代更需要重視的 Infrastructure 邊界。Agent 能做什麼，不應由模型決定；應由系統決定模型被允許做什麼。從研究 LLM、Agent、Tools 與 Runtime 架構後，我逐漸發現「讓 Agent 能呼叫工具」很容易，但「限制 Agent 只能在正確情境做正確操作，避免越做越錯越修越錯」才是真正困難的工程問題。

關於作者

我是一名 AI × Infrastructure Solution / Integration 技術實作者，專注於 AI、MLOps、Cloud、Docker、Kubernetes、GPU、LLM 與 AI Agent 等技術的整合與落地，跨足 LLM、GPU、Docker、Kubernetes、MLOps 與 AI Agents，持續研究企業 AI 從 Prototype 到 Production 所需要的工程能力。協助企業理解 AI 從 Prototype 到 Production 所需要的技術能力。

本系列同時是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》的延伸實戰筆記。如果想完整理解這些更深的技術問題，未來可以去看這本書(書中包含了一些的範例與提示詞，特別是AMD W7900 48G的使用技術心得，這些是外面很少有的獨家踩坑經驗，未來買書真的賺到！)。敬請期待唷~