今天要聊什麼？

上一篇談的是架構取捨：外層流程由程式控制，只有在任務需要根據當下狀況動態決定下一步時，才把這部分交給 Agent。

今天就沿著這個原則，看看我怎麼把前幾天提過的這個需求落成一條實際的資料獲取流程：

「送給剛滿三十歲、喜歡露營、偏好低彩度風格的朋友，預算大概 NT$2,000。」

搜尋系統要回答這句話需要以下的資訊：產品屬於什麼分類、適合什麼情境，有哪些文字、材質與圖片可以描述風格，以及哪些條件需要用明確欄位保存，才能直接比較與篩選。

前面幾天已經談過要怎麼把使用者需求用資料表示，現在要處理下一個問題：**資料獲取流程要怎麼有系統地把需要的資訊找回來、驗證，再存進資料庫？**這些資訊分散在品牌官網、商品頁、社群與購買頁面裡，而且每個網站的結構都不一樣。想用一套固定規則涵蓋所有 edge cases 並不實際；在需要根據現場資訊調整策略的地方，Agent 的動態判斷就開始有價值。

先看整條資料獲取流程

真正開始做資料獲取時，我們要面對的不是「找一個爬蟲把網站抓完」這麼單純，而是一連串性質不同的問題：先確認有哪些可信入口、判斷這是不是我們要的品牌、決定網站該怎麼讀，再把名稱、品牌資訊和商品整理成後面能使用的結構。

最後我把這些責任拆成六個模組：Gather、Detect、Acquire、Names、Editorial、Products。

從上圖可以看到每個步驟之間的關係：後續模組會讀取前面模組的輸出，再繼續處理。這些模組的執行方式並不相同：為什麼有些地方我只用程式，有些地方加一個 LLM，有些地方卻真的需要 Agent？我的決策邏輯如下：

• 規則能寫清楚 → deterministic code：規則有限、輸入輸出明確，就不需要額外增加 AI 的不確定性，例如 Gather 這個步驟就是這樣的狀況。
• 任務明確，但需要語意判斷 → LLM workflow：程式知道要問什麼，也知道答案應該長什麼樣子，只把難以規則化的判斷交給 LLM，例如 Detect、Names、Editorial 就是這樣的狀況。
• 連下一步都要根據目前結果決定 → Agent：系統需要先觀察已經拿到的資訊，再決定下一個動作，例如 Acquire、Products 就是這樣的狀況。

接下來就用實際模組看看這三種情況。

規則寫得清楚，就留在程式裡

第一個模組 Gather 的目標，是先整理和品牌有關的入口與基本資料。流程通常從品牌名稱，以及一個已知的官網或社群連結開始；手上的連結可能包含：

• 品牌自己建立的官方網站
• 社群網站，如 Facebook、Instagram、Threads 等
• 集合頁，如 Linktree、Portaly、Biosite 等

為了補齊後續 data pipeline 需要的來源，我使用了 Serper.dev 這個第三方 Google Search 工具，盡可能把官方網站、社群、購買通路與搜尋摘要補齊。

這裡雖然會呼叫第三方服務、讀取網頁，但沒有使用 LLM，也沒有 Agent。原因很簡單：規則本身已經足夠清楚——知道輸入長什麼樣、不同 URL 類型要怎麼處理，也知道什麼結果可以接受。這種情況下，多加一層 AI 只會增加成本與不確定性。

任務方向明確，但需要語意判斷，就用 LLM workflow

Detect、Names 和 Editorial 都屬於這一類。它們共同的特徵是：程式知道現在要回答什麼問題，也知道輸出應該長什麼樣子，只是中間的判斷很難完全靠規則寫出來。這裡我們就會依靠 LLM 並進行 Prompt Iteration 來持續優化。

