AI Agent 工程實戰：
從底層原理到編排、安全與 ROI

討論具體技術之前，可以先用一個穩定的框架來拆解 Agent 系統。任何可執行任務的 Agent，大致都可以分為四層：目標、指令、上下文和底層模型。

• 目標層（Goal）：定義 Agent 最終要交付甚麼。目標越含糊，越容易出現過度執行、任意擴大範圍或走捷徑。好的目標應包含輸出形式、資訊來源、範圍和完成標準，例如「基於公開資料整理三個主要替代方案，輸出不超過 500 字的比較摘要」。
• 指令層（Instruction）：定義怎樣做，以及哪些事不能做。這包括系統提示、任務規則、工具限制和邊界約束，例如「只使用指定資料源」「無法確認的內容標記為待核實」「不得發送外部請求」。指令越清晰，行為越可預測。
• 上下文層（Context）：包含 Agent 在每一步決策時能看到的資訊，例如對話歷史、文件內容、工具回傳、記憶和檢索結果。上下文的質量和組織方式，直接影響輸出質量。
• 模型層（LLM）：提供推理與生成能力。應用開發者通常不直接改變模型層，但必須理解它的概率特性、上下文限制和工具調用方式，才能設計好上面三層。

目標層、指令層和上下文層可以合稱為 Harness：也就是圍繞模型搭建的工作環境。Agent 工程的核心，不只是選擇模型，而是設計一套能穩定管理目標、資料、工具、評估和權限的 harness。

Agent Loop：四步運行循環

當 Agent 收到任務，它通常會重複以下循環，直到目標完成或遇到無法解決的阻礙：

1. 確認目標：從提示詞和上下文中抽取「要完成甚麼」。如果目標描述含糊，模型會自行推斷，推斷結果未必符合使用者原意。
2. 收集上下文：讀取可用資訊來源，包括目前對話、文件、記憶、技能模組和工具輸出。關鍵不是把提示寫得很長，而是把資訊源組織到可被查找和引用。
3. 制定步驟：決定先做甚麼、後做甚麼、是否需要調用工具，以及每一步如何驗證。
4. 執行並觀察：調用搜尋、讀寫文件、資料查詢或其他工具，根據結果更新計劃，再進入下一輪循環。

很多人會直覺地把 LLM 想成一個超大型資料庫，好像它把互聯網、書籍和程式碼完整「存」了進去，所以任何問題都能直接查答案。這個直覺不準確。

LLM 更準確的描述是 Next Token Predictor：給定一段輸入文字，它估計下一個 token 的概率分佈，再按概率生成後續內容。訓練的結果不是逐字儲存知識，而是學會人類文字、程式碼和推理痕跡中的統計規律。

Token 是甚麼

Token 是模型計量文本的基本單位。英文單字、標點、空格組合、中文字符都可能被切成不同 token。例子：

generates / the / most / likely / next / ' / s / token / , / word / or / phrase

粗略來說，英文一個單字約等於一個 token，標點符號常常單獨成為 token；中文的切分會因 tokenizer 而異。不同 tokenizer 會把同一段文字切成不同 token 數，因此會影響上下文容量與計費。

為甚麼輸出會變

假設輸入是 generates the most likely next，模型可能估算出以下概率分佈：

• token：50%
• weapon：30%
• resource：20%

模型不一定每次都選最高概率的詞，而是按設定和概率分佈抽樣。因此，同一個問題問多次，結果可能有所不同。這就是非決定性（non-determinism）的來源。

Temperature：控制確定性的旋鈕

Temperature 會影響抽樣分佈。較高的 temperature 讓輸出更多樣，適合腦震盪、創意寫作和探索；較低的 temperature 讓輸出更穩定，適合合規判斷、資料擷取和結構化輸出。

不少模型服務也提供類似「推理深度」或「思考強度」的參數。它們未必等同於 temperature，但都會影響模型在輸出前進行自我檢查、步驟展開和答案穩定性的程度。

理解 LLM 是概率機器之後，許多常見行為就有了解釋：幻覺、討好、過度執行和不穩定輸出，都是「在概率空間中生成高分答案」這個底層機制的不同表現。

不同大模型的能力、語氣和偏好各異，原因之一是訓練流程和資料分佈不同。主流訓練通常包括以下幾類階段：

