打造旅遊 Copilot：端對端架構、核准閘門（Approval Gate）與稽核能力（Auditability）

當一個團隊準備建構進階 AI 旅遊 Copilot 時，真正的難題不是「用哪個模型」，而是「在系統能被正式環境信任之前，什麼事情必須發生、按什麼順序、憑什麼證據、在什麼狀態下、經誰核准？」這是架構問題——模型位於其中，但模型並不能解決這個問題。

以本系列貫穿始終的範例為例：一個為 OptiVerse Travel 設計的多模態旅行規劃 Copilot——一家專注於客製化行程的中型旅行社。客戶提出需求：

規劃一趟 10 天的日本無障礙旅行，適逢櫻花季——四口之家，一位輪椅使用者——預算 $13K–$15K。請附上相關的合約費率、無障礙證據，並產出一份推薦備忘錄，列出最具防禦力的行程建議。

這個需求已經遠超生成任務的範疇。系統必須匯入並解析合作夥伴文件、還原合約費率表和無障礙認證、檢索符合無障礙加預算加日期的最佳選項、組建旅行檔案、建立帶有證據軌跡的行程、執行預算檢查，並在明確的核准邊界處停下——預訂前要客戶簽核、收費前要付款授權。這些職責中只要有任何一項是模糊的，系統可能還是會產出流暢的答案，但它不會是一個可用於正式環境的旅行系統。

本總結篇透過兩個組織框架把系列串連起來。第一個是架構三元組：證據流、狀態流和控制流。第二個是輸出階梯：「描述 → 建議 → 行動」（describe → recommend → act）。這兩個框架不是修辭上的包裝，而是設計系統時的實用邊界——確保系統在能力提升的同時，仍保持有基礎、可審查且在營運上安全。

這裡的主張也不宜過度。這是一個受治理旅遊 Copilot 的架構模式，而非在宣稱某個通用代理可以安全地端對端自動化整個行程規劃工作流程。重點在於展示有界限的檢索、工具使用、核准閘門（approval gate）和可重播的軌跡怎麼組合成一個系統，在不假裝不確定性已消失的前提下支援旅行規劃。

免責聲明：本文中所有公司、人物、預訂和資料均為虛構。OptiVerse Travel 不是一家真實的旅行社。

端對端的架構問題

要誤解進階 Copilot，最簡單的方式就是把它當成一個多了幾個工具的聊天介面。在正式環境中，系統邊界寬得多。

一個端對端的旅遊 Copilot 通常至少需要以下幾層：

• 匯入合作夥伴合約、費率表、無障礙稽核、目的地指南和物件照片

• 還原版面、表格、圖片連結和文件層級關係的文件智慧（document intelligence）流程

• 跨文字、表格、中繼資料和視覺產物的檢索

• 為活躍規劃任務持有有界限旅行檔案的工作記憶

• 用於搜尋、擷取、比較、正規化和預算分析的工具使用

• 產出選項摘要、推薦行程或拒答的合成步驟

• 在具有後果性的下游動作之前設置核准閘門——預訂前需要客戶簽核、收費前需要付款授權

• 紀錄系統看到了什麼、做了什麼、決定了什麼和交接了什麼的軌跡與日誌基礎設施

所以總結架構應該理解為一個複合系統，而不是一個代理提示詞。第一和第二篇確立了有用的系統將工作分解為具有明確控制邏輯的階段。第五篇把這個觀點聚焦為一個設計問題——「誰控制下一步」——並引入了「描述／建議／行動」階梯，本總結篇將其具體化。第三、第四和第七篇區分了基礎化檢索、持久知識、任務狀態和有界限的工作上下文。第五和第六篇闡明了使用工具的代理行為是一種控制模式，而非無限制自主的許可。第八和第九篇指出文件和多模態證據本身就是架構層。最後一步是讓這些層在營運約束下協同工作。

組織三元組：證據流、狀態流和控制流

要理解正式環境 Copilot 的運作邏輯，最簡單的方式是把三個在原型中經常混在一起的流分開來看。

