# Google(5-Day AI Agents Intensive) - 前言
## From Predictive AI to Autonomous Agents (從預測式 AI 到自主代理)

人工智慧正從專注於被動、離散任務（如問答或生成圖像）的舊典範，轉向能夠**自主解決問題和執行任務**的新型軟體。

* **AI 代理 (AI Agents)** 是這場典範轉移的核心。
* 代理不僅是靜態工作流程中的 AI 模型，它是一個**完整的應用程式**，能夠制定計畫並採取行動以實現目標。
* 它結合了大型語言模型（LM）的**推理能力**與實際的**行動能力**，使其能夠處理單一模型無法應對的複雜、多步驟任務。

## Introduction to AI Agents (AI 代理介紹)

AI 代理被定義為**模型、工具、編排層和運行時服務**的組合，這些要素在迴圈中利用 LM 來完成目標。

| 要素 | 功能定位 | 核心職責與細節 |
| :--- | :--- | :--- |
| **Model (模型)** | **「大腦」** | 核心推理引擎。代理系統是 LM **輸入上下文視窗**的終極策展者。模型的類型決定了代理的認知能力。 |
| **Tools (工具)** | **「雙手」** | 將代理的推理與外部世界連接的機制。包括 API 擴展、程式碼函數和資料儲存庫。代理系統允許 LM 規劃使用哪些工具、執行工具，並將結果放入下一個 LM 調用的輸入上下文視窗。 |
| **The Orchestration Layer (編排層)** | **「神經系統」** | 管理代理運作迴圈的核心流程。處理**規劃、記憶**（狀態）和推理策略的執行。使用如 Chain-of-Thought 或 ReAct 等框架來分解複雜目標。 |
| **Deployment (部署)** | **「軀幹與雙腿」** | 將代理託管在安全、可擴展的伺服器上，並整合生產服務（如監控和日誌記錄），使其成為可靠和可存取的服務。一旦部署，代理可透過圖形介面或 A2A API 供其他代理程式存取。 |

**開發者典範的轉變：**
傳統開發者是「砌磚工」（Bricklayer），精確定義每一個邏輯步驟。代理開發者更像 **「導演」**，設定場景（指令）、選擇演員（工具和 API），並提供必要的上下文（數據），引導這個自主的「演員」來執行任務。

**上下文工程 (Context Engineering)：**
代理的成功在於**上下文視窗的策展藝術**。它是一個永無休止的迴圈：組合上下文、提示模型、觀察結果，然後為下一步重新組合上下文。上下文可能包括系統指令、長期記憶、工具選項及其結果等。

### The Agentic Problem-Solving Process (代理問題解決流程)

代理的核心是實現目標的持續、週期性流程，簡而言之是「帶有工具的 LM 迴圈以完成目標」。這個迴圈可以分解為五個基本步驟：

1. **Get the Mission (接收任務)：** 由使用者（例如：「組織團隊的會議差旅」）或自動化觸發器（例如：「收到高優先級的客戶工單」）發起的高層次目標。
2. **Scan the Scene (掃描場景)：** 編排層感知環境，收集上下文，包括用戶請求、短期記憶、工具可存取的資訊（如日曆、資料庫）。
3. **Think It Through (思考與規劃)：** 代理的核心「思考」迴圈，由推理模型驅動。它分析任務和場景，制定一個計畫（例如：「要預訂差旅，我需要先用 `get_team_roster` 工具，然後檢查 `calendar_api`」）。
4. **Take Action (採取行動)：** 編排層執行計畫中的第一個具體步驟，選擇並調用適當的工具（如調用 API、運行程式碼）。這是代理**在內部推理之外對世界採取行動**。
5. **Observe and Iterate (觀察與迭代)：** 代理觀察行動的結果，將新資訊（如名單）添加到上下文或「記憶」中，然後返回步驟 3，繼續「思考、行動、觀察」迴圈，直到完成初始任務。