Detect 負責判斷「這筆資料要不要繼續往下處理」。Gather 已經準備了品牌名稱、搜尋摘要，以及幾個已知網址的基本資訊；LLM 只需要判斷這是不是我們真的想處理的產品品牌，並排除非品牌的商店、媒體、服務或同名網站。模型只回傳固定格式的判斷與 confidence（信心程度），而且只有高信心結果才會直接影響流程。它不需要完整理解整個品牌，只需要守住這一道入口。

Names 處理的是歧義。在前面我們從很多不同的網站拿到資訊，有些名稱可能會不盡相同，而這裡則是需要 LLM 針對歧義進行整理。舉例來說，一個品牌可能在不同網站中使用不同的名稱，如中文品牌名、英文品牌名、社群軟體 handle 名稱、公司全名等等。若沒有進行資料的清理則可能會同個品牌不同的名稱視為不同的品牌。

Editorial 則是一條固定的 data enrichment pipeline。在這裡我們目標是要產出品牌描述、實體通路和 FAQ 等資訊，這些資訊都有明確的資料來源和輸出規則，所以沒有必要讓 Agent 自己決定下一步。程式只需要先挑出相關的資訊和來源證據，再讓 LLM 整理成指定格式，產生結果後再用規則檢查文字長度、允許值、重複內容與欄位一致性即可。

這一類 workflow 真正的工程問題，不是「模型會不會回答」，而是怎麼知道它回答得夠不夠好，而且改版之後有沒有退步。後面我們會再談怎麼用固定測試案例與 Eval，把原本主觀的「看起來比較好」變成可以比較的結果。

當需要動態進行決策時，才使用 Agent

Acquire 和 Products 是流程裡比較需要 Agent 的兩個模組。這裡的不確定性不只在答案本身，而是連下一步該做什麼，都要先看目前拿到的結果才能判斷。下面先用 Acquire 當代表案例。

在 Acquire 這個步驟，我們需要逐一檢視 Gather 整理出的來源，再進一步取得後續需要的資訊。這也是整條流程裡最難標準化的部分。

• 同樣是品牌官網，有些首頁的 HTML 就包含完整內容，有些主要靠 JavaScript 載入；有些商品直接掛在首頁，有些要先進分類頁，再從分類頁找到商品頁。
• 同樣是社群媒體，有些會在自我介紹欄位放上完整資訊，有些會放上不同連結或實體寄售點。

由於每個品牌都有自己的網站設計，這時就需要 Agent 先觀察目前拿到的資訊，再決定下一步。它可以先嘗試直接讀 HTML；如果內容不足，再改用 browser rendering；也可以從目前頁面找出新的連結，判斷哪些值得繼續探索。

這裡其實分成兩個階段：前面是在做有限的「探索」，目的是弄清楚資料可能在哪裡；等資訊足夠後，才產生正式的抓取計畫。Agent 必須要清楚的知道目前所讀取的頁面能不能得到所需要的資訊，若資訊不足或是網頁的架構並不如原先想像，則需要根據當下的狀態去動態調整決策，例如改用 rendering、展開更多連結，或補做搜尋。

但這個自由有明確邊界。Agent 不能任意發明網址，只能讀 Gather 已經提供的網址，或從這些頁面實際發現的新連結；browser rendering、搜尋次數與總執行時間也都有上限。Agent 決定下一步做什麼，程式決定它最多可以做到哪裡。

Acquire 會是後面幾篇反覆使用的主要案例。當系統開始有 Tool Use 和多步決策之後，真正困難的就不只是 prompt 怎麼寫，而是怎麼讓模組之間可靠交接、限制 Agent 的行動範圍，並且知道失敗到底發生在哪一步。這些問題都建立在同一個前提上：先決定哪裡真的需要 Agent，再想辦法把這份自由變得可控、可測、可以持續改善。

明天要聊什麼？

模型給出一個答案，不代表下一段程式就能安全使用。明天先從 Structured Outputs 和 schema validation 開始，處理模組之間最基本的資料交接問題。

我們明天見！