證據流

證據流是來源材料變成可用答案或建議支撐的路徑。

在日本旅行範例（JPN-2026-0417）中，證據流在問題被問出來之前就已經開始了。系統匯入合作夥伴合約、飯店費率卡、航空公司無障礙政策、輪椅計程車可用性表、目的地照片和無障礙稽核報告。文件層擷取的是結構而不只是文字：章節、表格、圖說、照片區域、頁面版面和來源中繼資料。多模態層保留了影像證據，以及物件照片、無障礙認證、鄰近描述和預訂識別碼之間的連結。檢索接著選出任務專屬的子集——「廣泛檢索、局部推理」（retrieve broadly, reason locally）——在所有合作夥伴資料中廣泛檢索，然後在旅行檔案內局部推理。結果不是「所有上下文」，而是一個為單一行程組裝的有界限證據封包。

該封包可能包含：

• 三個符合櫻花季日期的京都無障礙飯店選項，源自合約 KYO-H12

• 兩份 JAL 和 ANA 的航空費率比較，含輪椅協助細節

• 擷取的費率表，定價層級已正規化為美元

• 與預訂中繼資料關聯的物件照片和無障礙認證影像（照片集 ACC-09）

• 關西和關東地區的 JR Pass 定價和輪椅計程車可用性紀錄

• 回溯到來源合約條款、費率表儲存格、照片 ID 和紀錄 ID 的溯源指標

這些連結一旦薄弱，系統其餘部分也會跟著薄弱。光在最終段落附上引用並不夠——架構必須能顯示哪些產物被檢索、哪些被丟棄、哪些被轉換，以及哪些實際上支撐了推薦。

狀態流

狀態流是系統追蹤它正在執行什麼任務、存在哪些中間產物，以及什麼工作上下文處於活躍狀態的路徑。

這與證據流不同。證據是關於來源支撐，狀態是關於流程。

對同一個 JPN-2026-0417 需求，系統可能持有：

• 活躍的旅行 ID 和客戶身份

• 當前的工作流程階段

• 本次執行所選的證據封包 ID

• 未解決的缺口——例如箱根的輪椅計程車確認仍缺失

• 中間輸出——例如一張結構化的預算比較表

• 推薦和預訂階段的核准狀態

狀態之所以重要，是因為進階工作流程會橫跨許多步驟，而且經常分支。一個無法追蹤自己是否還在用當前旅行檔案、費率表擷取是否驗證過、或行程是否已經通過客戶審查的系統，很容易出現微妙的失敗——看起來像推理錯誤，實際上是狀態管理出了問題。

這也是為什麼工作記憶要保持有界限且暫時性。JPN-2026-0417 的活躍封包對當前行程建構有用，但它不是持久的知識庫，也不該悄悄變成一個。

控制流

控制流是系統決定接下來做什麼的路徑。在此架構中，「誰控制下一步」（who controls the next step）絕不交由模型自行裁量，而是由明確的決策邊界來定義。

控制流決定：

• 何時匯入必須在檢索之前執行

• 何時擷取品質足以繼續

• 哪個工具可以被呼叫、以什麼 schema、在什麼驗證規則下

• 何時合成步驟被允許生成推薦

• 何時工作流程必須停止、拒答、重試，或提報給人工審查者

在早期原型中，控制流往往隱藏在提示詞內。在正式環境中，這太不透明了。應用程式需要明確的決策邊界，因為這些邊界決定了可靠性、延遲、成本和營運風險。

三元組一旦明確了，系統設計就更容易除錯。行程引用了錯誤費率？問題可能在證據流。系統用了新合約到達之前上個月的費率卡？問題可能在狀態流。系統在客戶簽核之前就發出預訂確認？問題可能在控制流。不同的失敗，需要不同的修復。

匯入、檢索、工作記憶和工具使用如何組合

把架構當成一次執行來追蹤，而不是列一張元件清單，理解起來就具體多了。

