其中 Vision API 把看圖這段工作刻意解耦出來，只負責一件事，把訪客上傳的圖片轉成大多數模型都讀得懂的文字描述，再交給後續的 AI 節點。多模態模型本身就能直接看圖回答問題，這套架構卻先把圖片翻譯成一份文字小抄，目的是讓每一位 Sub Agent 都能在檢索階段的文字海裡，拿著同一份小抄、加上訪客的原始提問，一路下潛。
RAG Harness 的分段解耦
RAG API 由 Diving Agent（調度） 拿著 Master Sitemap，並依照訪客的提問來主導該派出哪一位 Sub Agent（執行，Diving-mode），與該往哪個方向進行。而 Sub Agent 負責判斷該抓哪段內容。每到一個新的深度、面對一個新的場景，手上始終握著小抄與使用者最初的提問。最終 Chat API 收到所有檢索成果之後，用站長定義的人格與回答規範產出最終回應。
Vision API、RAG API、Chat API 三段 AI 節點各自獨立，每段都可以自由配置不同的模型。雲端有 Mistral、OpenAI、Gemini、xAI 等選項，本地運算推薦 vLLM。挑模型不再是一個全局決策，而是分段最佳化，圖片辨識交給擅長視覺的模型、檢索路由交給便宜的小模型、最終回應再用適合表達的模型來收尾。
每段 AI 節點都是一份乾淨的配方
每段 AI 節點不會把所有的上下文往下游堆，Sub Agent 之間交付的，只是清晰的下潛方向與重新注入的原始提問。Vision API 只傳出判讀後的圖片語意。RAG API 在 Diving-mode Loop 的多次潛降中，每一輪找到的目標另外存進累積區，由 Scuba Deep Dive（驗收）判斷檢索是否充足，夠了才把整個累積區交給 Chat API。下游只會拿到上游團隊的成果，碰不到過程。
除了上下文隔離之外，每一個節點的 LLM 任務也被刻意收斂。檢索過程中的每一次呼叫，LLM 不是自由生成長文，而是輸出固定 JSON，先用一句 think 審題、想清楚當下該往哪走，再填 next_mode 與 next_act 兩個作答欄位。這句 think 一物兩用，輸出到前端讓訪客看見 AI 此刻在想什麼，也讓小模型在作答前先把方向收斂一次，到後面選模式、選內容會因此更準。
整段任務收斂成選擇題，只考模型知不知道自己在做什麼、做不做得出判斷，不考長文生成的能力。乾淨的配方加上收斂的輸出，這兩件事一起讓 Llama 3B 這種輕量模型也能跑通整套 RAG 流程。
Prompt Cache：第二次查詢起的成本剩零頭
整個運作流程中，token 消耗量最大的是輸入不是輸出，比例大約是 10：1。佔比最大的提示詞、Master Sitemap、所有頁面或文章 chunk 全部都是靜態內容，從架構層面就被歸類為 cache 段，連 #ROLE、#RULES、#OUTPUT、#SOUL.md 也一併處理。網站主不需要自己劃這條邊界，靜態的歸靜態、動態的歸動態，從第二次查詢起，最大宗的開銷只剩零頭。
RAG Harness 的最小化紀律
每一 hop 用乾淨的配方、每一段任務都收斂到最小、靜態與動態邊界清楚，這些設計沒有一項是裝飾性的。每段 AI 都做成一個 MVP，Minimum Viable Product 的思路，以最低的代價達成最基本的可行性。每個節點只做剛好夠用的事，配方剛好夠乾淨、模型剛好夠小、輸出剛好夠收斂。當下的實踐是多個輕量模型分段配置，未來若多模態小模型成熟，整段用單一模型也照樣成立。
