# 課程主題：Context Engineering 是什麼

* 近期熱門詞，實質與 Prompt Engineering 指涉同一概念：優化語言模型的輸入
* 重點從「格式與咒語」轉向「自動化管理輸入的內容與脈絡」
* 在 AI Agent 時代，是讓 Agent 穩定運作的關鍵技術

# 語言模型觀點：f(x) 與可改變之處

* 語言模型可視為函式 f，輸入 x，輸出 f(x)
* 想改善輸出有兩條路：改 f（訓練/學習）或改 x（改善輸入）
* 多數情境無法改 f（閉源、成本高），實務聚焦在改 x

# Context Engineering 與 Prompt Engineering 的差異

* 本質相同：都在「把輸入弄好」
* 焦點不同：Prompt Engineering 常強調輸入格式與指令寫法；Context Engineering 強調管理「輸入的脈絡與資料」
* 名稱更新帶來觀念轉移，而非能力飛躍

# 神奇咒語的歷史與退潮

* 早期模型（如 GPT-3）不穩定，以格式/關鍵詞觸發長輸出或更好行為（如「位置」）
* 常見咒語：一步一步思考、確認答案正確、先深呼吸、情緒勒索/小費誘因等

* 模型進步後效益下降：2023/06 對數學題從 72%→88%；2024/02 無咒語已 85%，加咒語僅到 89%
* 合理趨勢：模型應「本來就盡力」，不應靠咒語啟動思考

# 為何在 AI Agent 時代特別需要

* Agent 需穩定、可重現地獲取正確資訊並決策
* 透過自動化方式讓模型「自己管理自己的輸入」
* 目標是流程化與系統化，而非手工調咒語

# Context 應包含的內容

* 使用者任務與指令（要做什麼）
* 具體操作指引（步驟、格式、長度限制、語氣要求）
* 必要前提與情境（domain、場景、對象）
* 評估/成功條件（正確性、覆蓋度、約束）
* 可用資料與例子（範例輸入輸出、參考資訊）

# 例子：加入情境可消歧

* 問「載具是什麼？」無脈絡會得到多義答案（交通工具、電子票證載具等）
* 加上情境「在超商結帳時」→ 正確解為電子發票的儲存工具
* 關鍵：模型不會讀心，前提需明講

# 關於論文與 arXiv 的補充（簡要）

* arXiv 是快速公開研究成果的平台，鏈接中的數字可見上傳年月（如 2206 代表 2022/06）
* 早期工作（無 ChatGPT 前）多展示「咒語」對行為的影響，作為歷史背景

# 本堂課的綱要與範圍

* 釐清 Context 應包含哪些資訊
* 說明為何 AI Agent 時代需要 Context Engineering
* 介紹 Context Engineering 的基本操作（以管理輸入為核心）
* 不涵蓋模型訓練；重點在「訓練人」而非「訓練模型」

---
# 情境影響輸出：曼谷運河動物案例

* 同一張照片，在不同情境下模型會得出不同結論
* 未提供地點時，模型判斷為鱷魚；加上「曼谷」後改判為水巨蜥
* 顯示「情境資訊」能顯著改變模型輸出結果
* 提供背景（地點、時間、任務）可讓模型給出更合理的答案

# 範例在 Context 中的作用

* 給模型明確範例可顯著提升準確度
* 火星文例子：單純指令下模型自行定義「火星文」；加入範例後才正確理解需以注音替換
* 範例讓模型建立任務概念，而非僅靠文字描述

# GPT-3 時代的 In-Context Learning

* GPT-3 論文指出：給模型範例可使其在不改變參數的情況下完成新任務
* 模型透過「輸入中的例子」理解任務模式
* 稱為 In-Context Learning，「Learning」加引號因其非真正學習（參數不變）

# Gemini 1.5 的 In-Context Learning 案例

* 測試極稀少語言「卡拉蒙語 (Kalamang)」翻譯
* 模型原本無法翻譯，加入教科書與字典內容後即可進行翻譯
* 關鍵在於教科書中的例句，而非文法解釋
* 顯示長 Context 可使模型在輸入階段「臨時學會」新語言
* 強調模型未改變參數，Context 移除後能力即消失

# System Prompt 的角色

