建置和部署人工智慧代理變得越來越容易。借助代理框架和基於雲端的託管環境，您只需一個下午即可將代理部署到雲端。現在，無需編寫大量程式碼或進行大量基礎設施建設，即可建立包含記憶體、可觀測性和 MCP 連接工具的多代理系統。

這種便利性，再加上人工智慧編碼助理讓產品發布變得前所未有的輕鬆，催生了一個值得探討的趨勢。許多開發者直接將使用者介面連接到他們的代理，彷彿代理在執行時就是整個後端。這種做法看起來簡潔明了，也覺得有效率又方便。而且，這恰好也是大多數演示所展示的，因此團隊採用這種模式也就不足為奇了。

該圖展示了一種直接客戶端→代理架構，只有一個入口點，其中代理執行時取代了整個後端。

這種方法在探索想法時非常有效。但一旦從演示階段過渡到實際應用，這種客戶端到代理的模式可能就會失效。這並非因為某個特定的代理程式執行時本身有其局限性，而是因為實際的生產系統仍然需要與以往相同的架構層。

Web應用程式仍需要輸入過濾。 API仍然需要速率限制。業務邏輯仍然需要一個存放位置。服務仍然需要與其他系統協調。一旦這些要素都考慮進去，架構就會變得更加熟悉。

人工智慧代理擴展了應用程式的功能，但它們並不會抹殺優秀系統設計的基本要素。代理本身並非系統，而是系統內部的功能。

讓我們來談談這意味著什麼以及為什麼它很重要。

為什麼直接客戶端→代理架構是不完整的

術語說明：本文中， 「執行時期」指的是伺服器端執行代理邏輯的託管環境。我總是以 Amazon Bedrock AgentCore Runtime 為例，但同樣的概念也適用於其他託管環境。 「代理」或「代理服務」是指您已部署的程式碼，其中包含代理框架、提示和工具整合。

上游服務或模組是指在請求到達代理之前處理請求的所有元件（UI、網關、路由器、後端）。

>

下游服務或模組是代理呼叫的工具和資源（MCP 工具、API、資料庫、內部服務）。

當客戶端直接與代理程式執行時間通訊時，通常存在於其他元件中的職責要么會完全遺失，要么最終會被推入到它們不屬於的代理程式碼中。

由於缺少典型的 Web 架構元件，代理程式需要處理以下事項：

1. 請求和安全邊界

 Input sanitization, API level authorization rules, web traffic filtering, rate limiting, throttling, and safety checks. 

2. 應用和系統編排

 Coordinating services, enforcing business rules that span multiple systems, and managing workflow transitions that require durability outside an agent session. 

3. 韌性和營運方面的考量

Retries, backoff behavior, event buffering, and behaviors that protect downstream systems. 

代理或託管執行時或許能夠處理部分此類任務，但它們的設計初衷並非是作為完整的後端、中間層或 Web 伺服器。這與我們不會在大多數生產系統中直接將客戶端指向 AWS Lambda 函數（而不加入保護層）的原因相同。同樣，對於大多數用例而言，代理也並非旨在作為直接面向前端的服務。

這種架構在實務上會失效的地方

以下是客戶端→代理模式在生產環境中可能失效的 3 種方式：

1. 交通流量、成本和負載模式變得難以控制。

 When the UI talks directly to a single agent service without upstream boundaries, there is no clean place to enforce rate limits, handle noisy clients, or cap usage per user. A small bug, a retry loop, or a surge in usage can translate into a flood of LLM calls, driving unpredictable latency and inference costs without a structured way to throttle or shed load.

1. 每次變更的影響範圍都相同，因為所有東西都裝在一個部署單元裡。

 When validation logic, business rules, integration code, and agent behavior all live in the same service, every small change requires touching and redeploying the entire agent app. A tweak to a business rule, a simple bug fix, or a prompt change all share the same blast radius and rollback path, which slows iteration and makes failures harder to localize. 

1. 隨著系統規模的成長，重構會變得脆弱。

 When the agent service acts as the entire backend, every aspect is fused into a single deployment unit. Additionally, many agent runtimes expose a single entrypoint like `POST /invoke`, which means every feature, workflow, and behavior enters through one undifferentiated entrypoint. 

Nothing distinguishes one operation from another, so you lose the natural places where you would normally enforce permissions, validate input, or apply business rules. 

With this setup, extending the architecture becomes difficult. Adding new functionality, queues, or workflow orchestration later means untangling tightly coupled logic. Adding features risks rewriting the agent, because the system never developed the separation needed to evolve cleanly.

為什麼關注點分離仍然重要

我們將系統拆分成模組，因為每個模組都處理特定類型的複雜性，從而減輕了系統其他部分的負擔。這種職責分離能夠確保責任範圍明確，避免邏輯跨模組洩漏，實現解耦，並使系統在大規模執行時更具可預測性。

