AI Agent 架構拆解：Tool Calling、Memory、Planning 與MCP／A2A

AI Agent 的核心定義是：LLM（大型語言模型）在一個迴圈裡反覆使用工具，直到達成目標為止。這個迴圈不是模型自己憑空轉起來的——負責跑迴圈、呼叫工具、把結果餵回去給模型判斷的是外層的應用程式，應用程式同時也設護欄，例如最多轉幾圈、哪些重要動作要先問過人。而每一步「接下來要做什麼」，才是由模型自己判斷決定的，這也是 Agent 和只會問一句答一句的 Chatbot 最根本的差異。這篇文章不重複 Agent 是什麼，直接往下拆它內部的四個元件，再看 MCP 與 A2A 兩個協議各自解決什麼問題，最後給一張判讀廠商簡報的檢查表。

Agent 內部到底是哪四個模組在運作

一套東西要稱得上 Agent，通常要同時具備四個模組，缺一個就不太算：

• 大腦（模型）：負責理解意圖、推理、決定下一步，是整套系統判斷品質的天花板。
• 規劃：把大任務拆成可執行的步驟，可以是自己排序，也可以是照寫死的流程走。
• 記憶：記住當下做到哪裡、以及跨對話都要遵守的長期規則。
• 工具：實際去呼叫系統、查資料、執行動作的能力，能不能接到現有的 ERP、CRM，權限怎麼控管都算在這裡。

下面分開講這四塊怎麼運作，以及彼此怎麼接起來。

Tool Calling：模型怎麼決定呼叫哪個工具

先釐清幾個常被混用的詞。Tool 是 Agent 可以呼叫的外部能力，例如查天氣的 API、資料庫、或是檢索文件用的 RAG Retriever。Tool Calling 是 Agent 決定要用某個 Tool，並且自己生成這個 Tool 需要的輸入參數。Function Calling 更精確地說，是讓模型從預先定義好的一組 Function 裡面選一個，並且產生符合這個 Function 介面規格的參數。輸出不是自由文字，而是固定格式，這種輸出方式叫 Structured Output。

整個決策過程會組成一個 Agent Loop：判斷下一步 → 執行動作（Action）→ 取得觀察結果（Observation）→ 更新狀態（State）→ 再判斷，一直重複直到任務完成。這裡面幾個名詞要分清楚：

• **Goal（目標）**是 Agent 最終想完成的事，通常比較高層、抽象。
• **Task（任務）**是為了達成 Goal 所需執行的具體工作，通常比較具體。
• **State（狀態）**是系統在某個時間點需要記住的資訊，像是目前的 Goal、走到哪一步、工具回傳了什麼結果。
• **Observation（觀察結果）**是 Agent 執行完一個 Action 之後，從環境得到的實際結果，這個結果會被拿去更新 State，進而影響下一步的判斷。

換句話說，Tool Calling 本身只是「模型怎麼告訴程式我要呼叫這個功能、參數是這些」這個輸出格式的約定，實際的呼叫動作還是在應用程式裡執行的，模型自己不會真的連去外部系統。

Memory：為什麼不能把所有東西都塞進提示詞

Memory 的功能是保存過去的資訊，讓未來的決策可以參考。但不是所有記憶都該用同一種方式存，常見的分法是：

• Short-Term Memory（短期記憶）：保存目前這個任務或對話需要的暫時資訊，任務結束後可能就不需要永久保留。
• Working Memory（工作記憶）：Agent 正在完成某個任務時，暫時保存的、正在使用中的活躍資訊。
• Conversation Memory（對話記憶）：保存對話中重要的脈絡，讓後續的訊息可以延續上下文。
• Long-Term Memory（長期記憶）：保存跨 Session（工作階段）或長時間仍有價值的資訊，但這一塊必須額外考慮隱私、使用者是否能控制這些記憶、以及資料新不新鮮這三件事。
• Memory Retrieval（記憶檢索）：從過去保存的記憶裡，找出跟目前任務相關的那一小部分。

這也是為什麼不能把所有東西都硬塞進提示詞裡一次解決：短期的工作細節跟長期才有效的規則，本質上是不同生命週期的資訊，混在一起只會讓提示詞越來越肥、又帶著不新鮮或不該被看到的內容，而長期記憶一旦牽涉隱私和使用者控制，就不是單純「存起來」就好的問題。