* System Prompt 由模型開發者設定，提供每次互動必備資訊
* Claude 3 Opus System Prompt 約 2500 字，包含：

* 模型身份（名稱、公司、日期）
* 使用說明與限制（禁止事項、互動規範）
* 回應風格（避免「Good Question」、知識截止時間、身份設定）
* 錯誤應對策略（不要輕易承認錯誤）
* System Prompt 是模型行為一致性的基礎

# 對話歷史（短期記憶）

* 模型利用當前對話歷史接續文字生成
* 例如教它「隔壁老王＝法老王」，在同一對話中能記住
* 關閉對話或開新對話後記憶消失
* 對話歷史僅影響當前 session，不改變模型參數

# 長期記憶的引入（ChatGPT）

* 2024 年 9 月後 ChatGPT 新增長期記憶功能
* 可在「自訂 ChatGPT」中開啟記憶選項
* 長期記憶基於使用者過往互動形成，嵌入於每次輸入前
* 用戶可透過「我是什麼樣的人」測試記憶內容
* 長期記憶不可見，但影響模型對使用者的理解與回應

---
# 為何需要額外資訊來源

* 語言模型的知識有限且可能過時
* 需結合外部資料（如網路搜尋或內部資料庫）以補足資訊缺口
* 典型做法是先搜尋，再將結果與使用者的 Prompt 一起餵入模型

# RAG（Retrieval-Augmented Generation）

* RAG 是結合檢索與生成的技術
* 流程：搜尋 → 取回相關文件 → 與 Prompt 合併 → 模型生成回答
* ChatGPT 已可直接在對話介面中搭配搜尋引擎使用
* 但仍要注意：搜尋結果可能錯誤，模型仍是「文字接龍」

# RAG 錯誤案例：Google AI Overview

* 有人詢問「起司黏不在披薩上怎麼辦？」
* AI Overview 建議「加入 1/8 無毒膠水」
* 原因：模型引用 Reddit 玩笑貼文，誤當真
* 顯示語言模型即使有搜尋仍可能產生錯誤與幻覺（hallucination）

# 搜尋輔助的效益與限制

* 搜尋能讓模型獲取正確或最新資訊（如課程官網）
* 無搜尋時模型常提供錯誤網址或資訊
* 但搜尋不保證正確性，模型仍可能誤讀來源內容

# 模型使用工具的能力

* 搜尋引擎是一種工具，現今模型還能結合更多工具
* 各大模型（Claude、Gemini、GPT）皆支援工具調用
* 搜尋 Gmail
* 讀取 Google Calendar
* Gemini 甚至可直接修改日曆內容

# 讓模型學會使用工具的方法

* 在 Context 中說明「如何使用工具」
* 可用自然語言描述操作方式，模型能理解
* 工具指令放在「<tool>」與「</tool>」間
* 工具輸出放在「<output>」與「</output>」間
* 範例工具：`temperature(城市, 時間)` 取得氣溫

# 模型輸出與真實執行的差異

* 模型輸出工具指令僅為「文字」
* 不會自動執行實際程式
* 需自行撰寫外部程式（例如用 `eval()`）將指令轉為真實動作
* 執行後再將工具輸出回饋給模型

# Colab 實作示範概要

* 下載並使用 Hugging Face 模型（Gemma 2 9B）
* 建立兩個工具：`multiply(a, b)`、`divide(a, b)`
* 模型僅能輸出文字如 `multiply(3, 4)`，需 `eval()` 執行才會運算
* 模型初步運算僅靠「心算」模擬結果（未真正使用工具）

# 真正呼叫工具的流程

* 從模型輸出中擷取工具指令（在標記符號間）
* 將指令丟給 `eval()` 執行並取得輸出
* 將工具指令與輸出回寫到模型的 Context
* 模型根據新 Context 繼續生成內容
* 若再次產生新工具請求，重複流程
* 當輸出不再出現工具請求時，即為最終回答

# 工具輸出與最終回答分離

* 工具使用過程可隱藏於系統內，不需顯示給使用者
* 使用者僅看到模型的最終答案
* 實際上結果來自工具回傳的資訊，而非模型本身的知識

---
# 工具使用流程