當所有功能都運作在單一邊界內時，可測試性也會受到影響。將功能劃分到清晰的模組中，可以更輕鬆地隔離元件、模擬依賴項並進行有針對性的迴歸測試。

經驗豐富的開發人員和系統工程師憑直覺就知道這一點，但人工智慧工具的快速發展降低了代理部署的門檻，使得人們可以在沒有架構背景支援代理之前就發布代理程式。

作為技術社群，我們應該推廣現實世界的模式和經驗教訓。提供更多高級用例範例以及簡化的教程，將有助於我們共同學習，並最終制定一套架構良好的智能體設計指南。

在智能體系統中平衡簡潔性和結構性

就像其他解決方案一樣，隨著活動部件的增多，您現在需要負責操作和維護它們。

就像負載平衡器、API 閘道和資料庫連線池會增加複雜度一樣，增加其他元件也會增加複雜度。這些元件的存在是因為它們承擔或抽象化了特定類別風險或責任的處理，從而使核心應用程式程式碼無需處理這些事務。它們提高了整個系統的可靠性。

但這並不意味著你必須建立一個龐大的、高度分散的微服務架構才能正確使用代理。

你可以建立一個簡潔的配置，在代理前端部署負載平衡器和路由器元件；或增加一個 API 閘道來進行基本的流量整形和保護，僅此而已。這種模式對許多團隊來說都完全適用，尤其是在初期階段。

同時，在全球範圍內運營的公司或具有複雜需求的專案自然需要更多元件。它們可能會引入額外的服務，用於編排、工作流程持久性、訊息緩衝、網路連接或跨系統協調。這些架構更加複雜，因為其需求和流量模式決定了其複雜性。

這兩種極端情況都合理。關鍵在於根據你的用例和限制條件選擇合適的架構。目標並非為了複雜而複雜，也不是把所有東西都扁平化到一個模組裡。而是引入最少的元件，從而有效地降低風險、提高安全性，並隨著系統的發展和變化保持靈活性。

這種平衡能幫助你從簡單的入手，而不會在以後把自己逼入絕境。

哪些內容應該放在代理端，哪些內容應該放在後端？

綜上所述，哪些內容應該屬於代理，哪些內容應該屬於其他元件？

代理框架很容易模糊這些界限，但保持界限清晰才是防止系統崩潰成昂貴爛攤子的關鍵。代理程式的建置方式很大程度上取決於你的用例和技術選擇。代理框架的實作方式各不相同，因此不同用例的需求也各不相同。沒有萬能的解決方案。以下是一些入門的高級指導原則。

通常屬於上游的元件（使用者介面、閘道、路由器、後端）

• 輸入整形、驗證、速率限制和網路流量過濾

• 核心業務邏輯

• 協調各項服務或編排複雜的工作流程

• 工作流程狀態、重試、編排和持久性

將這些問題分開，可以將安全性、驗證和業務規則與核心代理程式碼分開，減少變更的影響範圍，並允許您變更代理行為，而無需不斷重寫維持系統基本運作的邏輯。

通常情況下，代理內部包含哪些內容？

• 使用代理框架呼叫LLM

• 工具選擇與編排邏輯

• 代理會話狀態、上下文和記憶體處理

智能體通常負責解讀目標、選擇行動並根據上下文進行推理。決策可能來自模型、圖級編排或確定性路由，具體取決於框架和用例。

工具中通常包含哪些東西？

• 讀取或寫入資料

• 查詢記錄系統

• 觸發確定性程式碼

• 呼叫內部或外部 API

• 觸發另一個代理執行工作

工具封裝了操作。模型可以決定何時需要這些工具，而工具則控制它們如何執行底層操作。

AWS AI代理架構模式

代理程式就像其他功能一樣，可以融入系統中。您可以保持輕量級設計，也可以隨著規模和需求的變化擴展到更分散式的架構。

以下重點介紹的模式有意省略了代理系統的其他部分，例如記憶體、MCP 伺服器、RAG 和多代理通訊。這些固然重要，但它們位於代理程式執行時內部或其下游，而非我們在此關注的上游架構元件中。

您可以根據自身用例擴充或調整這些模式。我將以 AWS 服務為例，並使用 Amazon Bedrock AgentCore Runtime 作為代理程式執行時，但您也可以將這些元件替換為其他供應商的服務，並保持相同的模式。

快速了解亞馬遜 Bedrock AgentCore 入門指南

由於以下範例使用了 AWS 服務，因此這裡先介紹一些基本概念。 AgentCore Runtime 是一個託管的無伺服器環境，用於託管 AI 代理程式。它負責部署、擴展和會話管理，並可與 AWS 內外的眾多工具和服務整合。它同時支援基於 IAM 和 OAuth 的身份驗證，因此您可以將其整合到現有的安全模型中。要了解更多關於 AgentCore Runtime 的訊息，請點擊此處。

1. 最小 API 網關模式

用戶端 → Amazon API Gateway + AWS Web 應用程式防火牆 (WAF) → Amazon Bedrock AgentCore 執行時 → 下游服務

