**摘要：**Firecrawl 在 2026 年 10 月 23 日發布了一篇完整的資料補全指南，作者 Hiba Fathima。它把「補資料」從銷售場景的 CRM 例行公事，重新定義成 AI agent 任務中途呼叫的即時工具，並附上實測數據。對正在組 agent 工具鏈的產品團隊來說，這篇值得當設計參考。
補全（enrichment）到底在補什麼
指南的核心定義很乾淨：拿一個你手上已有的 match key（公司網域、工作信箱、SKU、股票代號、套件名稱），從外部來源補上原本沒有的欄位，例如員工數、職稱、現價、近期申報或已知漏洞。它特別區分補全與清洗（cleansing）：清洗修的是表裡已有的重複與錯字，補全加的是從不存在的事實。而且清洗要先做，因為 key 打錯，每次查詢都會 miss。
真正的新東西在第二種用法：AI agent 在做別的事時，把補全當工具呼叫。文章引 Stack Overflow 2026 年 5 月的調查，職場 AI agent 使用率一年內從 31% 升到 59%。這代表欄位必須有型別、回應要快、而且要能附上出處。
為什麼 agent 特別需要可追溯的資料
Agent 會照記錄上寫的東西行動；欄位缺失或過期，模型要嘛瞎猜，要嘛把錯誤帶進後續每一步。指南引 Validity 在 2026 年 8 月 25 日發布的報告（調查 500 位行銷專業人士）：92% 的 SVP／VP 受訪者曾按 AI 建議行動、事後懷疑是壞資料害的；只有 21% 的行銷人認為自家 CRM 資料「準備得很好」。換句話說，自主決策變多的同時，底層記錄還是破破爛爛。
每個欄位送對來源
指南最有實用價值的部分，是「按欄位路由」的原則：穩定參考欄位（總部、成立年）找資料供應商；會變動的事實（價格、庫存）讀賣家自己的頁面；事件類（融資、新聞）靠網路搜尋。文章在 2026 年 10 月 23 日對五家公司實測：provider 查詢中位數 1.8 秒、結構化抽取 1.5 秒、agentic 網路研究一次 42 秒。速度差近 30 倍，這直接決定你的 pipeline 怎麼分層。
六步流程也值得照抄：選 match key、按欄位路由、抽取成固定 schema、連同來源與時間戳一起儲存、驗證、按變動速度排程刷新。第四步是讓記錄對 agent 安全的關鍵——「2,510 名員工，People Data Labs，2026 年 10 月 23 日取得」這種欄位才能被引用、被審查。
供應商不是全都準
Firecrawl 自家對 200 家美國公司的基準測試顯示：Apollo 在四個常見欄位拿 89.3%，People Data Labs 80.6%；但員工數全行業平均只有 57%，是最弱的欄位。指南的建議很務實：每個欄位明定 agent 該信任哪個來源，員工數這種欄位驅動路由或評分前，先跟第二家供應商核對。
對工具鏈設計的啟示
Firecrawl Alexandria 把多家供應商塞進同一把 API key、MCP server 和 CLI，並附上 2026 年 9 月的測試：845 個任務中，接 Alexandria 的 agent 答題品質比用內建網路工具的 agent 高 21%（盲評）。當然這是 Firecrawl 自己做的比較，數字要打折看，但「一個介面吃到多種來源、每個欄位帶出處」這個方向本身是對的。
如果你已經在為 Claude Code 或 Codex 挑工具，這篇可以和先前的 MCP Server 比較對照讀：資料補全類 server 該怎麼選、放進哪個環節，指南給了判斷框架。下一步很具體：盤點你的 agent 會讀到哪些記錄欄位，先替「會驅動決策」的那幾個加上來源與時間戳。