1. 匯入建立權威的原始輸入

系統接收一系列材料：合作夥伴合約 PDF、費率卡試算表、無障礙稽核報告、物件照片、目的地指南和航空公司政策文件。匯入層會指派穩定的紀錄識別碼、儲存來源中繼資料、計算校驗碼，並記錄存取控制屬性。在這個階段，系統還沒在回答任何問題——它正在建立權威輸入，後續的證據都從這些輸入衍生。

要注意的是：匯入應儘早保留身份和溯源。後來擷取的費率如果無法回溯到來源合約和文件位置，軌跡就已經斷了。

2. 文件智慧重建結構

下一層將原始檔案轉化為結構化的證據物件。對 PDF 和掃描合約而言，這意味著必要時使用 OCR、版面還原、閱讀順序、表格重建、圖說連結、章節分割，以及當一個檔案包含多個邏輯文件時進行文件分割。對內部紀錄而言，可能意味著 schema 正規化和跨旅行 ID、合約 ID 和物件識別碼的實體解析。

這一層延續了第八篇的核心教訓：文件智慧（document intelligence）不是可選的前處理便利功能——它決定了後續檢索能否區分費率表表頭和內容儲存格、照片圖說和無關文字，或合約附錄和主條款。

3. 多模態證據處理保留視覺支撐

系統不該把影像扁平化成附帶品。物件照片、無障礙認證影像和頁面呈現需要有自己的識別碼，以及跟圖說、鄰近描述和預訂中繼資料的連結。這正是第九篇的核心教訓在總結中發揮作用之處：視覺證據必須跟旅行紀錄的其餘部分保持對齊。

對 JPN-2026-0417 來說，這代表系統不只能檢索關於無障礙房間的文字段落，還能檢索支持適用性比較的特定物件照片和無障礙認證影像（照片集 ACC-09）。

4. 檢索組裝有界限的證據封包

檢索是從廣泛語料庫到活躍任務的橋梁。好的正式環境模式是混合式的：在索引語料庫中廣泛檢索，然後透過為規劃工作流程組裝有界限的旅行檔案來局部推理。封包應該小到可以審查和推理，但豐富到足以保留決定性證據。

此任務的典型檢索產物可能包含：

• 具有類似無障礙需求或櫻花季時程的先前行程

• 合作夥伴合約中討論無障礙房可用性和取消條款的章節

• 含季節性定價和輪椅協助附加費的擷取費率表

• 與特定飯店綁定的物件照片和無障礙認證

• 約束輪椅協助選項是否真正可比較的航空公司政策

新鮮度和權限在這裡很重要。檢索若忽略了最新的合作夥伴合約、或浮出旅遊顧問還沒有權限引用的費率，系統在生成開始之前就已經失敗了。

5. 工作記憶持有活躍封包和中間比較

檢索完成後，旅行檔案就成為當前任務的工作記憶。系統可能用正規化的預算明細、待解決問題和中間判斷來充實它——例如「京都物件的無障礙房已確認，但箱根的輪椅計程車可用性尚未完整」。這是有用的暫時狀態，不是持久的真理。

把封包保持明確有兩個好處。第一，為合成層提供一個比整個語料庫倒進去更窄、更站得住腳的上下文視窗。第二，為稽核和審查流程提供執行後可以檢查的具體內容。

6. 工具使用在明確的契約上運作

工具使用在這裡是工作流程的受控擴展，不是自由形式的自主展示。模型可能被允許呼叫：

• 檢索服務

• 費率表比較工具

• 貨幣換算和預算正規化函式

• 可用性查詢服務

• 影像分析或照片裁剪工具

• 行程組裝範本

每個工具都應該有清楚的契約：允許的引數、結構化的輸出、驗證規則和失敗回應。工具呼叫產出格式錯誤或費率比對含混時怎麼辦？不該悄悄流入下游合成，而應該以安全失敗（fail closed）的方式中止、帶約束重試，或導向審查。

