AWS 用一個流程講懂 AI Agent

我把 AWS 的 AI agent 說法拆成可直接照抄的工作流，補上規劃、工具、記憶與反思模板。

我用 agent demo 一陣子了，老實說，很多都很像在演。模型會講、工具會叫，畫面也做得漂漂亮亮，可一碰到真正的任務就開始鬆掉。它會忘記自己在幹嘛，會把目標講得很大聲卻做歪，甚至一路衝進錯的分支，還以為自己很聰明。

我最受不了的就是，大家老把「agent」講成「LLM 加工具」就結束了。然後系統一旦需要規劃、記憶、停手，整個東西就像被抽掉骨頭。這種東西看起來很新，實際上只是更會講話的自動回覆器。

後來我看了 AWS 這篇 What are AI Agents?，才終於找到一個比較乾淨的講法。它不是把 agent 神化，而是把它講成一個有決策迴圈的工作流。這個版本比較無聊，但也比較能做。

先別把每個聊天機器人都叫 agent

An artificial intelligence (AI) agent is a software program that can interact with its environment, collect data, and use that data to perform self-directed tasks that meet predetermined goals.

翻譯一下就是：agent 不是只會吐字，它要能觀察環境、收集資訊，然後朝著某個目標自己往前推。AWS 在這裡其實是在劃線，分清楚「模型回答了我」跟「系統真的做完事情」是兩回事。

我以前也被這個詞搞過。很多團隊來找我，說要「加 agent」。結果我一問，發現他們要的根本不是哲學機器人，而是能讀上下文、選下一步、把任務推到底的流程自動化。講白一點，他們要的是好用，不是名詞漂亮。

我自己的判斷很簡單：如果一個系統沒有環境、沒有狀態、沒有目標、沒有行動，它多半不是 agent，只是 prompt 外套穿得比較厚。

實操寫法很直接：你先把 agent 能看到什麼、能做什麼、要達成什麼、什麼時候該停下來寫清楚。寫不出來，就先別急著做架構圖，因為那通常只是把混亂畫得更工整。

• 環境：它能讀哪些資料源？
• 行動：它能呼叫哪些工具或輸出哪些結果？
• 目標：成功長什麼樣子？
• 停手規則：什麼情況要交給人？

自治不是加分項，是整個難點

AI agents act autonomously, without constant human intervention.

AWS 這句話很直白，也很煩，因為它點到痛處了。一般軟體是照指令跑，agent 則是根據當下狀態自己決定下一步。這差異聽起來不大，實際上超級大，尤其是你真的要上線的時候。

我看過一堆所謂「agentic flow」，其實每一步都要人按確認。那不是自治，那是包裝得比較像產品的核取清單。這樣做不是不行，但你就老實承認它是半自動，不要硬裝成 agent 行為。

自治真正麻煩的地方在於風險會一起上來。系統一旦能自己決定下一步，你就不能只靠「模型很聰明」這種鬼話。你要有權限範圍、速率限制、工具邊界，還要有壞掉時怎麼回收的機制，不然它會比人類更快地把錯事做完。

實操上，我會先把動作分三類：可以自動做、需要確認才做、永遠不能自己做。這一步很土，但真的省很多麻煩。你越早分，後面越不會在資安、法務、客服之間來回打架。

• 可自動：唯讀查詢、摘要、分類
• 需確認：寄信、建單、改資料
• 禁止自動：刪除資料、付款、法律承諾

沒有明確目標，agent 只會亂表現

AI agents are driven by objectives. Their actions aim to maximize success as defined by a utility function or performance metric.

這段聽起來很學術，但其實是最實際的地方。agent 需要一個能優化的目標，不然它會開始優化一些看起來很像進步、其實完全沒用的東西。你如果把目標寫糊，它就會自己補空白，然後補出一堆奇怪行為。

AWS 拿物流、客服這些情境來講，我覺得很對。目標不是「很有幫助」，而是「解決問題」、「縮短配送時間」、「補齊缺件資訊」。目標越具體，規劃才越能成立；目標越空泛，模型就越容易開始演戲。

我之前看過一個團隊把目標寫成「改善客戶體驗」。結果 agent 開始做一堆看起來很貼心的事：回覆變長、道歉變多、語氣變溫柔。問題是，工單還是沒消。後來我們把目標改成「降低首次接觸未解決率」，整個設計才終於收斂。

實操寫法：你先定義成功指標，再寫流程。不要先做工具串接，最後才想「欸到底怎樣算完成」。如果量不到，agent 通常就會去優化最容易偽裝的指標，這不是悲觀，是優化系統的基本物理。

比較像樣的目標通常長這樣：

• 80% 的客服問題不用升級就能結案
• 30 秒內產出合規回覆草稿
• 財務結帳前先找出缺漏紀錄

規劃、記憶、工具，才是 agent 的骨架

The planning module enables the agent to break down goals into smaller, manageable steps and sequence them logically.

AWS 把架構拆成 foundation model、planning module、memory module、tool integration、learning/reflection。我覺得這拆法很對，因為模型不是 agent 全部，它只是推理核心。真正讓系統站得住的，是那些看起來很無聊的層。

白話講就是：它要能分步驟想事情、記得剛剛發生了什麼、也要能伸手到外面拿資料或做動作。沒有規劃，它就會亂跳；沒有記憶，它就會一直重問；沒有工具，它就只能嘴上說自己可以做。

我做原型最常撞到的地方，其實就是工具整合。模型在純文字裡很會講，但一旦要查資料庫、吃亂七八糟的 API 回應、更新 CRM，真相就露出來了。到底是系統真能做事，還是只是會講幹話，這裡一試就知道。

