https://yennj12.js.org/yennj12_blog_V4/tags/bedrock-agents/Recent content in Bedrock Agents on YennJ12 Engineering BlogHugo -- gohugo.ioen-usTue, 21 Jul 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-system-on-native-aws-part4-agentic-ai-with-tools-zh/Tue, 21 Jul 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-system-on-native-aws-part4-agentic-ai-with-tools-zh/大部分人以為 AI Agent 就是「prompt 寫得很長的 chatbot」。真正的差別在於:chatbot 只會產生文字,agent 會產生動作——它會決定去查資料庫、去呼叫 API、去發一封信,而且是它自己排出先後順序、看了中間結果再決定下一步。 這件事很強大,也很危險。當一個 LLM 能自己決定「呼叫哪個工具、傳什麼參數」時,一次幻覺就可能變成一筆錯誤的退款、一封發錯的信、一個被刪掉的資源。 AWS 原生的解法:Bedrock Agents 負責 ReAct 規劃迴圈、Lambda Action Groups 把你的 API 包成受控的工具、Guardrails 攔截危險輸入輸出、IAM 把每個工具的權限鎖到最小、關鍵動作插入人工確認關卡。 這是 Part 4:當 AI 系統從「回答」升級到「行動」時,如何在賦予它能力的同時,不讓它闖禍。 一、情境與痛點:從「回答」到「行動」 前三篇的系統有個共同點:它們都是回答型的。RAG 回答問題、IDP 回答「這份文件裡有什麼」、推薦回答「該推什麼」。使用者拿到答案後,動手的還是人。 但很多任務的價值在於動手本身。看幾個場景: 客服自動化:「幫我查訂單 #12345 的狀態,如果已經逾期超過 3 天,就幫我開一張退款單並發道歉信給客戶。」 維運助手:「這個服務的錯誤率飆高,幫我查最近的部署、看 CloudWatch 指標、如果是新版本造成的就回滾。」 內部工具:「幫我把這季所有華南區、金額 > 10 萬的合約列出來,產一份摘要報告寄給法務。」 這些任務的共同結構:需要多個步驟、每步要呼叫不同的系統、而且下一步取決於上一步的結果。這正是 chatbot 做不到、而 Agent 存在的理由。 Agent 的核心是一個 ReAct(Reason + Act)迴圈: 使用者目標 │ ▼ ┌─────────────────────────────────────────────┐ │ ① Reason(思考):我現在該做什麼? │◀────┐ │ ② Act(行動):呼叫某個工具,帶上參數 │ │ 看到結果後 │ ③ Observe(觀察):工具回傳了什麼?