1. 預訓練（Pre-training）：在大規模文本、程式碼和多模態資料上學習統計規律，令模型能生成流暢文字並掌握大量一般知識。這一步需要巨量算力和資料治理能力。
2. 監督式微調（Supervised Fine-Tuning, SFT）：用人工整理或程序化生成的問答、指令和示範資料，讓模型更懂得跟隨任務格式、回答方式和領域要求。
3. 人類反饋強化學習（RLHF）：讓評估者比較不同答案的質量，再把偏好信號轉化為訓練目標。它能提升可用性和服從度，但也可能帶來討好使用者、過度自信等副作用。
4. AI 反饋強化學習（RLAIF）與蒸餾：用另一個模型作為評估器或教師模型，擴大評估規模，並讓能力或風格在模型之間轉移。這可能令不同模型在語氣、結構和安全偏好上逐漸趨同。

這些階段共同塑造了模型的可用性，也留下了工程上必須管理的副作用：模型會追求被評為「好答案」的輸出，但「看起來好」不一定等於「真實、完整、可執行」。

以下特性不是某個產品或某個部署方式才有，而是大模型作為概率生成系統、經過偏好訓練後常見的工程風險。它們不能完全消除，只能透過目標、指令、上下文、評估和權限設計來管理。

1. 討好傾向（Sycophancy）：模型會傾向輸出使用者更容易接受的答案。需要客觀評估時，應明確要求批判性分析、列出反例和不確定性。
2. 幻覺（Hallucination）：模型可能生成不存在的連結、數字、來源或結論，並以很肯定的語氣呈現。高風險任務應要求來源、引用原文、標記未核實內容，並加入獨立驗證。
3. 過度執行（Over-execution）：目標越寬泛，模型越可能做太多、寫太長或掃描不相關範圍。任務應限制範圍、輸出長度、可用工具和停止條件。
4. 走捷徑（Shortcut-seeking）：如果成功標準設計得不好，模型可能追求「看起來完成」而不是真正完成。工程上要定義真實目標，而不是只定義容易被操控的指標。
5. 容易受注入影響（Injection-prone）：模型會把上下文中的文字當作可參考內容；若外部文件、網頁或電郵藏有惡意指令，就可能干擾任務。必須把外部內容視為不可信輸入。
6. 非決定性（Non-determinism）：同樣輸入不保證得到同樣輸出。需要穩定結果時，應降低隨機性、固定格式、加入測試集或使用評估器篩選輸出。

接受這些特性，並不代表 Agent 不能用。相反，清楚知道它會在哪裏出錯，才有可能設計出穩定、可追蹤、可審計的工作流。

建立 AI 系統之前，需要先分清幾個常被混用的概念：

• LLM：底層的 token 預測與生成模型，是其他形態的基礎。
• Chatbot：基於 LLM 的對話介面，通常是一問一答，適合一次性解釋、摘要和問答。
• Workflow：帶有固定步驟和任務上下文的自動化流程，適合高確定性的重複任務。
• Agent：能夠持續規劃、調用工具、讀取上下文並迭代到目標完成的系統，適合較開放、需要多步推理的任務。

選型時可以先問：任務步驟是否固定？如果步驟固定、輸入輸出清晰，workflow 往往更穩定、更便宜；如果任務開放、需要自行查找資料和調用工具，才更適合使用 Agent。

上下文是 Agent 工程的核心。模型每一步決策能看到甚麼、看不到甚麼、看到的內容是否可信，往往比單次提示詞措辭更重要。

甚麼是 Context Window

每個模型都有 context window 上限。超過上限，請求可能失敗或需要壓縮。Agent 工作時，上下文會累積得很快，因為每次回覆都可能把歷史對話、工具結果、文件片段和中間推理重新打包發給模型。

上下文變大的三個代價

• 變慢：每次都要處理更多 token，推理延遲上升。
• 變鈍：上下文越長，模型越容易忽略早期約束、關鍵細節或低頻指令。
• 變貴：輸入 token 通常會計費；上下文翻倍，成本可能同步上升，甚至因 cache miss 而更高。

成本例子

以假设计费模型估算：全新對話可能只需處理數百個 token；如果對話已累積 100K token，之後就算只說一句話，也可能需要重新帶上 100K token；若累積到 500K token，單次互動成本可能比全新對話高出數十倍。

Prompt Cache

部分模型服務會對重複上下文提供 prompt caching 或折扣計費。如果長上下文前綴在有效期內被重複使用，重複部分可能按較低成本計算；一旦 cache 失效，舊上下文就可能重新按正常成本計費。

實務上，長時間離開前可以讓 Agent 把結論和待辦寫入文件；回來後開新會話，從摘要和文件恢復上下文。這通常比在超長對話裏繼續追加指令更清晰，也更容易控制成本。

管理上下文的工具箱