**範例：客戶支援代理**
當用戶問：「我的訂單 #12345 在哪裡？」代理不會立刻行動，而是先進入「思考」階段：
* **計畫：** 1. 識別訂單 (使用 `find_order` 工具)。2. 追蹤包裹 (提取追蹤號碼，查詢承運商 API)。3. 報告結果 (綜合資訊)。
* **行動 1：** 執行 `find_order("12345")`，觀察結果：獲得追蹤號碼 "ZYX987"。
* **行動 2：** 執行 `get_shipping_status("ZYX987")`，觀察結果：「正在配送中」。
* **行動 3：** 綜合資訊，生成最終回應。

> **圖示參考：**
> 

> * **Figure 1: Agentic AI problem-solving process (代理 AI 問題解決流程)**
> 

> * **Figure 2: Agentic system in 5 steps (五步驟代理系統)**

## A Taxonomy of Agentic Systems (代理系統分類)

代理系統根據其複雜性可分為不同的等級：

| 等級 | 名稱 | 核心能力和限制 | 範例 |
| :--- | :--- | :--- | :--- |
| **Level 0** | **核心推理系統** | 僅依賴預訓練知識運作，**沒有工具、記憶或即時互動**。對訓練數據之外的即時事件一無所知。 | 能解釋棒球規則，但無法回答「昨晚洋基隊的得分」。 |
| **Level 1** | **連結的問題解決者** | 透過連接**外部工具**成為功能性代理。能夠與世界互動，獲取即時數據或使用 RAG 查詢資料庫。 | 詢問即時股價，或透過 Google Search API 查詢昨晚洋基隊比分。 |
| **Level 2** | **策略性問題解決者** | 從簡單任務擴展到**策略性規劃複雜多步驟目標**。關鍵技能是**上下文工程**：主動策展最相關的資訊用於計畫的每個步驟。 | 規劃尋找辦公室間中途點的好咖啡店，需要先用 Maps 工具，然後用 `google_places` 工具並**自動新增篩選條件** (`min_rating=4.0`)。 |
| **Level 3** | **協作式多代理系統** | 典範轉移：從單一「超級代理」轉向 **「專業團隊」**。代理將其他代理視為工具。 | 「專案經理」代理將「發佈新耳機」任務委派給 `MarketResearchAgent`、`MarketingAgent` 和 `WebDevAgent`。 |
| **Level 4** | **自我演化系統** | 從委派到**自主創造和適應**。系統能識別自身能力差距，並**動態創建**新的工具或代理來填補空白。 | 「專案經理」發現缺乏社交媒體監控能力，主動調用 `AgentCreator` 工具**創建**新的 `SentimentAnalysisAgent`。 |

## Core Agent Architecture: Model, Tools, and Orchestration (核心代理架構：模型、工具和編排)

### Model: The “Brain” of your AI Agent (模型：「大腦」)

模型的選擇是關鍵的架構決策，決定了代理的認知能力、成本和速度。

* **成功的衡量：** 代理在生產環境中的成功不是由通用的學術基準決定的。實務上的成功取決於模型在**導航複雜多步驟問題的推理能力**和**可靠的工具使用能力**上的表現。
* **多模型策略：** 穩健的架構會採用 **「專業團隊」** 模型組合。例如，使用如 Gemini 2.5 Pro 等頂尖模型進行初始規劃，而將高流量、簡單的任務（如分類意圖）路由到更快、成本效益更高的模型（如 Gemini 2.5 Flash）。
* **適應性：** 由於 AI 環境快速演進，開發者必須建立敏捷的 **Agent Ops** 實踐，持續評估新模型，確保代理始終使用最佳「大腦」。

### Tools: The "Hands" of your AI Agent (工具：「雙手」)

工具讓代理能夠超越其靜態訓練數據，擷取即時資訊並在現實世界中採取行動。