使用此方法

• 您正從原型階段過渡到生產階段，並且希望使用數量較少但易於理解的層。

• 您需要身份驗證、速率限制和輸入驗證等基本保護措施，但目前還沒有龐大的服務生態系統。

API Gateway 和 AWS WAF 在呼叫代理之前提供身份驗證、速率限制、路由、Web 流量過濾和受控邊界。

您可以選擇在 API 閘道和代理程式執行時間之間包含一個 AWS Lambda 函數，這樣您就可以在呼叫代理程式時編寫自訂邏輯，包括確定性輸入驗證或其他邏輯。

AgentCore Runtime 使用 OAuth 或 IAM 處理入站身分。

如果之後需要對傳入訊息進行排隊，可以在 API Gateway 和代理之間新增 Amazon SQS，並使用 Lambda 函數來處理訊息並呼叫 AgentCore Runtime。這樣，您就可以在不改變代理本身運作方式的情況下，處理尖峰流量或有序訊息處理。

2.傳統後端+代理模式

用戶端 → 應用程式負載平衡器 + AWS WAF → Web 伺服器（例如，位於 Amazon EC2、Amazon ECS 或 AWS Lambda 上的伺服器）→ Amazon Bedrock AgentCore 執行階段 → 下游服務

使用此方法

• 您已經有一個需要整合到其中的 Web 後端，或者您需要一個用於路由和業務邏輯的指定元件。

• 您有非同尋常的邏輯或工作流程編排需求。

許多生產環境工作負載仍然執行傳統的 Web 後端。在加入 AI 代理程式後，這些架構並不會消失或需要進行重大改造，而是需要對其進行擴展。

用戶端透過應用程式負載平衡器發送請求，該負載平衡器可以與 AWS WAF 整合以進行 Web 過濾。之後，請求將被傳送到 Amazon EC2、容器或 Lambda 上的 Web 後端。

後端負責處理業務邏輯和系統協調。代理是後端使用的功能，透過 VPC 端點呼叫，以確保流量私密性。

3. 深度自動化代理模式

來自 Amazon EventBridge → AWS Step Functions → AWS Lambda → Amazon Bedrock AgentCore Runtime → 下游系統的事件

使用此方法

• 代理的價值體現在後端流程中，而不是聊天使用者介面上。

• 你希望經紀人成為更大工作流程的一個環節。

• 工作是由事件、日程或流程觸發，而不是由使用者直接互動觸發。

在此，代理商是大型工作流程、管道或自動化任務的一部分。代理可以異步執行，完全沒有面向使用者的介面。

來自 Amazon EventBridge 的事件或計劃執行可以直接使用 IAM 作為驗證方法來呼叫 AgentCore Runtime 中的代理程式。您也可以選擇引入 AWS Step Functions，以協調包含確定性步驟和非確定性步驟的長時間執行或多階段工作流程的各個步驟。

Step Functions 提供了一種工作流程控制機制，因此代理程式無需管理重試、分支或整體工作流程狀態。

代理程式執行其工作，並根據需要呼叫下游服務或工具，而步驟之間的協調則由 Step Functions 負責。這可讓您先使用 AWS Lambda 等服務執行確定性步驟，之後再使用 Amazon Simple Notification Service 通知相關方，或並行呼叫各種服務來執行代理程式。同樣，您可以將 Step Functions 替換為其他工作流程編排器，該概念仍然適用。

這些模式讓你可以從簡單的架構開始，只在需要時引入元件，並逐步發展成更分散式或更成熟的架構。

重點總結

如果你從這篇文章只能記住一點，那就記住這一點：問題不在於你是否能將客戶直接轉接給經紀人。從技術上講，你可以這樣做。問題在於你是否應該這麼做。

短期來看，它可能感覺快速簡單。但從長遠來看，它會導致系統脆弱不堪，難以擴展、難以理解且維護成本高。

結構良好的架構可以讓智能體成為系統中的一等參與者，而不會被其他無關的事務所分心。這樣就能兼顧兩者的優點：既擁有智能體推理的強大功能，又具備成熟分散式系統設計的可靠性。

沒錯，客戶端到代理的教學仍然很有用。它們旨在講解一個重點概念，而不會讓你陷入具體用例的複雜細節。它們會教你如何執行代理，而不是如何圍繞它設計整個應用程式。

但一旦進入生產階段，問題就變成了：我們建構的是完整的系統，還是只止步於代理？

代理人是大腦，架構是軀體，兩者缺一不可。

如果您想了解更多關於 AWS 上的智能體設計模式的訊息，請存取AWS 上的智能體 AI 模式和工作流程，並繼續關注 AWS 團隊的更多部落格文章，我們將在其中探索智能體 AI 用例的具體架構和高級設計模式。

原文出處：https://dev.to/morganwilliscloud/we-need-to-talk-about-ai-agent-architectures-4n49