• RAG（檢索增強生成）：先建立索引，需要時只取相關片段放入上下文。
• 文件組織：把背景知識拆成可導航、可引用的文件，而不是一次性貼入整段資料。
• 記憶（Memory）：把長期偏好、穩定規則和已確認結論存入持久化記憶，避免每次重新交代。
• 系統提示精簡：只保留真正需要常駐的規則，把可查詢資料移到文件或檢索系統。
• 技能模組可導航化：把大型指令拆成目錄、索引和小文件，讓 Agent 知道應該去哪裏找規則。
• 摘要與壓縮：定期把歷史對話壓縮成決策、結論、待辦和未解問題。

上下文工程的第一原則是：不要把所有內容堆進 prompt，而是把資訊放在可查找、可引用、可驗證的位置。

當任務變複雜，單個 Agent 獨立工作未必足夠。常見編排模式包括：

1. Prompt Chaining（順序鏈）：把任務拆成線性步驟，上一輪輸出作為下一輪輸入。適合步驟清晰的工作；風險是中間錯誤會向後累積。
2. Routing（路由）：先判斷任務類型，再把任務交給對應的提示詞、技能模組或工具流程。適合任務分類明確、規則穩定的系統。
3. Parallelization（並行）：把相互獨立的子任務分配給多個執行單元，最後合併結果。適合資料收集、獨立分析和多來源比較；前提是子任務真的互不依賴。
4. Orchestrator-Worker（編排者與執行者）：由一個主控單元負責計劃、分派和整合，多個工作單元各自處理具體任務。適合需要動態規劃和跨工具協調的複雜工作。
5. Evaluator-Optimizer（評估與優化）：一個單元生成輸出，另一個獨立單元按標準評估，再根據反饋修正。適合內容生成、程式碼審查、規則撰寫和高質量交付。

使用這些模式時，不一定要手寫底層編排器，但必須能描述任務形態、角色邊界、輸入輸出和評估標準。這些描述會直接影響 prompt、工具接口和子任務拆分方式。

Evaluator-Optimizer 的用法

1. 定義輸出目標：寫清楚產物、格式、約束和驗收標準。
2. 生成第一版：根據目標、上下文和工具結果產出 v1。
3. 獨立評估：用同一套標準檢查缺口、錯誤、風險和未滿足條件。
4. 根據反饋修正：只針對評估結果和原始目標修改，避免任意擴大範圍。
5. 循環直到達標：重複生成、評估和修正，直到通過質量門檻或達到迭代上限。

Harness 不是裝飾性的 prompt，而是 Agent 的管理系統。它決定目標如何被理解、上下文如何被選擇、工具如何被調用、輸出如何被評估，以及權限如何被控制。

• 定義目標與範圍：寫清楚完成標準和硬邊界，避免過度執行或自作主張。
• 組織上下文與資源：整理文件、記憶、技能模組和工具輸出，讓資訊可查找、可引用、可驗證。
• 管理模型特性：理解幻覺、討好、走捷徑和偏信輸入等風險，並在提示詞、工具和評估流程中提前約束。
• 建立評估與反饋：使用規則檢查、測試集、獨立評估器或真實數據信號，避免只相信模型自我聲明。
• 設計權限邊界：高風險操作需要人工覆核，工具權限遵循最小權限原則。
• 保留可追蹤性：記錄工具調用、輸入來源、決策摘要和輸出版本，方便審計與回滾。

不要把原始憑證交給 Agent

Agent 有時需要代表使用者調用外部系統。最危險的做法，是把瀏覽器 cookie、session token、API key 等原始憑證直接貼給模型。這類憑證通常權限過大、難以審計，也難以限制用途。

設計授權時，至少要回答四個問題：

1. 是否需要人工覆核？高影響力操作是否必須先經人確認？
2. 是否最小權限？Agent 拿到的是任務所需的最小 scope，還是完整帳戶權限？
3. 是否可撤回？憑證或授權能否快速 revoke？錯誤操作能否 rollback？
4. 是否可追蹤？能否看到它調用了哪些工具、讀取了哪些資料、改動了甚麼狀態？

系統越安全，Agent 能被授權做的事越多。安全不是自動化的阻礙，而是擴大自動化範圍的前提。

AI 安全不只是「不要問不該問的問題」。真正的安全威脅來自 Agent 的所有輸入來源，而這些來源遠不止使用者輸入的一句話。

Agent 會讀取哪些輸入

• 使用者 prompt
• 文件區中的 PDF、Word、CSV、Markdown 或程式碼
• 技能模組和系統提示
• 網絡搜尋結果和網頁內容
• 複製貼上的電郵、聊天紀錄或表格
• 其他模型或 Agent 的輸出