1. **Retrieving Information (檢索資訊)：讓代理立足於現實**
* **RAG (檢索增強生成)：** 為代理提供「圖書證」，用於查詢向量資料庫或知識圖譜，極大地**減少幻覺**。
* **NL2SQL (自然語言轉 SQL)：** 用於查詢結構化資料庫，回答分析性問題。
2. **Executing Actions (執行動作)：改變世界**
* 透過將現有 API 和程式碼函數封裝為工具，代理可以發送電子郵件、安排會議或更新客戶記錄。
* 代理可以在安全的沙箱中即時編寫和執行程式碼（如 Python 腳本或 SQL 查詢）。
* **Human in the Loop (HITL) 工具：** 用於在工作流程中暫停，尋求人類的確認 (`ask_for_confirmation()`) 或輸入特定資訊，確保關鍵決策有人參與。
3. **Function Calling (函數調用)：連接工具**
* 代理需要清晰的指令來**可靠地**使用工具。
* **OpenAPI 規範**提供了結構化的合約，描述工具的用途、所需參數和預期回應。
* **Model Context Protocol (MCP)** 等開放標準由於更方便，受到簡單工具發現和連接的歡迎。

### The Orchestration Layer (編排層)

編排層是中央神經系統，負責運行「思考、行動、觀察」迴圈，決定何時推理、使用哪個工具、以及如何利用行動結果來指導下一步行動。

#### Core Design Choices (核心設計選擇)
* **自主程度：** 決定代理是處於「確定性工作流程」（LM 作為工具）還是「LM 驅動的動態規劃」的範圍內。
* **實作方法：** 對於簡單任務，可使用無程式碼建構器；對於複雜系統，應使用程式碼優先框架，如 **Google 的 Agent Development Kit (ADK)**。
* **可觀察性 (Observability)：** 生產級框架必須為可觀察性而設計。當代理行為異常時，無法對模型的「想法」設中斷點，因此需要**詳細的追蹤（traces）和日誌**來揭露其完整的推理軌跡。

#### Instruct with Domain Knowledge and Persona (使用領域知識和角色進行指導)
開發者最強大的手段是透過**系統提示**（代理的「憲法」）來指導代理。這包括設定代理的角色（例如：「你是 Acme Corp 樂於助人的客服代理」）、約束條件、所需的輸出模式、語氣，以及明確指導**何時**和**為何**使用工具。

#### Augment with Context (使用上下文增強記憶)
代理的「記憶」由編排層在運行時組織到 LM 上下文視窗中。

* **Short-term memory (短期記憶)：** 代理的活動「暫存區」，維護當前對話的運行歷史，包括持續的 (行動, 觀察) 配對序列。
* **Long-term memory (長期記憶)：** 跨會話的持久性。通常實作為連接到向量資料庫的 **RAG 系統**（一個專業工具）。這使代理能夠「記住」用戶數週前的偏好或類似任務的結果，以提供個性化體驗。

#### Multi-Agent Systems and Design Patterns (多代理系統與設計模式)
當任務複雜時，應採用 **「專業團隊」** 方法，將複雜流程分割給專業化的 AI 代理。

* **Coordinator pattern (協調者模式)：** 引入一個「管理者」代理，分析複雜請求，然後智能地將子任務路由給不同的專家代理。
* **Sequential pattern (順序模式)：** 線性工作流程，一個代理的輸出作為下一個代理的直接輸入。
* **Iterative Refinement pattern (迭代優化模式)：** 創建一個回饋迴圈，使用「生成器」代理創建內容，並由「批評者」代理根據品質標準進行評估。
* **Human-in-the-Loop (HITL) pattern (人機迴圈模式)：** 在工作流程中設置刻意停頓，以獲得人類的批准，適用於高風險任務。

> **圖示參考：**
> 

> * **Figure 3: The “iterative refinement” pattern (迭代優化模式)**：展示了一個生成器代理如何創建內容，並由一個批評者代理來評估的模式。

## Agent Deployment and Services (代理部署和服務)

代理的部署將其從原型轉變為可靠的服務，需要考慮會話歷史、記憶持久性、安全、隱私和法規遵循。