* 準備 system／tools prompt 與使用者輸入，組成 messages（符合 Gemma 格式）
* 進入 while 迴圈，每輪把 messages 丟給 pipeline 取得 response
* 若 response 含工具指令，擷取 \ 與 \ 之間的命令並忽略其他文字
* 在 Python 以 eval 執行命令，將結果轉成字串存入變數，並把工具輸出與使用紀錄寫回 messages
* 若無工具相關符號，直接將模型輸出作為最終答案

# 範例：數學運算工具

* 呼叫 multiply 計算 111×222
* 再呼叫 divide 計算 24642÷777，得到 31.714
* 最終對使用者顯示「111 乘以 222 除以 777 等於 31.714」
* 工具呼叫過程可對使用者隱藏

# 範例：溫度工具與可靠性

* 假工具 get_temperature：輸入城市與時間，回傳固定的「攝氏 30 度」
* 問「高雄 1 月 11 號的天氣」→ 工具回傳 30 度，模型即據此回答
* 若工具回傳荒謬數值，模型有機會質疑結果並提示輸入可能有誤

# 模型決定是否用工具

* 任務需外部資料或計算（數學、天氣）時傾向用工具
* 一般寒暄（如「你好嗎？」）不會呼叫工具

# Computer Use（直接操控電腦）

* 模型可用「螢幕畫面＋工具集合（鍵盤輸入、滑鼠移動／點擊）」執行任務
* 能力接近人類操作電腦，可完成網站操作、表單填寫等
* 並非所有模型都勝任，需支援度較高的模型與介面

# ChatGPT 代理人模式示例：訂高鐵票

* 任務：9/20 09:00–10:00 台北→左營，兩張票
* 流程：開啟雲端螢幕→搜尋台灣高鐵→選起訖站→設定張數→選日期→輸入時間→遇到驗證碼停止
* 現況：操作可能失誤（點選不準、驗證碼無法處理），但展示了自動化潛力

# Computer Use 的操作原理

* 將螢幕截圖與可用動作（鍵盤、滑鼠座標、左右鍵）作為工具提供給模型
* 模型逐步規劃下一步行為並輸出具體座標與操作
* 實驗：定位搜尋欄座標→點擊→輸入關鍵字→按 Enter，完成頻道搜尋

# 深度思考（Reasoning／腦內小劇場）

* 模型先在內部嘗試多種解法、規劃步驟與驗證，再產生答案
* 使用者通常只看到摘要，不見完整思考過程
* 代表模型會自產 context（推理痕跡）並用於產生最終輸出

# Context 的組成

* 包含：User Prompt、System Prompt、對話歷史、長期記憶、搜尋結果、工具結果、推理結果
* 目標：避免塞爆 context，只放必要資訊

# Agentic Workflow 與 AI Agent

* Workflow：把任務拆成 SOP 多步驟（驗證輸入→評分→檢查合理性），提升穩定性
* AI Agent：模型自行規劃與調整步驟，循環進行蒐集資料、形成假設、寫程式實驗、驗證結論
* 適用於無法事先完全預期步驟的複雜任務

---
# AI Agent 的循環

* 人類先給目標（Goal）
* 模型基於當前輸入形成 Observation
* 依 Observation 採取行動（呼叫工具、寫程式、產出報告、與人互動）
* 環境（人、工具）回饋輸出導致新 Observation
* 不斷以「Observation → Action → 新 Observation」循環運作

# 與傳統 Agent 的差異

* 輸出空間幾乎無限（自然語言可表達任意行為），非預先離散化的動作集合
* 可用人類語言下指令與提供回饋，互動門檻低
* 例：AlphaGo 僅能在棋盤上落子；語言模型可接受文字需求並產生多樣行為

# 免費體驗範例：Gemini CLI

* 可直接操作本機電腦，具高風險（可刪檔、關程式），與雲端隔離的 Agent Mode 不同
* 會在執行前詢問許可，可批量「Allow」
* 多步驟完成任務：建立資料夾、生成 index.html／style.css／script.js、打開檔案
* 能依使用者回饋迭代修改（如降低遊戲速度）
* 可嘗試開關投影片等系統操作，但成功率受環境與上下文影響

# 本質仍是文字接龍