Planning：任務怎麼拆、怎麼邊做邊修

Planning（規劃）是 Agent 在執行前或執行過程中，決定完成目標可能需要哪些步驟。當觀察結果、失敗或需求改變時，重新調整計畫這件事叫 Re-planning。常見的工作模式有幾種，各有取捨：

• 邊想邊做（ReAct 式）：想一下、做一個動作、看結果、再回到想一下。出錯時容易追查，但每多想一輪就多花一次模型用量。
• 先規劃再執行：先列出整張清單，再照著打勾執行，這種模式用量比較省，但彈性較差，做到一半狀況跟預期不同時就不太適用。
• 做完自我檢查：執行完先自己審一遍再修正，對品質要求高，但時間和成本會往上加。
• 多個 Agent 分工：一個負責拆解、一個負責找資料、一個負責產出、一個負責檢查，但除錯難度也會跟著往上推。

其中「先規劃再執行」也可以進一步拆成 Planner-Executor Architecture：由 Planner 想要做什麼，Executor 真正去做，這種拆法適合比較複雜的多步驟任務。

一個實際會用到這些決策點的例子是 Agentic RAG：在原本固定的檢索流程裡，加入幾個由模型判斷的節點。先用一個 Router 判斷這個問題要不要啟動檢索；如果要，Decomposer 會把問題拆成幾個子問題；每個子問題各自保存自己的證據，交給 Grader 判斷目前取回的證據夠不夠回答；最後由 Synthesizer 根據各子問題的評估結果，統整回答原始問題。這套流程每多一個判斷節點，就多一次呼叫模型的延遲與成本，所以如果大部分問題都只是單純的事實查詢，用一次檢索加生成就夠了，只有真的需要整合多份證據的多跳問題，才值得跑完整個 Agentic 迴圈。

Workflow 與 Agent 的界線在哪

固定順序、寫死步驟的流程，不管包裝得多漂亮，都不算 Agent。兩者的差別整理如下：

	Workflow（工作流）	Agent
誰決定下一步	程式碼寫死	模型自己判斷
行為可預測性	高	低
運算成本	較低	較高
出錯追查	容易	困難
面對意外狀況	容易中斷	有彈性
適合場景	報表產出、資料轉檔、固定審批、法遵要求高的作業	客訴處理、資料調查、需求不明確的探索型任務

導入前最該先問的一句話是：這個流程的步驟固定嗎？固定的話就該用 Workflow，兩者的成本差很多。實務上也常混用——整體流程用 Workflow 控住大框架，只在真的需要臨場判斷的環節，才放一個 Agent 進去處理。這部分可以參考 該用工作流還是 AI Agent？先畫得出流程圖就不要用代理 的判斷方式。

MCP：解決 Agent 怎麼接外部工具與資料

**MCP（Model Context Protocol）**是 Anthropic 在 2024 年 11 月提出並開源的協議，核心架構分成三塊：Host（容器與協調者，負責建立和管理 Client）、Client（由 Host 建立，跟每個 Server 維持一個獨立的連線狀態）、Server（提供實際的 context 與能力）。它要解決的問題很直接：如果每個 AI 應用都要跟每個外部系統各自寫一套串接，整合數量會是 N×M；MCP 把它變成 N+M，一個 AI 應用只要支援 MCP，就能接上所有支援 MCP 的系統，反過來也一樣。

2025 年 12 月，Anthropic 把 Skills 的格式開放成公開規格——Skills 解決的是另一個問題：「該怎麼做」。它是一份 Markdown 檔，寫明什麼情況下該啟用、要照什麼步驟走、輸出要長什麼樣子。合起來看，Function Call、MCP、Skills、A2A 這四層其實分工清楚：Function Call 是模型跟程式之間的輸出格式約定，MCP 是 Agent 接外部工具和資料的管道，Skills 是把「怎麼做」寫成可重複使用的手冊，A2A 則是下一段要講的、Agent 跟 Agent 之間的溝通協議。

一旦接上 MCP，等於讓 Agent 有了主動去讀、去寫外部系統的能力，權限邊界也會跟著變：工具權限給得越大，出錯的代價就越大，所以原則是只給需要的工具、只裝可信來源的 MCP Server，不然下載回來的 Server 可能藏著跟說明不符的動作。