* **部署選擇：** 可以使用專為代理設計的部署平台（如 **Vertex AI Agent Engine**）或將代理服務容器化（Docker），部署到行業標準運行時（如 Cloud Run 或 GKE）。
* **生產準備：** 建立安全的、生產就緒的環境需要投入時間和最佳實踐，包括 **CI/CD 和自動化測試**。

> **圖示參考：**
> 

> * **Figure 4: Vertex AI Agent builder (Vertex AI 代理構建器)**：展示了一個專門的代理構建平台。

## Agent Ops: A Structured Approach to the Unpredictable (代理營運：應對不可預測性的結構化方法)

**Agent Ops** 是管理代理系統的規範化、結構化方法，它是 **DevOps 和 MLOps 的自然演進**。

> **圖示參考：**
> 

> * **Figure 5: Relationships between the operational domains of DevOps, MLOps, and GenAIOps (DevOps、MLOps 和 GenAIOps 之間的運營領域關係)**：展示了代理營運是針對生成式 AI 系統挑戰的特殊演進。

* **Measure What Matters (衡量重要指標)：** 應將可觀察性視為 A/B 實驗。KPI 應衡量實際業務影響，例如**目標完成率**、**使用者滿意度**、**延遲**和**運營成本**，以計算投資回報率。
* **Quality Instead of Pass/Fail (注重品質而非通過/失敗)：** 由於代理回應是概率性的，傳統的通過/失敗測試不再適用。應轉而使用 **「LM 作為評審（LM as Judge）」**，即使用強大模型根據預定義的標準（例如：是否屬實、是否遵循指令）評估代理的輸出品質。
* **Metrics-Driven Development (指標驅動開發)：** 將新版本代理針對**整個評估數據集**運行，並將分數與現有生產版本進行比較。這是部署的 Go/No-Go 決策依據。
* **Debug with OpenTelemetry Traces (使用 OpenTelemetry 追蹤進行除錯)：** 追蹤是代理執行路徑（軌跡）的**高保真、逐步記錄**。它揭示了發送給模型的確切提示、模型的內部推理、選擇的工具以及返回的原始數據，對於診斷根本原因至關重要。
* **Cherish Human Feedback (珍視人類回饋)：** 人類回饋（例如錯誤報告或「不滿意」點擊）是改進代理的最有價值資源。有效的 Agent Ops 流程會捕捉此類回饋，重現問題，並將其轉換為評估數據集中的**新的永久測試案例**，從而防止同類錯誤再次發生（「關閉迴圈」）。

## Agent Interoperability (代理互操作性)

代理互操作性旨在將代理與人類和其他代理互連，在身體部位比喻中，這可視為代理的「臉」。

### Agents and Humans (代理與人類)
* **UI 互動：** 代理不僅能以文字聊天機器人形式互動，還能提供 **JSON 等結構化數據**，驅動動態的前端體驗。
* **Computer use (電腦使用)：** 一類工具，使 LM 能夠**控制使用者介面**，決定導航到新頁面、突出顯示按鈕或預填表單。
* **動態 UI 協議：** 代理可以改變 UI 以滿足當下需求，透過控制 UI 的工具（如 **MCP UI**、**AG UI**）或生成**客製化介面**（如 **A2UI**）。
* **Live mode (即時模式)：** 透過 **Gemini Live API** 等技術，實現雙向串流，使代理能夠進行**即時、多模態**（語音、視覺）交流，其延遲模仿人類對話，允許使用者打斷。

### Agents and Agents (代理與代理)
隨著企業擴展 AI 使用，需要一個通用標準來連接不同團隊構建的專業代理，以避免客製化 API 整合的混亂。

* **A2A 協議 (Agent2Agent protocol)：** 旨在解決這個問題的開放標準。
* **Agent Card (代理卡)：** 代理透過發布數位「名片」（JSON 文件），宣傳其功能、網路端點和安全憑證，使其他代理易於發現。
* **任務導向架構：** 溝通基於**非同步「任務」**，客戶端代理發送請求，伺服器代理則透過長連接提供串流更新。

