摘要： LangChain 在 2026 年 10 月 13 日為 LangSmith 推出 AI Search：用白話描述一種行為，例如「使用者是不是挫敗了」或「PII 有沒有外洩」，系統就會回傳發生這件事的 trace。這把過去要預先設定 evaluator 或人工翻找的工作，變成一次 ad hoc 查詢，對做 agent 產品的人來說，這是從「看得見 log」到「問得出問題」的差別。
為什麼傳統搜尋找不到這些答案
Agent trace 的價值在於它記錄了使用者輸入、agent 的推理、工具呼叫和回應——理解 agent 哪裡做得好、哪裡失敗所需的資訊都在裡面。但「使用者有沒有放棄」「agent 說做完了其實沒做」這類問題，無法對應到 tag 或 metadata，全文檢索也派不上用場，因為答案藏在內容的語意裡，不是關鍵字裡。
LangChain 在公告中舉的例子很具體：產品團隊可以搜「要求了我們不支援的整合」「提到競品」「使用者對 onboarding 感到困惑」，直接在使用者自己的話裡看到產品缺口。AI Search 也能搭配既有的結構化篩選，例如只在出錯的 trace、或只在某個 tag 底下搜。
為什麼不用 vector search 就好
這是技術上最值得細看的取捨。向量搜尋把整條 trace 壓縮成一個 embedding，適合找主題，但壓縮是有損的——一條「真的把事做完」的 trace，和一條「只是嘴上說做完」的 trace，embedding 可能非常接近。要分辨這種差異，需要一個真的逐字閱讀 trace 並對照你的問題去推理的模型。
過去在查詢時這樣做太慢太貴，但快速決策模型改變了成本結構：它只回答一個窄問題，速度快到可以對每條 trace 都跑一次。LangChain 的做法是結構化篩選先縮小候選集，決策模型再逐一比對，批次並行處理，比對中的同時預抓下一批，命中的結果邊找邊串流回來。
Trajectory：統一格式與砍掉重複
Trace 來源五花八門——OpenAI、Anthropic 的 SDK、LangChain、LangGraph、Vercel AI SDK、OpenTelemetry，各自記錄方式不同。而且 agent 常常每次 LLM 呼叫都重送整段對話歷史，同一句話出現幾十次。SmithDB 在 trace 進來時把它們轉成 trajectory：整個 session 的訊息、工具呼叫、工具結果各列一次，所有格式攤平成同一種形狀。好處是一套搜尋可以跨不同 SDK 建的 agent 使用，砍掉重複也降低了要餵給模型的 context。
但 trajectory 還是很長。LangChain 從自家每天都在用的開源 coding agent Open SWE 抽樣了 150 條對話：中位數長達 72K tokens，其中約 85% 是工具輸出（主要是檔案讀取和 shell 指令），使用者訊息加 agent 回覆只占約 2K。有幾條甚至超過一百萬 tokens。
這個數字背後的洞察是：多數關於 agent 行為的問題，答案就在使用者和 agent 說了什麼。所以 AI Search 給每條 trajectory 一個 8K token 的固定預算，按優先序填入——使用者和 agent 對使用者的回覆先進，剩餘空間才給中間推理、工具結果和系統訊息。
Builder 該注意的兩個限制
LangChain 自己點出了兩個未解問題。第一，8K 預算適合「對話裡找得到答案」的問題，但「agent 忽略了工具錯誤」這類行為只出現在工具結果裡，優先序排後面可能被裁掉。第二，細微差異的分類仍不可靠——「使用者放棄了」和「使用者得到答案滿意離開」，差別可能就在長 trajectory 裡的一兩個 turn。團隊正在實驗用 trace 資料微調模型、以及讓模型在不確定時帶更多 context 做第二輪。
這種「先統一表示、再按問題優先級分配 context」的思路，其實和我在另一篇談 context 壓縮時機裡整理的方向一致：關鍵不是壓得多狠，而是決定哪些內容值得留下來。AI Search 把這件事做成了查詢基礎設施。
目前 AI Search 在 LangSmith Cloud 的 GCP 美國、歐盟、亞太區域開放公測，不加收費用，由 org 管理員在設定中開啟。實務上的下一步很簡單：把你過去人工翻 trace 找的那幾類問題（挫敗、放棄、PII、取消訂閱）拿來跑一輪，看看決策模型的判斷和你的直覺差多少——差異本身就是一份現成的 eval 資料集。
參考來源
在 X 上查看原貼文