A2A：解決 Agent 之間怎麼互相委派

**A2A（Agent-to-Agent Protocol）**是 Google 在 2025 年 4 月發布的協議，目前由 Linux Foundation 負責託管。截至 2026 年 4 月，已有超過 150 個組織支持，列名的包括 AWS、Cisco、Google、IBM、Microsoft、Salesforce、SAP、ServiceNow。應用領域涵蓋供應鏈、金融服務、保險、IT 維運等。

A2A 設計時瞄準六個目標：互通性（Interoperability）、協作（Collaboration）、可被發現（Discovery）、彈性（Flexibility）、安全（Security）、非同步（Asynchronicity）。簡單說，MCP 處理的是 Agent 對工具、對資料的「向下」連接，A2A 處理的是 Agent 對 Agent 的「橫向」協作，兩者互補，不是互相取代的關係。接上 A2A 之後，等於開放一個新的信任邊界——另一個組織的 Agent 能透過 Agent Card 看到你開放了哪些能力，這也是為什麼安全是 A2A 設計目標裡明確列出的一項。

生產環境少不了的控制面

接上工具、串好協議之後，真正決定一套 Agent 能不能穩定上線的，是有沒有把人卡在對的位置。

Human-in-the-Loop 要卡在哪：會改變真實世界的動作、做了就收不回來的動作、代表公司對外說話的動作，一定要讓人按確認。更具體一點說，凡是動到錢、動到客戶資料、動到資料庫的動作，都應該保留人工確認這一關，不要讓它全自動跑完。

為什麼要檢查中間結果：Agent 的風險之一是一步錯、步步錯——迴圈第一步如果查到錯的資料，後面每一步都蓋在這個錯誤之上，而且因為每一步都是模型自己判斷的、不是寫死的，出錯之後要追查原因也比固定流程困難。對策是在關鍵節點檢查中間結果，而不是等到最後才發現整套邏輯建立在錯誤的第一步上。

上線不是終點：Agent 裝完不代表結束，需要有人定期回頭看它實際做了什麼、規則要不要調整。整體可以濃縮成四句話：範圍小一點、權限剛好就好、重要動作有人看、來源要可信。這部分更完整的風險項目，可以參考 AI Agent 導入前要搞懂什麼？權限、流程與風險檢查清單。

看懂廠商簡報的檢查表

很多廠商簡報上寫著「AI Agent」，但拆開來看，有些其實是一條包裝過的固定流程。幾個常見的誤解可以拿來對照：

• 誤解一：以為換成最強的模型效果就會好——實際上導入卡住的原因八成不在模型，而在資料跟流程有沒有講清楚。
• 誤解二：以為可以讓它全自動跑、不用人管——凡是動到錢、客戶、資料庫的動作，都應該保留人工確認。
• 誤解三：以為用雲端服務就不用管資安——Agent 一旦有工具權限，就能主動去讀系統，權限要用最小範圍給。
• 誤解四：先買再說、之後再想要用在哪——正確順序是先挑一個明確、重複性高的流程把它做通，再考慮下一個。

實際判讀時，可以直接問對方三個問題：這個流程的每一步是不是寫死的？遇到意料之外的狀況時，它是會中斷，還是能自己判斷怎麼處理？出錯的時候，查得出是哪一步判斷錯嗎？如果答案是步驟寫死、遇到意外就中斷，那成本結構其實比較接近 Workflow，運算成本較低、行為可預測、但彈性差；如果答案是會自己判斷、能處理意外，那才是真正會動用決策迴圈的 Agent，代價是運算成本較高、行為可預測性較低、出錯也比較難追。兩者沒有誰比較好，差別在於你的流程本身需不需要臨場判斷——步驟固定的作業硬套 Agent，只是把成本墊高而已。

如果還在釐清 Agent 跟聊天工具之間怎麼選，可以先看 AI Agent 是什麼？和 Chatbot、自動化流程差在哪，2026 入門；真的要動手做，目前能實際動手完成多步驟任務的代表性產品是 Claude 和 OpenAI 的 Codex，兩者的差異可以參考 Codex、Cursor、Claude Code 怎麼選？AI 寫程式工具比較。