### Agents and Money (代理與金錢)
當自主代理進行交易時，會產生信任危機（如果出錯，誰負責？）。

* **AP2 (Agent Payments Protocol)：** 透過引入經**加密簽署的數位「授權書 (mandates)」**，作為使用者意圖的可驗證證明，為每筆交易創建不可否認的審計追蹤。
* **x402：** 一種開放的網際網路支付協議，利用 HTTP 402「需要付款」狀態碼，實現**無摩擦、機器對機器的微支付**。

## Securing a Single Agent: The Trust Trade-Off (單一代理的安全保障：信任的權衡)

授予代理的自主權越多，它帶來的風險（例如，流氓行為或敏感數據洩露）也越大。必須採用混合的、**深度防禦**方法，不能單純依賴 AI 模型的判斷（存在提示注入風險）。

* **第一層：確定性防護欄 (Deterministic Guardrails)：** 在模型推理之外設定**硬編碼的規則**作為安全扼流點，提供可預測的、可審計的硬限制（例如：阻止超過 $100 的購買）。
* **第二層：基於推理的防禦 (Reasoning-based Defenses)：** 使用 AI 來協助保護 AI，例如部署專業的 **「守衛模型」** 來檢查代理擬議的計畫中是否存在風險。

### Agent Identity: A New Class of Principal (代理身份：一類新的主體)
代理是一個自主的行動者，它是一種新的**主體類別**，需要一個可驗證的「數位護照」（例如使用 **SPIFFE** 標準）作為其身份。

* **身份區分：** 代理身份必須**區別於**調用它的使用者和構建它的開發人員。
* **最小權限：** 每個代理被授予其特定的**最小權限**，以限制潛在的爆炸半徑。
* **身份驗證表：** 代理作為一類新的主體，使用 SPIFFE 進行驗證，以代理用戶的委託權限採取行動。

### Policies to Constrain Access (限制存取的策略)
策略（授權 AuthZ）限制了主體的能力。必須對代理、其工具、其他內部代理和上下文應用權限，遵循**最小權限原則**，只授予完成工作所需的最小功能子集。

### Securing an ADK Agent (保障 ADK 代理安全)
[Google ADK](/S-25Aly6STSAeREuDSMENw)
在 ADK 中，安全需要明確定義三種身份：使用者帳戶、服務帳戶和代理身份。

* **工具層防護欄：** 必須將防護欄內建於工具、模型和子代理中，確保無論 LM 如何推理或惡意提示如何建議，**工具的自身邏輯**都會拒絕執行不安全或違反策略的行為。
* **Callbacks (回調) 和 Plugins (插件)：** 提供動態安全檢查的能力。例如，`before_tool_callback` 允許在工具調用前檢查參數。
* **Model Armor：** 一種可選的企業級託管服務，專門用於篩選提示和回應，防範提示注入、敏感數據洩露（PII）等威脅。

> **圖示參考：**
> 

> * **Figure 6: Security and Agents (安全與代理)**：展示了代理安全架構的重點。

## Scaling Up from a Single Agent to an Enterprise Fleet (從單一代理擴展到企業機隊)

當代理和工具在組織中擴散時，會產生「代理擴散 (agent sprawl)」的挑戰。

### Security and Privacy (安全與隱私：強化代理前線)
擴展規模時，代理本身成為新的攻擊向量（例如提示注入、數據中毒）。

* **平台必須提供深度防禦策略：** 確保企業專有數據**絕不被用於訓練基礎模型**。
* 提供輸入和輸出過濾（充當提示和回應的防火牆）。
* 提供合約保護，如**知識產權賠償**，以確保企業在生產環境中部署代理的法律和技術信心。

### Agent Governance: A Control Plane instead of Sprawl (代理治理：控制平面取代擴散)
管理代理擴散需要一個**中央網關**作為所有代理活動的強制入口點，創建控制平面。