這是正式環境系統和演示之間的分界。工具呼叫不只是便利功能，它是應用程式控制面的一部分。

核准閘門是架構的一部分

核准閘門（approval gate）經常被歸到治理或政策的範疇。這個看法不完整。在正式環境 Copilot 中，核准閘門屬於架構，因為它們塑造了控制流、資料流、使用者體驗和下游整合。

核准閘門是一個刻意設計的停止點——系統把輸出準備好供審查，但在未取得明確核准事件之前，不得推進到下一個具有後果性的階段。這個事件應該綁定角色、身份、政策，以及軌跡中的一筆紀錄。

旅遊 Copilot 的核准閘門通常設置在以下轉換處：

• 從選項摘要到推薦行程發布

• 從推薦行程到預訂執行（客戶簽核）

• 從預訂確認到收費扣款（付款授權）

• 從內部旅行備忘錄到面向客戶的交付或合作夥伴通知

這裡的重點是，並非所有輸出都有相同的營運權重。一份描述性選項摘要通常只是提供資訊。一份推薦行程就開始牽涉承諾了。而一個預訂動作則直接改變現實——它訂了房間、保留了座位、收取了費用。

如果團隊把核准當成事後附加的東西，幾個問題會立刻浮現：

• 使用者介面可能無法保留審查者需要檢查的中間產物

• 軌跡可能未記錄哪份旅行檔案支撐了被核准的行程

• 動作路徑可能已直接連線到預訂 API，沒有乾淨的暫停點

• 使用者可能不知道自己在審查的是證據、建議，還是預訂請求

所以本系列以比「人在迴路中」更高的標準作結。有用的問題不只是人類能不能介入，而是工作流程有沒有在具有後果性的轉換之前設置明確的架構暫停點。

「描述 → 建議 → 行動」（Describe → Recommend → Act）

進階 Copilot 設計中最實用的控制邊界，是這個階梯：「描述 → 建議 → 行動」（describe → recommend → act）。

描述

描述意味著系統摘要、擷取、比較或解釋證據。它可以回答這類問題：

• 在合約 KYO-H12 下，京都有哪些無障礙飯店選項符合我們的櫻花季日期？

• 哪些費率表和物件照片與這次適用性比較相關？

• JAL 和 ANA 的輪椅協助政策在哪些方面一致或分歧？

描述性輸出仍然可能出錯、仍然需要基礎化，但它本身不會改變下游系統，也不會讓旅行社承擔某個行動方案。

建議

建議意味著系統根據可用證據提出下一步方向。例如：

最具防禦力的行程是一條 10 天的路線，途經東京、箱根、京都和大阪，搭乘 JAL 並預訂輪椅協助，因為當前的合約費率和無障礙稽核確認在 $13K–$15K 預算範圍內有空房，但箱根的輪椅計程車確認仍待處理。

這跟描述有本質上的區別——系統從證據呈現轉向決策支援。這通常需要更強的充分性檢查、更清楚的不確定性語言，以及在輸出能驅動預訂決策之前設好可見的核准邊界。

行動

行動意味著系統改變了當前推理上下文之外的東西。例如：

• 預訂飯店客房

• 訂購含輪椅協助的機票

• 向客戶的付款方式收費

• 向合作夥伴飯店發送預訂確認

• 用已確認的行程細節更新旅行社的紀錄系統

這是風險最高的類別，因為輸出不再只是資訊性的，而是有後果的。

對多數正式環境系統來說，核心規則應該很簡單：

• 系統可以自主地描述

• 它可以有條件地建議

• 在具有後果性的工作流程上，不應在沒有明確政策、範圍權限和核准事件的情況下自動行動

不同組織會設定不同門檻，但把這些類別混淆就是設計上的錯誤。一份再怎麼完善的描述性摘要，也無法合理化預訂權限。一份看似合理的行程推薦，不等於已核准的預訂。

範例實作：一次端對端的旅遊 Copilot 執行

我們來走一遍 JPN-2026-0417 需求的完整執行。