* 系統提示與初始 Observation 決定第一個 Action
* Action 影響環境產生新 Observation，進而產生下一步 Action
* 整體行為是「依序條件化的文字續寫」，與對話生成本質一致

# 長時運行的挑戰：Context Window

* 模型宣稱可處理極長輸入（數十萬至百萬 token），以容納歷史與資料
* 「能輸入」不等於「能讀懂」；輸入過長時模型易混亂、表現劣化
* 實務需抑制無用內容，避免超限導致錯誤或漂移

# 過長 Context 的負面效應

* RAG 資料量與正確率呈先升後降：過多檢索內容使模型「讀不動」
* 「Lost in the middle」現象：開頭與結尾資訊較易被利用，中段資訊易被忽略
* 即使尚未達到長度上限，表現也可能因資訊堆疊而下降

# 互動方式對表現的影響

* 一次給完整需求優於「擠牙膏式」逐步追加
* 多輪增量指示會降低正確率並提高不穩定性（Capability 下降、Unreliability 上升）

---
# Context Rot 與長上下文失效

* 「Context Rot」指出「可輸入很長 ≠ 真能讀懂」，長上下文常使模型在細節上失準
* 實驗：要求模型精確複製長字串（如多次出現 Apple/Apples），輸入一長就大量出錯
* 多家宣稱大視窗的模型（Gemini、Qwen、GPT-4 Turbo、Claude）在約 10^4 tokens 即顯著退化
* 結論：上下文越長越易混亂，不能盲目增長

# Context Engineering 核心

* 只把「需要的內容」放進 context
* 把「不需要的內容」清出 context，保持潔淨
* 實務上常用模型本身協助挑選與清理

# 招數一：選擇（Retrieval 與篩選）

* 以 RAG 只檢索與任務高度相關的資料再送進 context


* 利用模型把使用者任務轉成搜尋關鍵字，再去查找資料
* Reranking：用小模型過濾搜尋結果，只留最相關的文檔進 context


* 句級檢索（如 Provence 思路）：小模型逐句判斷相關性，進一步縮短輸入


* 工具版 RAG：把「工具說明」當文件，僅檢索需要的工具說明放入系統提示
* 過多工具會劣化行為；少而精的工具集合表現更穩定（早期 Plugin 僅允許選少數）


* 記憶選擇：把龐雜歷史存外部，按需用 RAG 取回，而非全塞進 context

# 記憶選擇的實作範例

* 史丹佛小鎮（Smallville）式記憶：將代理的瑣碎經驗存檔外部，詢問或決策時再檢索
* 記憶評分三指標：最近性、重要性、與當前問題的關聯性；只將高分者放入 context
* 好處：避免大量無用細節擠爆 context，同時保留關鍵脈絡

# 從互動歷史中挑範例（SpringBench）

* 任務連續進行，每題回饋對/錯；期望模型用過往經驗提升答對率
* 不能把全部歷史放入 context，改以 RAG 選最相關的過往題目作為範例
* 動態挑選範例優於固定範例；僅加入「過去答對」的記憶表現最佳
* 純放「過去答錯」的記憶常有傷害；如何安全利用負例仍是開放問題

# 招數二：壓縮（Summarization/Compression）

* 當互動累積超過視窗，就把久遠歷史做摘要，留下關鍵要點作長期記憶
* 觸發策略可為：每 N 回合壓一次、視窗使用率達門檻即壓、固定時間間隔壓
* 遞迴式壓縮：多輪互動後將新舊摘要再合併重壓，遠古細節逐步淡出
* 直覺理由：大量互動細節本就冗餘，壓縮能去除噪音、保留決策所需訊息

# 壓縮在「電腦操作」場景特別必要

* 電腦操作含大量低價值事件（滑鼠移動、關廣告、右鍵等）
* 對未來推理只需保留任務結果與關鍵狀態，微步驟應被摘要掉
* 節省視窗又維持可用脈絡

# 外部長期儲存 + RAG 回讀

* 未放入 context 的原始歷史可存硬碟或資料庫，必要時以 RAG 讀回
* 若擔心 RAG 漏檢，可在摘要中留「指向原始檔」的明確線索，需細節時再展開
* 原始庫近乎無限，但視窗有限；以摘要做門面、原文做備援

# 關於模型記憶的觀察與猜測