* **網關的兩大功能：**
1. **運行時策略執行 (Runtime Policy Enforcement)：** 作為安全性的架構扼流點。處理身份驗證和授權，並提供集中式的可觀察性（日誌、指標和追蹤）。
2. **集中治理 (Centralized Governance)：** 通過**中央註冊表**（類似企業應用商店）提供真實來源。此註冊表允許開發人員發現和重用現有資產，並實現代理和工具的正式生命週期管理（安全審查、版本控制）。

### Cost and Reliability (成本和可靠性：基礎設施基礎)
底層基礎設施必須在可靠性和成本效益之間取得平衡。

* 平台需要提供多種選項，從針對不規則流量的 **Scale-to-zero** 服務，到針對任務關鍵型工作負載的專用、**保證容量**（如 Provisioned Throughput 或 99.9% 的 SLA）。

## How agents evolve and learn (代理如何演化和學習)

由於現實環境不斷變化，代理如果無法適應，其性能會隨著時間推移而**「老化」**。更具擴展性的解決方案是設計能夠**自主學習和演化**的代理。

### How agents learn and self evolve (代理如何學習和自我演化)
代理從經驗和外部訊號中學習：

* **運行時經驗：** 來自會話日誌、追蹤和記憶，尤其包括 **HITL 回饋**，提供了權威性的修正和指導。
* **外部訊號：** 新的外部文件、更新的企業政策或來自其他代理的批評。

這些資訊用於優化代理未來的行為。

* **適應技術：** 包括持續優化提示、少數範例和從記憶中檢索的資訊（**增強上下文工程**）。
* **工具優化與創建：** 識別能力差距並主動獲取或**創建新工具**（Level 4 行為）。

**範例：學習新的合規指南**
在金融等受嚴格監管的行業中，代理需要生成符合隱私和法規（如 GDPR）的報告。
* 一個多代理工作流程包括：查詢代理、報告代理和批評代理。
* **學習代理 (Learning Agent)** 觀察整個互動，特別關注**人類專家的糾正回饋**。
* 學習代理將回饋**概括**為新的、可重用的指南（例如：更新批評代理的規則），從而使系統自主適應不斷變化的合規要求。

> **圖示參考：**
> 

> * **Figure 7: Sample multi agent workflow for compliance guidelines (合規指南的多代理工作流程範例)**：展示了查詢、報告、批評和學習代理如何協同工作以吸收人類專家的回饋。

### Simulation and Agent Gym - the next frontier (模擬和代理體育館——下一個前沿)
**Agent Gym** 是一個專門為**離線流程**設計的進階平台，用於優化多代理系統。

* **核心屬性：**
1. 它**不在執行路徑中**：是一個獨立的非生產平台。
2. 提供**模擬環境**：供代理在新的數據上「鍛鍊」和學習，非常適合「試錯」和優化。
3. 可調用高級的**合成數據生成器**：將模擬引導得盡可能真實，並對代理進行壓力測試（包括紅隊測試）。
4. 可與**人類領域專家**連接：諮詢正確的結果集，以指導下一輪優化。

## Examples of advanced agents (進階代理範例)

### Google Co-Scientist (Google 協同科學家)
Co-Scientist 是一個先進的 AI 代理，旨在作為**虛擬研究協作者**，透過系統地探索複雜問題空間來加速科學發現。

* **設計系統：** 系統充當**研究專案經理**。一個 **Supervisor agent（主管代理）** 將任務委派給一組專業代理，分配計算資源。
* **工作流程：** 代理可以連續工作數小時甚至數天，運行迴圈和元迴圈，不斷改進假設和判斷新想法的方法。

> **圖示參考：**
> 
> * **Figure 8: The AI co-scientist design system (AI 協同科學家設計系統)**。
> 
> * **Figure 9: Co-scientist multi agent workflow (協同科學家多代理工作流程)**。