客戶要求一份 10 天的日本無障礙行程、符合無障礙和預算限制的合作夥伴選項比較、相關費率表和物件證據，以及最具防禦力的推薦行程。系統首先將需求拆解為工作流程：蒐集相關合作夥伴文件、重建結構化證據、對照預算和無障礙標準進行比較、合成選項摘要、評估證據是否足以支持推薦，並在任何下游預訂動作之前於核准處停止。

匯入層已持有相關語料庫：合作夥伴合約、航空公司政策文件、費率卡試算表、無障礙稽核報告和物件照片。文件智慧層已重建費率表、合約條款、照片區域和章節邊界。多模態層已保留物件影像、無障礙認證和預訂中繼資料之間的連結。

檢索接著為這次特定執行組裝旅行檔案。它拉取了來自合約 KYO-H12 的三個京都無障礙飯店選項、兩份 JAL 和 ANA 的航空費率比較（含輪椅協助細節）、一張顯示櫻花季定價的費率表、入圍飯店的物件照片和無障礙認證（照片集 ACC-09），以及 JR Pass 和輪椅計程車紀錄——顯示目前東京、京都和大阪段的無障礙已完全確認，箱根段則尚未確認。

此時系統可以描述。它產出一份選項摘要：

• 呈現帶有合約支撐費率的無障礙飯店、航班和交通選項

• 辨識哪些選項滿足所有無障礙需求、哪些有缺口

• 引用支撐的合約、費率表擷取和物件照片產物

• 說明任何重要缺口——例如箱根段的輪椅計程車確認尚未完成

此階段的預算明細如下：

項目 — 預估範圍 — 備註

機票（JAL/ANA，輪椅協助） — $4,000–$6,000 — 含無障礙座位安排

住宿（無障礙房，櫻花季溢價） — $3,000–$4,500 — 京都 KYO-H12 合約費率

交通（JR Pass + 輪椅計程車） — $1,800–$2,800 — 箱根段待確認

餐飲 — $1,500–$2,000 —

活動 — $500–$1,000 —

雜項 — $400–$600 —

合計 — $11,200–$16,900 — 客戶目標 $13K–$15K 需選擇中階選項

在進一步推進之前，控制邏輯會檢查推薦標準是否滿足。關鍵證據連結存不存在？檢索到的合約是否最新、存取權限是否正確？正規化的費率表驗證過了嗎？無障礙比較是否還有實質上的模糊地帶？這些檢查沒通過的話，系統應該停留在描述階段，或回傳帶有明確不確定性的有限推薦。它不應該從部分證據中硬擠出決斷性。

假設檢查在附帶條件下通過了。系統現在可以建議：提出一份在無障礙、櫻花季時程和預算之間取得最佳平衡的 10 天行程，同時指出哪些證據最強、哪些假設仍然開放。推薦會附帶旅行檔案 ID、來源引用、比較產物和不確定性備註。

現在第一個核准閘門（approval gate）發揮作用。系統不會自行下任何預訂。客戶看到：

• 描述性選項摘要

• 推薦行程文字

• 使用的確切旅行檔案

• 預算明細和關聯的物件照片產物

• 未解決的缺口和驗證警告

• 若核准後將觸發的預訂項目

只有在客戶簽核後，系統才能行動：預訂飯店客房、訂購機票、確認輪椅計程車服務。但即便如此，在款項實際動支之前還有第二個核准閘門：旅遊顧問對照已核准的行程驗證最終預訂細節、對照商定預算核對總費用，以及對照實際預訂的內容核對當初承諾的內容。只有在付款授權之後才能向客戶收費。每個核准事件都成為軌跡的一部分。沒有這些事件，系統就停留在推薦產物階段，而非營運性變更。

這就是讓核准成為架構一部分的意義所在。客戶不是在讀一封電子郵件裡脫離脈絡的段落，而是在審查一個跟證據、狀態以及下一個可能後果綁在一起的受控產物——系統描述選項、建議行程，只有在明確簽核後才行動。