* 有「永久筆記」式顯式記憶與「會衰退」的隱性短期記憶兩路並存的可能
* 隱性記憶對近事較敏感、久遠會淡化；類似遞迴壓縮後的保留
* 指令要求「忘記」有時有效、有時殘留，顯示內部記憶機制非單一路徑

# 招數三：Multi-Agent（提要）

* 多代理協作常結合「選擇 + 壓縮」：檢索/評審代理負責挑選，摘要代理負責壓縮
* 依任務把工作流拆解給不同專長的小模型/代理，減少單一大上下文的負擔

---
# Multi-Agent 的概念

* Multi-Agent 系統中有多個 AI agent，各自扮演不同角色（如 CEO、CTO、Programmer、Reviewer、Tester）
* 每個 agent 各司其職，處理特定任務，組成類似公司協作的架構
* 除了專長分工外，從 context engineering 角度看，multi-agent 是有效管理上下文的手段

# 單一 Agent 的問題

* 單一 agent 需處理所有任務，context window 容易被資訊塞滿
* 例如組織出遊時，同一 agent 同時負責規劃、訂餐廳、訂旅館，context 很快爆滿
* 過多互動資訊（特別是 computer use 的細節）使模型難以維持效能

# Multi-Agent 的 Context 分離效益

* 領導 agent 僅記錄任務結果（如「餐廳訂好了」），不保留細節
* 各執行 agent（如訂餐廳、訂旅館）各自擁有獨立 context，互不干擾
* 有效縮短每個 agent 的上下文長度，減少混亂，提高任務執行效率
* 即使 agent 沒有不同專長，分開任務仍能降低 context 複雜度

# 實例：撰寫 Overview Paper 的分工

* Overview paper 涉及上百篇論文，單一 agent 無法一次處理
* Multi-agent 可讓每個 agent 讀一篇論文、生成摘要，再交由總整 agent 整合撰寫
* 各 agent context 彼此獨立，避免超出視窗限制
* 類似人類社會的團隊合作與分工模式

# LangChain 實驗結果

* 比較 single-agent 與 multi-agent 在不同任務難度下的表現
* 任務簡單時，single-agent 可能較佳（因資訊集中）
* 任務複雜時，multi-agent 優勢明顯（分散負擔、context 獨立）
* 缺點：多 agent 間可能缺乏全局資訊（如餐廳與旅館距離太遠）
* 結論：multi-agent 在高複雜任務中表現更佳，context 管理更有效