實操寫法：把每一層都明確定義。規劃可以是 prompt、規則引擎或 task graph；記憶可以是 session、資料庫或向量庫；工具可以是 API、腳本或內部服務。重點不是你用多炫的技術，而是每層都有清楚責任。

我會這樣切：

• 規劃：把目標拆成可執行步驟
• 記憶：存狀態、事實、前一次決策
• 工具：真的去做外部動作
• 反思：檢查結果有沒有達標

工作流比模型名字更重要

Most autonomous agents follow a specific workflow when performing assigned tasks.

這句是整篇最值得抄的地方，因為它直接把行銷雜音切掉了。工作流才是產品本體，模型只是裡面的其中一個零件。你如果把注意力全放在模型名號上，最後很容易做出一個很會講話、但流程很爛的系統。

AWS 把流程講成三步：先定義目標，再蒐集資訊，最後執行任務。這聽起來太基本，基本到有點想翻白眼，但老實說，很多 agent 系統就是死在這種基本步驟沒做好。它不是不夠聰明，是沒有穩定循環。

我之前 debug 過一個客服 agent，它老是重複問同樣的資料。我一開始以為是模型不行，後來才發現是工作流壞掉了。目標設定、資訊收集、動作執行之間沒有乾淨切開，所以它一直像緊張過頭的新手助理一樣反覆確認。流程一拆開，行為就穩了。

實操寫法很簡單：每個任務都強迫回答三件事。目標是什麼？還缺什麼資訊？下一步要做什麼？這三題能答乾淨，後面大多都能接得上；答不乾淨，就先別急著加功能。

這裡也是插檢查點的地方。資訊不足就停、信心太低就升級、動作碰到敏感資料就要求確認。agent 系統要能上線，靠的不是花俏，而是能安全地卡住。

多 agent 不是越多越厲害

Multiple AI agents can collaborate to automate complex workflows and can also be used in agentic ai systems.

AWS 提到多 agent 協作，我覺得這是遲早會碰到的路線，但也最容易被濫用。單一 agent 可以把窄任務做得很好；多個專門 agent 可以分工、接棒、互補。理論上很順，實務上常常只是把錯誤分散到更多角色身上。

我對多 agent 一直有點保留，因為很多人加 agent 只是為了讓圖看起來很大張。問題是，agent 數量變多，不會自動變聰明，通常只會增加協調成本、失敗模式，還有一堆「這步到底誰該負責」的爛問題。

但如果任務真的不同，專門化就有價值。AWS 那種 orchestrator agent 協調 specialist agents 的模式，我覺得是比較像樣的做法。由一個總控管流程，其他 agent 各自做檢索、分類、排程、草稿，這樣責任比較清楚。

實操寫法：只有在子任務有不同工具、不同記憶、不同成功標準時，才拆 agent。若大家做的事情其實差不多，那你不是在架構化，你是在製造噪音。

我自己的經驗是，先把單 agent 做穩，再拆角色。不要反過來。很多團隊一開始就多 agent，最後 debug 的時候每個人都在問「到底是誰想的」。

可抄的模板

# AI agent 工作流模板（可直接改成你的專案版）

## 1) 目標
用一句話寫清楚成功條件。

範例：
在限制權限內完成客戶請求，若資訊不足則整理後升級給人工。

## 2) 環境
列出 agent 可觀察的所有來源。

- 使用者輸入
- 對話歷史
- CRM / 工單系統
- 內部文件
- API 回應

## 3) 行動
列出 agent 可執行的所有動作。

- 搜尋知識庫
- 查資料庫
- 產生摘要
- 建立工單
- 交接給人工

## 4) 自治規則
定義哪些動作可自動做，哪些要確認。

可自動：
- 唯讀查詢
- 摘要
- 分類

需確認：
- 寄送訊息
- 建立紀錄
- 更新客戶狀態

禁止自動：
- 刪除資料
- 付款
- 法律或合規承諾

## 5) 規劃迴圈
每次任務都跑這個順序。

1. 確認目標
2. 找出缺少的資訊
3. 蒐集資料
4. 決定下一步
5. 執行動作
6. 檢查結果
7. 重複或升級

## 6) 記憶
定義要存什麼。

短期記憶：
- 目前任務狀態
- 最近訊息
- 工具輸出

長期記憶：
- 使用者偏好
- 歷史解法
- 已知實體與關係

## 7) 工具規則
每個工具都要寫清楚：
- 用途
- 輸入格式
- 輸出格式
- 錯誤處理
- 重試上限

## 8) 反思
任務結束後問自己：
- 有沒有解決問題？
- 有沒有用對資料？
- 有沒有做出不安全動作？
- 下次要改什麼？

## 9) 升級規則
如果信心太低、資料不足、或動作有風險，就交給人工，並附上精簡摘要。

## 10) 輸出格式
只回傳：
- 最終答案
- 已執行動作
- 使用來源
- 升級原因（如果有）

我喜歡這份模板，因為它會逼你先面對那些最討厭的問題：政策在哪、記憶在哪、停手點在哪、誰來接手。agent 專案通常不是死在模型，而是死在這些地方沒寫清楚。

如果你想把 AWS 這篇變成真的能做的東西，就從這裡開始。先寫目標，再定義環境，接著列工具與自治邊界，最後才加規劃和反思。順序不要亂，不然你只是在把混亂自動化。

來源：AWS What are AI Agents? Agents in Artificial Intelligence Explained。我把它改寫成開發者能直接拿去用的工作流與模板，核心框架來自 AWS；延伸閱讀我也會放著 AWS AI overview、Anthropic、OpenAI，拿來對照模型能力跟系統設計的差別。