AI Agent 的「無伺服器」時刻：當 AWS Bedrock 將開發重心從編碼轉向系統設計

雲端大廠正將 AI Agent 開發從繁瑣的指令式編碼推向簡潔的宣告式配置。AWS 於 2024 年 4 月 22 日為 Bedrock AgentCore 推出的「Managed Agent Harness」預覽功能，便是一個明確信號。這項更新讓開發者只需定義模型、提示詞與工具，即可運行功能完整的 Agent，底層複雜的 ReAct 循環與狀態管理則由 AWS 完全託管。這不僅大幅降低了開發門檻，更預示著開發重心的深刻轉移：當 Agent 核心控制流程成為託管服務，真正的差異化競爭力將回歸到更根本的系統設計與治理能力。

什麼是 Managed Agent Harness？

在過去，要建構一個能與外部工具互動的 AI Agent，開發者通常需要藉助 LangChain 或 LlamaIndex 這類框架，親手編寫或調用 Agent Executor。這個 Executor 就像 Agent 的大腦中樞，負責執行一個循環：首先根據用戶請求與歷史對話生成思考，決定下一步是呼叫工具（Action）還是直接回應（Finish），然後解析工具回傳的結果（Observation），再將結果餵回給模型進行下一輪思考。這個過程，也就是業界熟知的 ReAct (Reasoning and Acting) 框架，雖然強大，但實作起來充滿細節挑戰，包括錯誤處理、重試機制、狀態管理與防止無限循環等。

AWS 的 Managed Agent Harness 試圖將這整個「大腦中樞」抽象化並變成一項託管服務。開發者不再需要編寫 Python 程式碼來控制這個循環，而是透過一份設定檔或在 AWS 主控台上，以宣告的方式定義三樣東西：

• 基礎模型 (Foundation Model)：例如 Anthropic 的 Claude 3 Sonnet 或 Meta 的 Llama 3 70B。
• 指令 (Instruction)：也就是系統提示詞（System Prompt），用來定義 Agent 的身份、目標與行為準則。
• 工具 (Tools)：也就是 Agent 可以使用的能力，通常是透過 OpenAPI schema 定義的 API 或 Lambda 函數。

提交這些配置後，Bedrock 會自動生成並管理背後的編排邏輯，處理所有與模型互動、解析工具呼叫、管理對話歷史的繁重工作。這意味著，原型開發的速度可以從數天縮短到數分鐘。

為什麼說這是 AI Agent 的「無伺服器」時刻？

這次的轉變，讓我強烈聯想到雲端運算的「無伺服器」（Serverless）革命。在早期，我們需要手動管理實體伺服器；後來有了 EC2 這樣的 IaaS，我們只需管理虛擬機；最終，AWS Lambda 這類 FaaS（Function as a Service）服務的出現，讓我們連虛擬機都不用管，只需專注於編寫核心的業務邏輯函數即可。

AI Agent 的發展也遵循著類似的軌跡：

1. 手動編排：直接呼叫模型 API，手動解析回應、管理狀態、編寫工具呼叫的控制流。
2. 框架輔助：使用 LangChain/LlamaIndex 等框架，簡化 ReAct 循環的 boilerplate code，但仍需自行部署與管理整個應用程式。
3. 託管服務：使用 Bedrock AgentCore 的 Managed Harness，開發者只需提供「配置」，執行環境與控制邏輯完全由雲端平台負責。

這正是「無伺服器」的核心精神：將非差異化的基礎設施與運行環境（在這裡是 Agent 的控制流程）交給平台，讓開發者能更專注於創造獨特價值的核心業務邏輯（在這裡是 Agent 的能力與目標）。當然，如同無伺服器架構犧牲了部分底層控制權來換取便利性，Managed Agent Harness 也可能在客製化與除錯的靈活性上有所取捨。但對於絕大多數標準應用場景，這種抽象化無疑是巨大的生產力解放。

當基礎的技術門檻被夷平，競爭的維度就會向上提升。過去的優勢在於誰能更快、更穩定地寫出 Agent 循環，未來的優勢則在於誰能設計出更智慧、更可靠的 Agent 系統。

當控制流程被託管，AI Agent 的真正戰場在哪裡？

當編寫 Agent 控制流的苦工不再是核心挑戰時，我們應該將精力投向何處？我認為，真正的差異化將體現在系統設計的精緻度與系統治理的成熟度。這也是 Andrew Ng 提出的 Agentic Design Pattern 思想的延伸，即從單純的提示工程轉向更宏觀的系統架構思維。

如何精進 AI Agent 的系統設計？

在系統設計層面，關鍵在於：

• 工具的品質：你提供給 Agent 的 API 是否功能強大、穩定可靠、文檔清晰（好的 OpenAPI schema 就是最好的文檔）？一個設計精良的 API，遠比數百個提示詞技巧更能提升 Agent 的表現。
• 知識庫的建構：如果 Agent 需要使用 RAG（檢索增強生成），知識庫的品質、切分策略、與檢索演算法的選擇，將直接決定 Agent 資訊來源的準確性。
• 狀態管理的一致性：對於需要執行多步驟任務的 Agent，如何跨越多次呼叫來管理與傳遞狀態，將是系統穩健性的核心。

如何建立 AI Agent 的系統治理能力？

在系統治理層面，挑戰則更為複雜：

• 可觀測性 (Observability)：如何監控 Agent 的內部決策鏈（Chain of Thought）？如何追蹤工具的呼叫成功率與延遲？當 Agent 行為不符預期時，你是否有足夠的日誌與追蹤數據來快速定位問題？
• 版本控制：提示詞、模型版本、工具 schema 都應該像程式碼一樣被納入版本控制。一個微小的提示詞改動，都可能導致 Agent 行為的巨大變化。
• 安全與成本控管：如何防止 Agent 被惡意利用，執行破壞性操作？如何設定預算警報，避免 Agent 因陷入錯誤循環而產生天價的 API 帳單？
• 評估與測試：建立一套可靠的自動化評估基準（evaluation benchmark），例如使用 AgentBench 這類框架，對於確保 Agent 在迭代過程中的品質至關重要。

總結來說，AWS Bedrock AgentCore 的新方向，是 AI Agent 開發從「手工業」邁向「工業化」的重要一步。它將開發者的角色，從一個埋首於控制流細節的「程式設計師」，提升到一個著眼於整體架構、工具生態與治理框架的「系統架構師」。在這個新範式下，寫程式碼的技能依然重要，但設計一個穩健、可擴展、可治理的 AI 系統的能力，將成為更稀缺、也更有價值的核心競爭力。

延伸閱讀

• Amazon Bedrock Agents 使用者指南
• AWS 關於基礎設施即程式碼 (IaC) 的定義

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。