稽核能力需要可重播的軌跡，不只是最終引用

許多團隊以為答案裡附上引用就算可稽核了。這太薄弱了。

最終引用有助於面向使用者的溯源，但稽核能力（auditability）是系統層級的特性。要在事後審查一次有後果的執行，團隊通常需要重建至少五件事：

1. 系統選擇了什麼證據

2. 工作流程在每個階段處於什麼狀態

3. 呼叫了什麼工具以及回傳了什麼

4. 在階梯的每個類別中產出了什麼輸出

5. 在具有後果性的動作之前誰核准了什麼

這意味著可重播的軌跡通常應包含：

• 請求 ID（JPN-2026-0417）、客戶身份和時間

• 語料庫版本或來源紀錄識別碼（合約 KYO-H12、照片集 ACC-09）

• 旅行檔案 ID 和成員組成

• 檢索結果和重新排序或選擇紀錄

• 擷取的費率表、合約條款和照片產物 ID

• 工具呼叫及其引數、輸出和驗證狀態

• 工作流程狀態轉換

• 模型輸出類別——描述、建議或行動請求

• 核准事件及審查者身份、時間戳記和決定（客戶簽核、付款授權）

• 若動作已執行，則包含下游預訂紀錄，包括承諾與實際預訂的對帳

不是每個系統都需要逐位元組的確定性重播——許多 AI 系統嚴格來說無法做到這一點。但正式環境系統仍然應該支援實際重播：有足夠的可追溯性，讓人能理解哪些來源、轉換和決策產出了最終產物。

這也是「把最終提示詞和答案存起來」的局限性暴露的地方。那筆紀錄漏掉了檢索到的證據集、費率表和照片產物、中間比較物件、工具呼叫、狀態轉換和核准歷史。它是有用的除錯殘留物，但不是充分的稽核軌跡（audit trail）。

總結架構中的常見失敗模式

總結設計會以反覆且可預測的方式失敗。

一個常見失敗是來源連結太薄弱：最終行程引用了飯店名稱，但系統無法顯示哪些擷取的費率表儲存格或無障礙照片產物真正支撐了推薦。另一個是過時的狀態——推薦是從新合約到達之前就組裝好的旅行檔案生成的。第三個是混淆了輸出類別：使用者介面把推薦行程呈現得像已核准的預訂。第四個是軌跡捕獲不完整：文件和多模態產物在合成期間被用到了，卻從未記錄在稽核軌跡（audit trail）中。

還有工作流程層面的失敗。工具輸出可能沒經過驗證就進入下游邏輯。核准的權責可能不明確。客戶可能核准了行程文字，卻沒看到背後支撐它的旅行檔案。預訂路徑可能從原本只用來做描述性旅行規劃支援的同一個介面，就在技術上可以觸及。

這些都不是什麼奇特的模型失敗，而是架構失敗。更好的模型或許能讓它們暫時不那麼明顯——因為輸出看起來更連貫——但這不代表就不用針對它們做設計。

正式環境審查清單

在推出帶有推薦或預訂路徑的旅遊 Copilot 之前，技術團隊應該能清楚回答以下問題：

• 我們是否知道系統可能匯入的確切權威來源，並且從匯入開始就保留了穩定的來源識別碼？

• 文件層能否恢復任務所需的結構，包括費率表、合約條款、照片連結和邏輯文件邊界？

• 多模態層能否將物件照片和無障礙證據作為一級產物保留，而非扁平化為薄弱的文字？

• 檢索是否受到權限、新鮮度和任務相關性的約束，而不僅受嵌入相似度約束？

• 每次執行是否為活躍規劃任務建立明確的旅行檔案？

• 工作記憶是否被視為暫時的任務上下文而非持久知識？

• 工具契約是否明確、經過 schema 驗證，並記錄在軌跡中？

• 在系統從描述推進到建議之前，是否定義了證據充分性檢查？

• 在任何具有後果性的行動步驟之前，是否有可見的架構暫停點，包括客戶簽核和付款授權？