甚麼是 Prompt Injection

Prompt injection 是攻擊者在 Agent 會讀取的位置嵌入惡意指令，誘導模型洩露上下文、覆蓋原有規則或執行未授權操作。典型攻擊鏈如下：

1. 引入外部內容：使用者把網頁、文件、提示詞片段或技能模組加入任務上下文。
2. 惡意指令被嵌入：內容中藏有要求模型忽略原規則、外傳資料或調用工具的指令。
3. 模型誤把指令當任務：Agent 在中間步驟中讀取該內容，並把惡意文字視為應遵循的上下文。
4. 資料或權限被濫用：敏感上下文、帳戶操作或工具權限被導向不應到達的位置。
5. 表面輸出可能正常：最終答案未必暴露異常，因此需要依賴輸入檢查、權限邊界和操作日誌防禦。

防禦清單

• 引入外部內容前先檢查：讓系統先判斷文件或網頁是否包含試圖改寫行為的惡意指令。
• 在常駐規則中加入安全約束：處理電郵、PDF、網頁和外部文件時，優先檢查 prompt injection；發現可疑內容即停止並提示使用者。
• 使用最小權限：需要讀取就只授權讀取，不授權修改；需要查詢就不授權發送或刪除。
• 高風險操作必須人工確認：發佈內容、操作帳戶、轉帳、刪除資料或改動生產狀態，都應先經人確認。
• 建立操作日誌：記錄調用了哪些工具、讀取了哪些來源、產生了哪些輸出，以及是否有人工覆核。

AI 可以放大使用者的執行能力，讓同一個人同時使用多個模型、工具和自動化流程。但它不是免費勞動力，而是一種需要管理的計算資源。

常見成本陷阱

• 上下文沒有管理：每次互動都攜帶大量歷史，令 token 成本大幅上升。
• 過度執行：Agent 調用大量不必要工具，工具成本和 token 成本同步增加。
• Cache 失效：長上下文前綴不再命中 cache，舊上下文重新按正常成本計算。
• 並行過多：為小任務啟動太多子任務，協調成本高於節省的時間。
• Tokenizer 或模型版本變化：同一段內容的 token 數和單價可能改變，需要重新估算。

ROI 思維框架

1. 探索期：先驗證 AI 是否能做、效果是否足夠好，不急於壓低成本。
2. 驗證期：跑通 workflow，確認能穩定產出正確結果。
3. 規模化前：計算真實 ROI，包括節省的人力、提升的質量、新增收入、模型費用、工具費用和維護成本。
4. 無法計算 ROI 的流程，不應盲目擴大：如果成本高於節省的時間或產生的價值，就應重新設計或停止。

任何看似高效的 AI 流程，都可能在長上下文、並行任務和高頻工具調用下變得昂貴。識別哪些任務真正值得交給模型，是 Agent 工程的重要能力。

設計 Agent 任務前，先回答五個問題

1. 最終要交付甚麼？目標是否明確到可以判斷完成與未完成？
2. 真的需要 Agent 嗎？如果步驟固定，workflow 可能更穩定、更便宜；如果任務開放且需要工具推理，才需要 Agent。
3. 需要哪些上下文和工具？文件、記憶、技能模組、檢索系統和外部工具是否組織好？哪些內容不應進入上下文？
4. 如何評估它是否做對？是用獨立評估器、規則檢查、人工審核、測試集，還是真實數據反饋？
5. 出錯的最壞結果是甚麼？是否有人工覆核、最小權限、回滾方案和操作日誌？

第一性原理總結

• LLM 是概率機器，不是資料庫：它預測下一個 token，而不是直接檢索真相。隨機性、幻覺和不確定性只能管理，不能完全消除。
• Context 越大不一定越好：更多上下文會同時帶來更慢、更貴、更容易分心。上下文工程的重點是選擇、壓縮和分層。
• Harness 是 Agent 的管理系統：目標、指令、上下文、工具、反饋和權限共同決定 Agent 能力上限。
• 安全是放權的前提：只有當輸入檢查、權限邊界、人工確認和追蹤日誌存在時，Agent 才能被允許做更高影響力的事情。
• 編排模式要匹配任務形態：順序鏈、路由、並行、編排者與執行者、評估與優化，分別適用於不同任務。
• ROI 決定能否規模化：先驗證可行性，再計算真實成本。只有當節省的人力、提升的質量或新增收入高於 AI 成本時，工作流才值得擴大。