### AlphaEvolve Agent (AlphaEvolve 代理)
AlphaEvolve 是一個發現和優化數學和電腦科學中複雜問題演算法的 AI 代理系統。

* **核心機制：** 它將 **Gemini 語言模型的創意程式碼生成**與**自動化評估系統**相結合，採用**進化過程**。AI 生成潛在解決方案，評估器評分，最有前途的想法被用於下一代程式碼的靈感。
* **優勢：** 它擅長解決驗證解決方案品質比找到解決方案本身容易得多的問題。
* **人機協作：** AI 生成**人類可讀的程式碼**，允許使用者理解邏輯。人類專家則透過**優化評估指標**來引導探索，確保最終解決方案既強大又實用。

> **圖示參考：**
> 
> * **Figure 10: Alpha Evolve design system (Alpha Evolve 設計系統)**。
> 
> * **Figure 11: Algorithm evolution (演算法演化)**。

## Conclusion (結論)

生成式 AI 代理將 AI 從被動工具轉變為**主動的、自主的合作夥伴**。

* 成功取決於**工程嚴謹性**：包括穩健的工具合約、彈性的錯誤處理、複雜的上下文管理和全面的評估。
* 開發者的角色是成為 **「建築師」**和**「導演」**，指導、約束和除錯這個自主實體。
* 這種有紀律的、架構化的方法是釋放代理 AI 全部力量的決定性因素。

---

## DAY 1 - 掌握核心架構、專家洞察與 ADK 實作
本堂課為 Kaggle Google 5 天 AI 代理密集課程的第一天直播 。由主持人 Kanch Parlola 和 Anand Nalgria 開場，內容涵蓋了課程概覽 、Day 1 白皮書的核心概念 、業界專家的深度 Q&A ，以及 Day 1 程式實作 (Code Labs) 的介紹 。
[DAY 1 - AI 代理 (Agents)](/EGXDPFA_SrC_Hc9j-7kf8A)

---

## DAY 2 - 代理工具與 MCP (Agent Tools & MCP)
Day 2，主題是關於「工具」與「MCP」，這在整個五天課程中是承接第一天「代理架構」之後的核心環節。

[Day 2 - Agent Tools & MCP](/6_I1UKO1T_2kqHnjz2ZmDA)

---

## DAY 3 - 情境工程、會話與記憶 (Context Engineering, Sessions & Memory)
歡迎來到課程的第三天。繼第一天定義了代理 (Agent)，第二天為其提供了工具（手和眼）之後，今天我們將專注於為代理建立「記憶」。本筆記涵蓋了白皮書中關於情境工程、短期會話 (Sessions) 和長期記憶 (Memory) 的核心概念，以及來自 Notebook LM 團隊和 ADK 框架專家的深度解析。
[Day 3 - Context Engineering](/VEOSNs82Rf-NptNqU9jp8Q)

---

## DAY 4 - 代理品質 (Agent Quality)
歡迎來到課程的第四天。在過去的三天裡，我們為代理建立了大腦（模型）、手和眼（工具）以及記憶。但在我們將這個複雜的系統部署到生產環境之前，我們必須回答一個關鍵問題：**我們如何知道它能可靠地運作？**

今天的重點是「代理品質」，這對於本質上「**非確定性**」的軟體（如 AI 代理）尤其重要。本筆記將摘要白皮書的四大品質支柱、程式實驗中的可觀測性與評估，以及專家的深度問答。

[Day 4 - 代理品質 (Agent Quality)](/D24THTyWSAW6P56IXGxQMA)

---

## DAY 5 - 從原型到生產 (Prototype to Production)
歡迎來到 AI 代理密集課程的最後一天。在過去的四天裡，我們設計了代理的大腦、手、眼和記憶，並學會了如何評估它。今天，我們面臨最後的挑戰：**如何將我們的本地原型（Kaggle 程式實驗）轉變為一個安全、可靠的生產級系統**。

[DAY 5 - 從原型到生產 (Prototype to Production)](/1nKQiO5KQvK_EQ7bQthuUg)