---
# Terminology
* 情境工程（Context Engineering）：以自動化與結構化方式管理模型輸入以提升輸出品質。
* 提示工程（Prompt Engineering）：設計與改寫提示以誘導模型產出期望結果的實務。
* 上下文（Context）：模型在生成時可見的所有訊息集合（指令、例子、記憶、檔案等）。
* 系統提示（System Prompt）：平台預置的高優先序規範，用於設定身份、能力與限制。
* 使用者提示（User Prompt）：由使用者提供的任務描述、需求與條件。
* 助手訊息（Assistant Message）：模型先前的回覆，用於維持多輪語境。
* 對話樣板（Chat Template）：以角色/分隔符格式化對話以提高可預測性的模板。
* 角色標記（Role Tag）：標示system/user/assistant等說話者的標籤。
* 標頭標記（Header Tokens/IDs）：在樣板中界定段落與角色的特殊符號。
* 上下文視窗（Context Window）：一次可供模型處理的最大token長度。
* 記憶（Memory）：跨輪或跨會話保存資訊以供後續對話使用的機制。
* 長期記憶（Long-term Memory）：可在多個會話間持久化並被隱式注入的資料。
* 工作記憶（Working Memory）：當前回合可見的短期對話與中間結果。
* 會話歷程（Conversation History）：先前輪次訊息的序列，用於維持連貫性。
* 內嵌資料（Inline Context）：直接放入提示中的背景、規則與範例。
* 工具呼叫（Tool/Function Calling）：以結構化輸出觸發外部函式與API的能力。
* 代理人（AI Agent）：具目標、能規劃並迭代調用工具與記憶的自主系統。
* 任務規劃（Task Planning）：將高層目標分解為步驟並決定執行順序。
* 目標分解（Goal Decomposition）：把複雜任務拆成可執行子任務的過程。
* 狀態機（State Machine）：以狀態與轉移規則管理代理人流程的結構。
* 規則引擎（Rules Engine）：以可維護規則集約束與引導模型行為。
* 提示路由（Prompt Routing）：依任務自動選擇合適模型/模板/工具的策略。
* 提示組合（Prompt Composition）：將多段指令、資料與範例組裝成完整上下文。
* 提示鏈（Prompt Chaining）：把多步提示串接，逐步逼近最終答案。
* 思維鏈（Chain-of-Thought）：要求顯式中間推理步驟以提升複雜任務表現。
* 自我反思（Self-Reflection）：模型對自身輸出進行評估與修正的迭代機制。
* 自我一致性（Self-Consistency）：以多條推理路徑投票提高穩定性的技巧。
* 檢索增強生成（Retrieval-Augmented Generation, RAG）：先檢索外部知識再引導生成以降幻覺。
* 向量檢索（Vector Search）：以嵌入相似度從知識庫取回相關片段。
* 文件分塊（Document Chunking）：將長文切塊以便索引與精準注入上下文。
* 嵌入向量（Embedding）：將文本/多模態資料映射為連續向量的表示。
* 程式化提示（Programmatic Prompting）：以程式自動生成與維護提示內容。
* 少樣本提示（Few-shot Prompting）：提供少量示例引導模型學習任務格式。
* 零樣本提示（Zero-shot Prompting）：僅以說明與約束完成任務而不給示例。
* 內文學習（In-Context Learning, ICL）：僅藉由上下文示例調整輸出而不改參數。
* 示範樣例（Demonstrations）：放入上下文的輸入—輸出範例對。
* 場景設定（Situation Framing）：提供地點/時間/身分等前提以消歧義。
* 不變要求（Non-negotiable Constraints）：必須嚴格遵循的規則與限制。
* 輸出格式規範（Output Schema）：要求輸出遵循的結構（如JSON/Markdown欄位）。
* 驗證步驟（Verification Step）：以規則/工具對中間或最終輸出做校驗。
* 事實性檢查（Fact-checking）：用檢索或外部資料核對模型敘述真偽。
* 幻覺抑制（Hallucination Mitigation）：降低無根據生成內容的技術與流程。
* 安全護欄（Safety Guardrails）：預防違規、有害或敏感輸出的策略集合。
* 停止條件（Stopping Criteria）：控制生成在特定符號或長度達標時結束。
* 指令層級（Instruction Hierarchy）：系統/開發者/使用者指令的優先序。
* 代理記憶體（Agent Memory Store）：代理人用於讀寫長短期記憶的資料層。
* 會話開場白（Conversation Primer）：啟動對話時預置的風格與任務設定段。
* 系統地雷詞（Banned/Sensitive Terms）：在系統層明確禁止的詞彙或主題。
* 提示評測（Prompt Evaluation）：以離線/線上指標衡量提示方案效果。
* 提示版本控制（Prompt Versioning）：對提示變更做版本化與回溯管理。
* 自動化管線（Orchestration Pipeline）：協調檢索、工具與生成步驟的工作流。
* 上下文預算（Context Budget）：在視窗限制下分配各類資訊的token配額。
* 觀察（Observation）：代理從環境或使用者取得的當前資訊快照。
* 行動（Action）：代理根據觀察產生並執行的操作（輸出、工具調用、程式等）。
* 環境（Environment）：代理之外的世界，含人類、工具、檔案與服務等。
* 目標（Goal）：代理需達成的任務描述或成功條件。
* 感知－行動循環（Perception-Action Loop）：觀察→決策→行動→新觀察的反覆流程。
* 代理迴圈（Agent Loop）：在目標未達成前持續規劃、執行與更新狀態的主流程。
* 工具調用（Tool Invocation）：以結構化參數呼叫外部函式或API取得結果。
* 程式合成（Program Synthesis）：代理自動產生並執行程式碼以完成子任務。
* 回饋（Feedback）：來自人類或系統的評語、分數或糾正，用於調整後續行為。
* 任務規劃（Task Planning）：將目標拆為可執行步驟並排序。
* 計畫執行監控（Plan Execution Monitoring）：在執行中追蹤進度與偏差並觸發修正。
* 動態重規劃（Dynamic Replanning）：根據新觀察或失敗即時更新計畫。
* 人在迴圈（Human-in-the-Loop, HITL）：關鍵步驟引入人類審核/決策以提升可靠性。
* 代理自治性（Agent Autonomy）：代理在有限規則下獨立決策與行動的能力。
* 代理政策（Agent Policy）：從狀態映射到行動的決策函式或策略。
* 狀態表示（State Representation）：抽取對決策最有用的結構化內部狀態。
* 世界模型（World Model）：代理對環境動態與因果的內隱近似。
* 報酬函數（Reward Function）：用於評價行動品質與任務達成度的標準。
* 任務分解（Task Decomposition）：把複雜目標拆成可管理的子目標與里程碑。
* 子目標生成（Subgoal Generation）：自動提出中介目標以縮短規劃跨度。
* 工具選擇（Tool Selection）：基於查詢與上下文挑選最適合的工具。
* 函式呼叫（Function Calling）：以結構化schema觸發特定函式並接收返回。
* 電腦操作（Computer Use）：代理以滑鼠/鍵盤控制沙箱電腦完成多步任務。
* 命令執行安全（Command Execution Safety）：限制可執行操作以避免破壞性行為。
* 權限升級防護（Privilege Escalation Guarding）：防止代理取得超出授權的系統權限。
* 會話記憶（Conversation Memory）：對話歷史與關鍵事實的短期存取。
* 長上下文視窗（Long Context Window）：模型一次可處理的Token上限。
* 上下文飽和（Context Saturation）：輸入超載導致理解與推理品質下降。
* 中段遺失效應（Lost in the Middle）：長輸入中部資訊被忽視、召回率偏低的現象。
* 上下文路由（Context Routing）：根據查詢動態挑選應注入的來源與片段。
* 片段擷取（Snippet Extraction）：從文件中切取最相關的短片段注入提示。
* 檢索增強生成（Retrieval-Augmented Generation, RAG）：先檢索再生成以降低幻覺。
* 文檔重排序（Re-ranking）：以較強模型對初檢結果重新打分排序。
* 來源對齊（Source Grounding）：回答中對齊可驗證的引用與出處。
* 幻覺偵測（Hallucination Detection）：檢測無依據或捏造內容的機制。
* 可信度評分（Confidence Scoring）：對答案或步驟產生置信指標供決策。
* 代理可靠性（Agent Reliability）：在多回合長任務中維持穩定正確的能力。
* 能力度量（Capability Metrics）：以任務完成度、正確率、覆蓋率等衡量表現。
* 失效模式（Failure Modes）：常見錯誤型態如卡死、循環、策略漂移。
* 回退策略（Fallback Strategy）：失敗時切換模型/工具/流程的預案。
* 連貫性維持（Coherence Maintenance）：跨回合保持語氣、一致性與計畫對齊。
* 會話狀態同步（Session State Sync）：在多工具/多執行緒間共享與更新狀態。
* 互動成本（Interaction Cost）：人機回合、API次數與人工審核帶來的資源開銷。
* 延遲預算（Latency Budget）：任務可容忍的端到端時間上限與分配。
* 代幣成本控制（Token Cost Control）：在視窗與費用限制下分配上下文配額。
* 執行追蹤日誌（Execution Trace Logging）：詳細記錄每次檢索、呼叫與決策以便除錯。
* 可重現性（Reproducibility）：在相同輸入與設定下穩定重現行為。
* 評測基準（Benchmarking）：用標準資料集與協議系統化比較方法。
* Gemini CLI（Gemini CLI）：可本機執行、具檔案/系統操作能力的命令列代理介面。
* 安全確認對話（Safety Confirmation Prompting）：對高風險操作先徵求明確人類同意。
* 上下文腐爛（Context Rot）：長輸入下模型對中段資訊急遽失真與遺漏的現象。
* 長上下文退化（Long-Context Degradation）：輸入變長時複述與推理正確率下降。
* 複製測試（Copying Task）：要求模型逐字複述長字串以量測長程保真度。
* 代幣預算（Token Budget）：在視窗與成本限制下可用的上下文配額。
* 上下文視窗（Context Window）：模型一次可處理的最大Token長度。
* 注意力稀釋（Attention Dilution）：序列過長導致關鍵訊號被平均沖淡。
* 首尾偏置（Primacy/Recency Bias）：模型更易記住開頭與結尾、忽略中段。
* 中段遺失效應（Lost in the Middle）：長輸入中央資訊被忽視的普遍現象。
* 上下文管理（Context Management）：選擇、組織與裁剪輸入以維持可用性。
* 上下文工程（Context Engineering）：用系統化策略打造高效可控的提示。
* 選擇策略（Selection）：只挑最相關片段注入，避免塞爆上下文。
* 壓縮策略（Compression）：以摘要/改寫降低歷史與文件的字元長度。
* 多代理架構（Multi-Agent Architecture）：以多個協作代理分攤任務與上下文。
* 檢索增強生成（Retrieval-Augmented Generation, RAG）：先檢索再生成以對齊事實。
* 查詢生成（Query Generation）：把任務轉為可檢索的關鍵字與查詢式。
* 關鍵字抽取（Keyword Extraction）：自動萃取高訊息量詞以驅動搜尋。
* 重排序（Re-ranking）：以更強模型對初檢結果重新打分排序。
* 句級選擇（Sentence-Level Selection）：在文內逐句判斷與任務之相關性。
* 工具檢索（Tool Retrieval）：對工具說明做索引，按需求只注入必要工具。
* 工具過載（Tool Overload）：同時暴露太多工具導致決策與閱讀失效。
* 記憶檢索（Memory RAG）：將長期記憶外部化，按需搜尋回填上下文。
* 情節記憶（Episodic Memory）：時間序列的互動與事件片段存取。
* 語義記憶（Semantic Memory）：跨情境可泛化的事實與概念庫。
* 近因加權（Recency Weighting）：對較新的記憶與觀察給更高權重。
* 重要度評分（Importance Scoring）：以代理自評衡量記憶存留優先度。
* 相關度評分（Relevance Scoring）：與當前任務的語義匹配分數。
* 記憶鞏固（Memory Consolidation）：將多回合歷史壓縮為長期摘要。
* 摘要壓縮（Summarization Compression）：以抽取/生成方式濃縮內容。
* 遞迴式摘要（Recursive Summarization）：多層級連續壓縮長期歷史。
* 滑動窗摘要（Sliding-Window Summaries）：按視窗滾動產生分段摘要。
* 檢查點摘要（Checkpointed Summaries）：在關鍵里程碑保存精煉狀態。
* 電腦操作（Computer Use）：以滑鼠/鍵盤在沙箱環境多步完成任務。
* 互動日誌（Interaction Logging）：完整記錄檢索、調用、決策與結果。
* 幻覺過濾（Hallucination Filtering）：檢測與抑制無依據或錯誤生成。
* 事實對齊（Grounding）：回答需引用可驗證來源與依據。
* 來源標註（Source Attribution）：精確標記引用片段與出處。
* 安全閘控（Safety Gating）：高風險操作前的人機確認與限制。
* 權限模型（Permission Model）：針對檔案/系統/工具的最小必要授權。
* 沙箱執行（Sandbox Execution）：在隔離環境運行程式與工具。
* 觀察（Observation）：代理感知到的最新環境狀態或輸入。
* 行動（Action）：代理基於觀察做出的工具調用或文字輸出。
* 環境迴圈（Environment Loop）：行動影響環境→產生新觀察的循環。
* 動態重規劃（Dynamic Replanning）：根據新訊息即時更新計畫。
* 計畫-執行-評估（Plan-Execute-Evaluate）：長任務的標準代理流程。
* 負例干擾（Negative Example Interference）：加入錯誤示例反而傷表現。
* 文件分片（Document Sharding）：把大語料分割給不同代理各自處理。
* 代理協調（Agent Orchestration）：調度多代理的任務、資源與訊息流。
* 領導-工人模式（Leader-Worker Pattern）：總召規劃，子代理執行細節。
* 上下文路由（Context Routing）：依查詢動態挑選來源與代理接手。
* 上下文修剪（Context Pruning）：剔除冗餘/低價值內容以維持清爽。
* 代幣成本控制（Token Cost Control）：在品質與費用間做動態配給。