• 每個核准事件是否記錄了審查者身份、決定和時間戳記？

• 團隊能否重建哪些來源、產物、工具呼叫和狀態轉換產出了特定的行程推薦？

• 當證據不完整、矛盾或過時時，是否定義了拒答和例外路徑？

• 使用者介面是否讓輸出類別一目瞭然：描述、建議，還是預訂請求？

• 下游整合是否經過範圍限定，使未核准的輸出無法悄悄觸發真實世界的預訂或收費？

• 團隊是否測試了涉及過時旅行檔案、斷裂溯源連結、格式錯誤的工具輸出和缺失核准的失敗案例？

• 是否有模型版本管理和行為漂移風險的政策？替換或更新底層 LLM 或 VLM 可能以證據層或控制層無法捕獲的方式改變系統行為。

• 團隊是否已解決安全性和對抗性穩健性問題？提示詞注入、資料投毒和對抗性輸入是與此處描述的證據和稽核架構互補的正式環境關切。

• 是否已針對任何面向使用者或影響決策的輸出考慮了公平性和偏見評估？

如果這些問題裡有好幾個答案是模糊的，那這個系統大概還是一個有潛力的原型，而非正式環境就緒的 Copilot。

系列結語：營運嚴謹度是真正的成熟度測試

本系列從區分模型和系統開始，以區分能力和營運成熟度作結。

一個進階旅遊 Copilot 的衡量標準，不在於它能不能流暢地談論目的地、呼叫預訂 API 或解讀物件照片。這些能力很重要，但不是最終標準。真正的成熟度測試在於：系統能不能把證據通過有界限的架構往前推、在多步驟工作流程中維持正確的狀態、在推薦和行動之前執行正確的控制邊界，並留下一條人類可以有信心審查的軌跡。

這就是為什麼總結標準是證據流、狀態流和控制流，圍繞「描述 → 建議 → 行動」（describe → recommend → act）來組織。邊界清晰，系統就能強大卻不至於不透明。邊界模糊的話，即使是令人印象深刻的模型堆疊，仍然難以被信任。

而本系列始終的核心錨定——「誰控制下一步」（who controls the next step）、「廣泛檢索、局部推理」（retrieve broadly, reason locally）、「描述 → 建議 → 行動」（describe → recommend → act）——不是口號，而是設計紀律。每一個都回答了一個在正式環境中必須回答的問題。

營運嚴謹度不是有趣的 AI 工作結束之後才來的部分。在正式環境中，它就是有趣的 AI 工作。

來源附註

本文作為總結篇，參考以下主要、官方與實務來源：

• BAIR. "The Shift from Models to Compound AI Systems." 本文複合式系統框架的核心參考。bair.berkeley.edu/blog/2024/02/18/compound-ai-systems

• Anthropic. "Building effective agents." 有界複雜度、檢查點與明確控制邊界的實務參考。anthropic.com/engineering/building-effective-agents

• OpenAI. "Structured model outputs." 結構化輸出與模型-電腦邊界可靠性的官方參考。developers.openai.com/api/docs/guides/structured-outputs

• OpenAI. "Conversation state." 應用程式端狀態管理責任的官方參考。developers.openai.com/api/docs/guides/conversation-state

• Lewis, P., Perez, E., Piktus, A., et al. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." 支撐證據封包檢索層的參考。arxiv.org/abs/2005.11401

• Smock, B., Pesala, R., and Abraham, R. "PubTables-1M." 表格擷取與結構化文件證據的參考。arxiv.org/abs/2110.00061

• Faysse, M., Sibille, H., Wu, T., et al. "ColPali," and Yu, S., Tang, C., Xu, B., et al. "VisRAG." 視覺豐富文件檢索與多模態 RAG 的參考。arxiv.org/abs/2407.01449, arxiv.org/abs/2410.10594

• National Institute of Standards and Technology. "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile." 可追蹤性、監督、評估與可信任部署語言參考。nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence