1. 當(dāng) Trace 多到人眼看不完聚類就成了剛需做 Agent 開發(fā)的朋友大概率都經(jīng)歷過這個階段本地跑幾個 case 的時候Trace 面板一拉每一步的輸入輸出、工具調(diào)用、耗時、token 消耗看得清清楚楚調(diào)試起來很舒服?？梢坏┥暇€或者做一輪批量評測情況就完全變了——一天幾萬甚至幾十萬條 Session每條 Session 里又有幾十個 Span你打開可視化面板翻到第三頁就已經(jīng)不知道自己在看什么了。我最早做 Agent 可觀測性的時候踩的就是這個坑。當(dāng)時團(tuán)隊(duì)做了一個客服場景的 Agent上線第一周收集了大概 8 萬條 Session。老板問了一個特別樸素的問題用戶到底在拿它干什么哪些場景表現(xiàn)好哪些場景翻車我盯著 Trace 列表看了整整一個下午最后只能給出幾個拍腦袋的個例完全沒有說服力。問題不在于數(shù)據(jù)不夠而在于數(shù)據(jù)太多、太碎、太異構(gòu)人眼根本沒法從海量 Trace 里抽象出行為模式。這就是智能聚類要解決的核心問題把海量、零散、非結(jié)構(gòu)化的 Agent Trace通過 Embedding 和聚類算法自動歸并成若干類可解釋的行為模式讓你從看單條 Trace升級到看行為分布。它適合所有在做 Agent 開發(fā)、評測、運(yùn)維、安全分析的人尤其是那些已經(jīng)過了 Demo 階段、開始面對真實(shí)流量的人。這篇文章我會把整套思路拆開講Trace 和 Session 的數(shù)據(jù)模型怎么設(shè)計(jì)、Embedding 到底該 embed 什么、聚類算法怎么選、聚類結(jié)果怎么解釋、以及我在實(shí)際項(xiàng)目里踩過的那些坑。不講空理論全部圍繞能落地來寫。2. 先搞清楚要聚類的對象Trace、Session、Span 到底是什么關(guān)系2.1 三層數(shù)據(jù)模型別把 Session 和 Trace 混為一談很多人一開始就搞混了這幾個概念導(dǎo)致后面 Embedding 的粒度選錯聚類結(jié)果一塌糊涂。我先把它們理清楚。在典型的 Agent 可觀測體系里數(shù)據(jù)是分層的Session會話一次完整的用戶交互過程從用戶發(fā)起請求到 Agent 給出最終答復(fù)。一個 Session 可能包含多輪對話。Trace追蹤一次請求鏈路的技術(shù)性記錄通常一個 Session 對應(yīng)一個或多個 Trace。Trace 是技術(shù)視角的容器。Span跨度Trace 里的最小單元一次 LLM 調(diào)用、一次工具調(diào)用、一次檢索都是一個 Span。用生活化的類比Session 是你去醫(yī)院看了一次病Trace 是這次看病的完整病歷流水Span 是掛號、問診、化驗(yàn)、開藥每一個具體環(huán)節(jié)。為什么要強(qiáng)調(diào)這個因?yàn)榫垲惖牧６葲Q定了你能得到什么洞察聚類粒度聚合對象能回答的問題適用場景Span 級單次工具/LLM 調(diào)用哪類工具調(diào)用容易失敗工具優(yōu)化Trace 級單次請求鏈路哪類任務(wù)鏈路最長/最貴性能優(yōu)化Session 級完整多輪會話用戶到底想干什么產(chǎn)品/行為分析我個人的經(jīng)驗(yàn)是做理解 Agent 行為和表現(xiàn)Session 級聚類是主戰(zhàn)場Trace 級聚類是補(bǔ)充。因?yàn)橛脩粢鈭D往往要跨多輪才能體現(xiàn)只看單輪 Trace 會丟失上下文。2.2 一條 Session 里哪些字段值得被 Embedding確定了粒度接下來要決定把什么變成向量。這是整個流程里最關(guān)鍵的一步選錯了后面全白搭。一條 Session 通常包含這些信息用戶的多輪輸入文本Agent 的多輪輸出文本調(diào)用的工具序列tool call sequence每步的耗時、token 數(shù)、狀態(tài)碼最終是否成功、是否有用戶負(fù)反饋元數(shù)據(jù)時間、渠道、用戶 ID、模型版本不是所有字段都適合 Embedding。文本類字段用戶輸入、Agent 輸出天然適合結(jié)構(gòu)化字段耗時、狀態(tài)碼更適合作為聚類后的分析維度而不是聚類輸入。我一般會構(gòu)造一個復(fù)合文本表示把一條 Session 壓縮成一段可 Embedding 的文本類似這樣def session_to_text(session): user_turns .join([t.content for t in session.turns if t.role user]) tool_seq - .join([s.tool_name for s in session.spans if s.type tool]) return f用戶意圖: {user_turns[:500]}\n工具鏈路: {tool_seq}注意這里我做了兩件事一是截?cái)嘤脩糨斎氡苊獬L文本稀釋語義二是把工具序列也拼進(jìn)去。為什么因?yàn)楹芏?Agent 的行為差異不體現(xiàn)在文本上而體現(xiàn)在它調(diào)用了哪些工具、以什么順序調(diào)用。兩個用戶問的問題很像但一個觸發(fā)了檢索、一個直接回答這本身就是兩種行為模式。提示工具序列拼接時建議用固定的分隔符如-并且對工具名做歸一化避免同一個工具因?yàn)槊灰恢卤划?dāng)成兩個。2.3 為什么不能直接對原始 Trace JSON 做 Embedding我見過有人圖省事直接把整條 Trace 的 JSON 序列化后丟給 Embedding 模型。實(shí)測下來效果很差原因有三個第一JSON 里大量字段是技術(shù)噪音trace_id、時間戳、span_id這些對語義毫無貢獻(xiàn)反而會干擾向量表示。第二JSON 的結(jié)構(gòu)化符號括號、引號、冒號會占用大量 token稀釋真正有意義的文本。第三Embedding 模型是在自然語言上訓(xùn)練的對 JSON 這種半結(jié)構(gòu)化文本的語義捕捉能力很弱。正確的做法是先做特征工程再 Embedding。把結(jié)構(gòu)化信息轉(zhuǎn)成自然語言描述或者干脆分成兩路文本走 Embedding結(jié)構(gòu)化特征走單獨(dú)的數(shù)值聚類最后做融合。這個思路后面第 4 節(jié)會詳細(xì)展開。3. Embedding 選型不是越貴越好而是越懂你的領(lǐng)域越好3.1 通用 Embedding 模型在 Agent Trace 上的真實(shí)表現(xiàn)Embedding 模型排行網(wǎng)上到處都是但那些榜單基本都是在通用語義相似度任務(wù)上評的跟你的 Agent Trace 場景未必對得上。我實(shí)測過幾個主流方向說說真實(shí)感受。通用大模型 Embedding比如各家 API 提供的通用 embedding 接口開箱即用語義理解能力強(qiáng)對用戶輸入這種自然語言處理得很好。缺點(diǎn)是貴而且對 Agent 領(lǐng)域特有的術(shù)語工具名、內(nèi)部黑話理解一般。開源中小模型比如 BGE 系列、GTE 系列可以本地部署成本低中文支持不錯。缺點(diǎn)是維度固定長文本處理能力有限需要自己做分塊。領(lǐng)域微調(diào)模型如果你有標(biāo)注數(shù)據(jù)比如人工標(biāo)過的 Session 分類可以拿通用模型做微調(diào)。效果最好但成本最高一般團(tuán)隊(duì)到不了這一步。我的建議是先用通用 API 模型跑通流程驗(yàn)證聚類有沒有價(jià)值再考慮降本或微調(diào)。別一上來就糾結(jié)模型選型流程跑不通模型再好也沒用。3.2 維度、成本、延遲的三角權(quán)衡選 Embedding 模型繞不開三個指標(biāo)維度、成本、延遲。它們互相制約。維度方面常見的有 768、1024、1536、3072 等。維度越高表達(dá)能力越強(qiáng)但存儲和計(jì)算成本也越高。做 Session 聚類我實(shí)測 1024 維基本夠用1536 維是舒適區(qū)3072 維對聚類任務(wù)來說邊際收益很低——因?yàn)榫垲惐旧砭褪窃诮稻S找結(jié)構(gòu)輸入維度太高反而容易受噪聲影響。成本方面按 token 計(jì)費(fèi)的 API 模型一條 Session 如果壓縮到 500 token10 萬條 Session 就是 5000 萬 token這個量級要算清楚預(yù)算。本地模型雖然省 API 費(fèi)但要算 GPU 成本。延遲方面如果是離線批量聚類延遲不敏感如果要實(shí)時給每條新 Session 打標(biāo)簽?zāi)?Embedding 延遲就很重要了。我一般會做一個簡單的成本估算表方案單條成本10萬條成本延遲適用階段通用 API 大模型高高中驗(yàn)證期開源本地模型低攤薄后低低規(guī)?；⒄{(diào)模型中中低成熟期3.3 一個容易被忽略的點(diǎn)Embedding 的歸一化這個坑我踩過。不同 Embedding 模型輸出的向量有的已經(jīng)做了 L2 歸一化有的沒有。如果你混用不同來源的向量或者沒注意歸一化聚類結(jié)果會嚴(yán)重偏移。判斷方法很簡單算一下向量的模長。如果模長都接近 1說明已歸一化如果差異很大就要手動歸一化。做余弦相似度聚類時務(wù)必確保所有向量在同一尺度上。我一般會在入庫前統(tǒng)一做一次 L2 歸一化省得后面出問題。import numpy as np def l2_normalize(vecs): norms np.linalg.norm(vecs, axis1, keepdimsTrue) norms[norms 0] 1e-10 return vecs / norms4. 聚類算法怎么選K-Means 不是萬能藥4.1 先降維還是先聚類順序很重要拿到一堆高維向量第一反應(yīng)往往是先降維再聚類。但這里有個順序問題降維是為了可視化還是為了聚類如果是為了可視化畫個散點(diǎn)圖給人看那 UMAP 或 t-SNE 都行降到 2 維或 3 維。但要注意降維后的距離關(guān)系已經(jīng)失真不能拿降維后的結(jié)果去做聚類否則聚類質(zhì)量會大打折扣。如果是為了聚類正確順序是先在高維空間聚類再降維可視化。因?yàn)榫垲愃惴ㄔ诟呔S空間能捕捉到更完整的結(jié)構(gòu)降維只是為了讓你看得見。我見過有人用 t-SNE 降到 2 維再跑 K-Means結(jié)果聚出來的類完全沒有業(yè)務(wù)意義。這就是順序搞反了。4.2 K-Means、HDBSCAN、層次聚類的適用邊界不同聚類算法適合不同場景我列個對比算法是否需要預(yù)設(shè)類數(shù)能否發(fā)現(xiàn)噪聲適合的類形狀A(yù)gent Trace 場景K-Means是否球形類數(shù)已知、分布均勻HDBSCAN否是任意類數(shù)未知、有離群點(diǎn)層次聚類否否任意小數(shù)據(jù)集、要層次結(jié)構(gòu)譜聚類是否任意圖結(jié)構(gòu)數(shù)據(jù)做 Agent Trace 聚類我最推薦HDBSCAN。原因很實(shí)際你事先根本不知道用戶有多少種行為模式而且總有一批四不像的 Session比如用戶亂輸、Agent 報(bào)錯這些應(yīng)該被識別為噪聲而不是硬塞進(jìn)某個類。K-Means 會強(qiáng)行把每個點(diǎn)都分到某個類導(dǎo)致噪聲污染真實(shí)類。但 HDBSCAN 也有缺點(diǎn)參數(shù)敏感尤其是min_cluster_size調(diào)不好要么全是一個類要么全是噪聲。我的經(jīng)驗(yàn)是min_cluster_size從總樣本量的 1% 到 2% 開始試然后根據(jù)結(jié)果調(diào)整。4.3 類數(shù)到底怎么定肘部法之外的實(shí)戰(zhàn)判斷如果你非要用 K-Means那類數(shù) K 怎么定就是繞不開的問題。教科書會告訴你用肘部法或輪廓系數(shù)但實(shí)戰(zhàn)中這兩個指標(biāo)經(jīng)常給出模棱兩可的答案。我的做法是指標(biāo) 業(yè)務(wù)雙驗(yàn)證。先用輪廓系數(shù)掃一遍 K 的范圍比如 5 到 50找出幾個候選值然后對每個候選 K 跑一次聚類人工看幾個類的代表樣本判斷這個類是不是有業(yè)務(wù)意義。指標(biāo)好但業(yè)務(wù)上說不通的類直接否掉。舉個真實(shí)例子有一次輪廓系數(shù)告訴我 K12 最好但我看了聚類結(jié)果發(fā)現(xiàn)其中 4 個類其實(shí)是同一個業(yè)務(wù)場景的細(xì)分合并后 K8 反而更清晰。指標(biāo)是參考業(yè)務(wù)是裁判。5. 讓聚類結(jié)果說人話從向量簇到行為標(biāo)簽5.1 每個簇的代表樣本怎么挑聚類跑完你得到一堆簇 ID但這對業(yè)務(wù)方毫無意義。下一步是給每個簇畫像。最直接的方法是挑代表樣本。怎么挑離簇中心最近的若干條。但要注意如果用的是 HDBSCAN簇中心的概念不直接適用可以用簇內(nèi)所有點(diǎn)的均值作為近似中心。def pick_representatives(embeddings, labels, cluster_id, top_n5): mask labels cluster_id cluster_vecs embeddings[mask] center cluster_vecs.mean(axis0) dists np.linalg.norm(cluster_vecs - center, axis1) idx np.argsort(dists)[:top_n] return np.where(mask)[0][idx]挑出代表樣本后人工讀一遍就能大致總結(jié)出這個簇在講什么。這一步目前還很難完全自動化但可以用 LLM 輔助把代表樣本喂給大模型讓它生成一句行為描述。實(shí)測下來LLM 生成的描述有 70% 左右可以直接用剩下的需要人工修正。5.2 用 LLM 給簇自動打標(biāo)簽的正確姿勢讓 LLM 打標(biāo)簽關(guān)鍵在于提示詞的設(shè)計(jì)。直接問這些 Session 屬于什么類型效果一般因?yàn)?LLM 不知道你的業(yè)務(wù)分類體系。我的做法是分兩步第一步讓 LLM 從代表樣本里抽取共同特征用戶意圖、工具鏈路、結(jié)果狀態(tài)第二步基于這些特征生成一個簡短標(biāo)簽。提示詞大概長這樣以下是同一類 Agent 會話的代表樣本請總結(jié)它們的共同行為模式。 樣本1: ... 樣本2: ... 請輸出1) 用戶核心意圖 2) 典型工具鏈路 3) 一個不超過10字的標(biāo)簽這樣出來的標(biāo)簽質(zhì)量明顯更高。另外標(biāo)簽要可迭代第一輪生成的標(biāo)簽可能比較粗糙可以拿全部樣本再讓 LLM 精修一輪。5.3 標(biāo)簽體系要能掛上業(yè)務(wù)指標(biāo)光有標(biāo)簽還不夠標(biāo)簽必須能跟業(yè)務(wù)指標(biāo)掛鉤否則聚類就只是自嗨。我一般會做一張簇-指標(biāo)對照表把每個簇的樣本量、成功率、平均耗時、平均 token 消耗、負(fù)反饋率都算出來。這樣一眼就能看出哪個行為模式是高頻但低質(zhì)的哪個是低頻但高價(jià)值的。簇 ID行為標(biāo)簽樣本占比成功率平均耗時負(fù)反饋率0簡單問答35%96%1.2s2%1多輪檢索22%78%8.5s12%2工具鏈?zhǔn)?%31%15s45%3意圖不明15%60%3s20%有了這張表優(yōu)化方向就非常明確了簇 2 成功率只有 31%負(fù)反饋率 45%這就是重點(diǎn)排查對象。你可以進(jìn)一步下鉆看這個簇里工具調(diào)用失敗的具體原因。6. 我在實(shí)際項(xiàng)目里踩過的坑和對應(yīng)解法6.1 坑一Session 長度差異巨大導(dǎo)致聚類偏移Agent 的 Session 長度差異可以非?？鋸堄械木鸵惠唵柎鹩械哪芰膸资?。如果直接把整條 Session 的文本拼起來做 Embedding長 Session 的向量會被大量內(nèi)容平均掉短 Session 的向量則很集中導(dǎo)致聚類結(jié)果被長度主導(dǎo)而不是被語義主導(dǎo)。我的解法是分層處理對超長 Session 做摘要后再 Embedding或者干脆按輪次切分對每一輪單獨(dú) Embedding 后再做 Session 級聚合比如取平均或加權(quán)平均。實(shí)測下來先摘要再 Embedding 的效果更穩(wěn)定。6.2 坑二工具名不統(tǒng)一同一個工具被聚成兩類這個坑特別隱蔽。比如你的 Agent 里有個搜索工具有時候叫web_search有時候叫search有時候叫g(shù)oogle_search。Embedding 時它們會被當(dāng)成不同的東西導(dǎo)致本該屬于同一類的 Session 被拆開。解法是做工具名歸一化維護(hù)一張別名映射表把所有變體映射到統(tǒng)一名稱。這個表要定期維護(hù)因?yàn)楣ぞ邥粩嘈略觥?.3 坑三聚類結(jié)果不穩(wěn)定每次跑都不一樣K-Means 對初始中心敏感HDBSCAN 對參數(shù)敏感導(dǎo)致每次跑出來的聚類結(jié)果都不太一樣。這在需要追蹤行為變化趨勢的場景下是致命的——你沒法比較這周和上周的分布。解法有兩個一是固定隨機(jī)種子保證可復(fù)現(xiàn)二是用增量聚類把歷史簇中心保存下來新數(shù)據(jù)來了先分配到已有簇只有明顯偏離的才新建簇。這樣分布就是連續(xù)可比的。6.4 坑四把聚類當(dāng)成終點(diǎn)而不是起點(diǎn)最常見的誤區(qū)是聚類跑完、標(biāo)簽打完項(xiàng)目就結(jié)束了。但實(shí)際上聚類只是把海量數(shù)據(jù)壓縮成可理解的幾個類別真正的價(jià)值在于基于這些類別去做優(yōu)化。我一般會把聚類結(jié)果接入三個下游一是評測針對每個簇設(shè)計(jì)專門的測試用例二是告警某個簇的占比突然飆升就觸發(fā)預(yù)警三是產(chǎn)品迭代高頻低質(zhì)的簇就是優(yōu)化優(yōu)先級最高的地方。7. 從離線聚類到在線行為監(jiān)控的演進(jìn)思路離線聚類跑通之后很自然會想能不能實(shí)時監(jiān)控 Agent 的行為分布我的做法是離線建庫、在線匹配。離線階段把歷史 Session 聚成若干簇保存每個簇的中心向量和標(biāo)簽。在線階段每條新 Session 來了先做 Embedding然后計(jì)算它到各個簇中心的距離分配到最近的簇。如果距離超過閾值說明這是一個新行為先標(biāo)記為待觀察積累到一定量后再觸發(fā)一次離線聚類。這樣既保證了實(shí)時性又能持續(xù)發(fā)現(xiàn)新行為模式。閾值怎么定我一般用歷史數(shù)據(jù)的距離分布取 95 分位數(shù)作為閾值這樣只有真正偏離的行為才會被標(biāo)記。這套機(jī)制跑起來之后你對 Agent 的理解就從事后分析變成了實(shí)時感知。哪個行為模式在增長、哪個在衰退、有沒有新行為冒出來一目了然。這才是智能聚類真正的價(jià)值所在——它不是一個分析工具而是一個持續(xù)理解 Agent 行為的感知系統(tǒng)。最后分享一個我個人的小習(xí)慣每次聚類結(jié)果出來后我都會隨機(jī)抽 20 條 Session 人工讀一遍看看聚類有沒有把明顯不同的東西混在一起。這個動作花不了多少時間但能幫你及時發(fā)現(xiàn) Embedding 或聚類參數(shù)的問題。機(jī)器再智能也需要人的眼睛做最后一道校驗(yàn)。 Agent Trace智能聚類：從海量Session到行為模式洞察
1. 當(dāng) Trace 多到人眼看不完聚類就成了剛需做 Agent 開發(fā)的朋友大概率都經(jīng)歷過這個階段本地跑幾個 case 的時候Trace 面板一拉每一步的輸入輸出、工具調(diào)用、耗時、token 消耗看得清清楚楚調(diào)試起來很舒服?？梢坏┥暇€或者做一輪批量評測情況就完全變了——一天幾萬甚至幾十萬條 Session每條 Session 里又有幾十個 Span你打開可視化面板翻到第三頁就已經(jīng)不知道自己在看什么了。我最早做 Agent 可觀測性的時候踩的就是這個坑。當(dāng)時團(tuán)隊(duì)做了一個客服場景的 Agent上線第一周收集了大概 8 萬條 Session。老板問了一個特別樸素的問題用戶到底在拿它干什么哪些場景表現(xiàn)好哪些場景翻車我盯著 Trace 列表看了整整一個下午最后只能給出幾個拍腦袋的個例完全沒有說服力。問題不在于數(shù)據(jù)不夠而在于數(shù)據(jù)太多、太碎、太異構(gòu)人眼根本沒法從海量 Trace 里抽象出行為模式。這就是智能聚類要解決的核心問題把海量、零散、非結(jié)構(gòu)化的 Agent Trace通過 Embedding 和聚類算法自動歸并成若干類可解釋的行為模式讓你從看單條 Trace升級到看行為分布。它適合所有在做 Agent 開發(fā)、評測、運(yùn)維、安全分析的人尤其是那些已經(jīng)過了 Demo 階段、開始面對真實(shí)流量的人。這篇文章我會把整套思路拆開講Trace 和 Session 的數(shù)據(jù)模型怎么設(shè)計(jì)、Embedding 到底該 embed 什么、聚類算法怎么選、聚類結(jié)果怎么解釋、以及我在實(shí)際項(xiàng)目里踩過的那些坑。不講空理論全部圍繞能落地來寫。2. 先搞清楚要聚類的對象Trace、Session、Span 到底是什么關(guān)系2.1 三層數(shù)據(jù)模型別把 Session 和 Trace 混為一談很多人一開始就搞混了這幾個概念導(dǎo)致后面 Embedding 的粒度選錯聚類結(jié)果一塌糊涂。我先把它們理清楚。在典型的 Agent 可觀測體系里數(shù)據(jù)是分層的Session會話一次完整的用戶交互過程從用戶發(fā)起請求到 Agent 給出最終答復(fù)。一個 Session 可能包含多輪對話。Trace追蹤一次請求鏈路的技術(shù)性記錄通常一個 Session 對應(yīng)一個或多個 Trace。Trace 是技術(shù)視角的容器。Span跨度Trace 里的最小單元一次 LLM 調(diào)用、一次工具調(diào)用、一次檢索都是一個 Span。用生活化的類比Session 是你去醫(yī)院看了一次病Trace 是這次看病的完整病歷流水Span 是掛號、問診、化驗(yàn)、開藥每一個具體環(huán)節(jié)。為什么要強(qiáng)調(diào)這個因?yàn)榫垲惖牧６葲Q定了你能得到什么洞察聚類粒度聚合對象能回答的問題適用場景Span 級單次工具/LLM 調(diào)用哪類工具調(diào)用容易失敗工具優(yōu)化Trace 級單次請求鏈路哪類任務(wù)鏈路最長/最貴性能優(yōu)化Session 級完整多輪會話用戶到底想干什么產(chǎn)品/行為分析我個人的經(jīng)驗(yàn)是做理解 Agent 行為和表現(xiàn)Session 級聚類是主戰(zhàn)場Trace 級聚類是補(bǔ)充。因?yàn)橛脩粢鈭D往往要跨多輪才能體現(xiàn)只看單輪 Trace 會丟失上下文。2.2 一條 Session 里哪些字段值得被 Embedding確定了粒度接下來要決定把什么變成向量。這是整個流程里最關(guān)鍵的一步選錯了后面全白搭。一條 Session 通常包含這些信息用戶的多輪輸入文本Agent 的多輪輸出文本調(diào)用的工具序列tool call sequence每步的耗時、token 數(shù)、狀態(tài)碼最終是否成功、是否有用戶負(fù)反饋元數(shù)據(jù)時間、渠道、用戶 ID、模型版本不是所有字段都適合 Embedding。文本類字段用戶輸入、Agent 輸出天然適合結(jié)構(gòu)化字段耗時、狀態(tài)碼更適合作為聚類后的分析維度而不是聚類輸入。我一般會構(gòu)造一個復(fù)合文本表示把一條 Session 壓縮成一段可 Embedding 的文本類似這樣def session_to_text(session): user_turns .join([t.content for t in session.turns if t.role user]) tool_seq - .join([s.tool_name for s in session.spans if s.type tool]) return f用戶意圖: {user_turns[:500]}\n工具鏈路: {tool_seq}注意這里我做了兩件事一是截?cái)嘤脩糨斎氡苊獬L文本稀釋語義二是把工具序列也拼進(jìn)去。為什么因?yàn)楹芏?Agent 的行為差異不體現(xiàn)在文本上而體現(xiàn)在它調(diào)用了哪些工具、以什么順序調(diào)用。兩個用戶問的問題很像但一個觸發(fā)了檢索、一個直接回答這本身就是兩種行為模式。提示工具序列拼接時建議用固定的分隔符如-并且對工具名做歸一化避免同一個工具因?yàn)槊灰恢卤划?dāng)成兩個。2.3 為什么不能直接對原始 Trace JSON 做 Embedding我見過有人圖省事直接把整條 Trace 的 JSON 序列化后丟給 Embedding 模型。實(shí)測下來效果很差原因有三個第一JSON 里大量字段是技術(shù)噪音trace_id、時間戳、span_id這些對語義毫無貢獻(xiàn)反而會干擾向量表示。第二JSON 的結(jié)構(gòu)化符號括號、引號、冒號會占用大量 token稀釋真正有意義的文本。第三Embedding 模型是在自然語言上訓(xùn)練的對 JSON 這種半結(jié)構(gòu)化文本的語義捕捉能力很弱。正確的做法是先做特征工程再 Embedding。把結(jié)構(gòu)化信息轉(zhuǎn)成自然語言描述或者干脆分成兩路文本走 Embedding結(jié)構(gòu)化特征走單獨(dú)的數(shù)值聚類最后做融合。這個思路后面第 4 節(jié)會詳細(xì)展開。3. Embedding 選型不是越貴越好而是越懂你的領(lǐng)域越好3.1 通用 Embedding 模型在 Agent Trace 上的真實(shí)表現(xiàn)Embedding 模型排行網(wǎng)上到處都是但那些榜單基本都是在通用語義相似度任務(wù)上評的跟你的 Agent Trace 場景未必對得上。我實(shí)測過幾個主流方向說說真實(shí)感受。通用大模型 Embedding比如各家 API 提供的通用 embedding 接口開箱即用語義理解能力強(qiáng)對用戶輸入這種自然語言處理得很好。缺點(diǎn)是貴而且對 Agent 領(lǐng)域特有的術(shù)語工具名、內(nèi)部黑話理解一般。開源中小模型比如 BGE 系列、GTE 系列可以本地部署成本低中文支持不錯。缺點(diǎn)是維度固定長文本處理能力有限需要自己做分塊。領(lǐng)域微調(diào)模型如果你有標(biāo)注數(shù)據(jù)比如人工標(biāo)過的 Session 分類可以拿通用模型做微調(diào)。效果最好但成本最高一般團(tuán)隊(duì)到不了這一步。我的建議是先用通用 API 模型跑通流程驗(yàn)證聚類有沒有價(jià)值再考慮降本或微調(diào)。別一上來就糾結(jié)模型選型流程跑不通模型再好也沒用。3.2 維度、成本、延遲的三角權(quán)衡選 Embedding 模型繞不開三個指標(biāo)維度、成本、延遲。它們互相制約。維度方面常見的有 768、1024、1536、3072 等。維度越高表達(dá)能力越強(qiáng)但存儲和計(jì)算成本也越高。做 Session 聚類我實(shí)測 1024 維基本夠用1536 維是舒適區(qū)3072 維對聚類任務(wù)來說邊際收益很低——因?yàn)榫垲惐旧砭褪窃诮稻S找結(jié)構(gòu)輸入維度太高反而容易受噪聲影響。成本方面按 token 計(jì)費(fèi)的 API 模型一條 Session 如果壓縮到 500 token10 萬條 Session 就是 5000 萬 token這個量級要算清楚預(yù)算。本地模型雖然省 API 費(fèi)但要算 GPU 成本。延遲方面如果是離線批量聚類延遲不敏感如果要實(shí)時給每條新 Session 打標(biāo)簽?zāi)?Embedding 延遲就很重要了。我一般會做一個簡單的成本估算表方案單條成本10萬條成本延遲適用階段通用 API 大模型高高中驗(yàn)證期開源本地模型低攤薄后低低規(guī)?；⒄{(diào)模型中中低成熟期3.3 一個容易被忽略的點(diǎn)Embedding 的歸一化這個坑我踩過。不同 Embedding 模型輸出的向量有的已經(jīng)做了 L2 歸一化有的沒有。如果你混用不同來源的向量或者沒注意歸一化聚類結(jié)果會嚴(yán)重偏移。判斷方法很簡單算一下向量的模長。如果模長都接近 1說明已歸一化如果差異很大就要手動歸一化。做余弦相似度聚類時務(wù)必確保所有向量在同一尺度上。我一般會在入庫前統(tǒng)一做一次 L2 歸一化省得后面出問題。import numpy as np def l2_normalize(vecs): norms np.linalg.norm(vecs, axis1, keepdimsTrue) norms[norms 0] 1e-10 return vecs / norms4. 聚類算法怎么選K-Means 不是萬能藥4.1 先降維還是先聚類順序很重要拿到一堆高維向量第一反應(yīng)往往是先降維再聚類。但這里有個順序問題降維是為了可視化還是為了聚類如果是為了可視化畫個散點(diǎn)圖給人看那 UMAP 或 t-SNE 都行降到 2 維或 3 維。但要注意降維后的距離關(guān)系已經(jīng)失真不能拿降維后的結(jié)果去做聚類否則聚類質(zhì)量會大打折扣。如果是為了聚類正確順序是先在高維空間聚類再降維可視化。因?yàn)榫垲愃惴ㄔ诟呔S空間能捕捉到更完整的結(jié)構(gòu)降維只是為了讓你看得見。我見過有人用 t-SNE 降到 2 維再跑 K-Means結(jié)果聚出來的類完全沒有業(yè)務(wù)意義。這就是順序搞反了。4.2 K-Means、HDBSCAN、層次聚類的適用邊界不同聚類算法適合不同場景我列個對比算法是否需要預(yù)設(shè)類數(shù)能否發(fā)現(xiàn)噪聲適合的類形狀A(yù)gent Trace 場景K-Means是否球形類數(shù)已知、分布均勻HDBSCAN否是任意類數(shù)未知、有離群點(diǎn)層次聚類否否任意小數(shù)據(jù)集、要層次結(jié)構(gòu)譜聚類是否任意圖結(jié)構(gòu)數(shù)據(jù)做 Agent Trace 聚類我最推薦HDBSCAN。原因很實(shí)際你事先根本不知道用戶有多少種行為模式而且總有一批四不像的 Session比如用戶亂輸、Agent 報(bào)錯這些應(yīng)該被識別為噪聲而不是硬塞進(jìn)某個類。K-Means 會強(qiáng)行把每個點(diǎn)都分到某個類導(dǎo)致噪聲污染真實(shí)類。但 HDBSCAN 也有缺點(diǎn)參數(shù)敏感尤其是min_cluster_size調(diào)不好要么全是一個類要么全是噪聲。我的經(jīng)驗(yàn)是min_cluster_size從總樣本量的 1% 到 2% 開始試然后根據(jù)結(jié)果調(diào)整。4.3 類數(shù)到底怎么定肘部法之外的實(shí)戰(zhàn)判斷如果你非要用 K-Means那類數(shù) K 怎么定就是繞不開的問題。教科書會告訴你用肘部法或輪廓系數(shù)但實(shí)戰(zhàn)中這兩個指標(biāo)經(jīng)常給出模棱兩可的答案。我的做法是指標(biāo) 業(yè)務(wù)雙驗(yàn)證。先用輪廓系數(shù)掃一遍 K 的范圍比如 5 到 50找出幾個候選值然后對每個候選 K 跑一次聚類人工看幾個類的代表樣本判斷這個類是不是有業(yè)務(wù)意義。指標(biāo)好但業(yè)務(wù)上說不通的類直接否掉。舉個真實(shí)例子有一次輪廓系數(shù)告訴我 K12 最好但我看了聚類結(jié)果發(fā)現(xiàn)其中 4 個類其實(shí)是同一個業(yè)務(wù)場景的細(xì)分合并后 K8 反而更清晰。指標(biāo)是參考業(yè)務(wù)是裁判。5. 讓聚類結(jié)果說人話從向量簇到行為標(biāo)簽5.1 每個簇的代表樣本怎么挑聚類跑完你得到一堆簇 ID但這對業(yè)務(wù)方毫無意義。下一步是給每個簇畫像。最直接的方法是挑代表樣本。怎么挑離簇中心最近的若干條。但要注意如果用的是 HDBSCAN簇中心的概念不直接適用可以用簇內(nèi)所有點(diǎn)的均值作為近似中心。def pick_representatives(embeddings, labels, cluster_id, top_n5): mask labels cluster_id cluster_vecs embeddings[mask] center cluster_vecs.mean(axis0) dists np.linalg.norm(cluster_vecs - center, axis1) idx np.argsort(dists)[:top_n] return np.where(mask)[0][idx]挑出代表樣本后人工讀一遍就能大致總結(jié)出這個簇在講什么。這一步目前還很難完全自動化但可以用 LLM 輔助把代表樣本喂給大模型讓它生成一句行為描述。實(shí)測下來LLM 生成的描述有 70% 左右可以直接用剩下的需要人工修正。5.2 用 LLM 給簇自動打標(biāo)簽的正確姿勢讓 LLM 打標(biāo)簽關(guān)鍵在于提示詞的設(shè)計(jì)。直接問這些 Session 屬于什么類型效果一般因?yàn)?LLM 不知道你的業(yè)務(wù)分類體系。我的做法是分兩步第一步讓 LLM 從代表樣本里抽取共同特征用戶意圖、工具鏈路、結(jié)果狀態(tài)第二步基于這些特征生成一個簡短標(biāo)簽。提示詞大概長這樣以下是同一類 Agent 會話的代表樣本請總結(jié)它們的共同行為模式。 樣本1: ... 樣本2: ... 請輸出1) 用戶核心意圖 2) 典型工具鏈路 3) 一個不超過10字的標(biāo)簽這樣出來的標(biāo)簽質(zhì)量明顯更高。另外標(biāo)簽要可迭代第一輪生成的標(biāo)簽可能比較粗糙可以拿全部樣本再讓 LLM 精修一輪。5.3 標(biāo)簽體系要能掛上業(yè)務(wù)指標(biāo)光有標(biāo)簽還不夠標(biāo)簽必須能跟業(yè)務(wù)指標(biāo)掛鉤否則聚類就只是自嗨。我一般會做一張簇-指標(biāo)對照表把每個簇的樣本量、成功率、平均耗時、平均 token 消耗、負(fù)反饋率都算出來。這樣一眼就能看出哪個行為模式是高頻但低質(zhì)的哪個是低頻但高價(jià)值的。簇 ID行為標(biāo)簽樣本占比成功率平均耗時負(fù)反饋率0簡單問答35%96%1.2s2%1多輪檢索22%78%8.5s12%2工具鏈?zhǔn)?%31%15s45%3意圖不明15%60%3s20%有了這張表優(yōu)化方向就非常明確了簇 2 成功率只有 31%負(fù)反饋率 45%這就是重點(diǎn)排查對象。你可以進(jìn)一步下鉆看這個簇里工具調(diào)用失敗的具體原因。6. 我在實(shí)際項(xiàng)目里踩過的坑和對應(yīng)解法6.1 坑一Session 長度差異巨大導(dǎo)致聚類偏移Agent 的 Session 長度差異可以非?？鋸堄械木鸵惠唵柎鹩械哪芰膸资?。如果直接把整條 Session 的文本拼起來做 Embedding長 Session 的向量會被大量內(nèi)容平均掉短 Session 的向量則很集中導(dǎo)致聚類結(jié)果被長度主導(dǎo)而不是被語義主導(dǎo)。我的解法是分層處理對超長 Session 做摘要后再 Embedding或者干脆按輪次切分對每一輪單獨(dú) Embedding 后再做 Session 級聚合比如取平均或加權(quán)平均。實(shí)測下來先摘要再 Embedding 的效果更穩(wěn)定。6.2 坑二工具名不統(tǒng)一同一個工具被聚成兩類這個坑特別隱蔽。比如你的 Agent 里有個搜索工具有時候叫web_search有時候叫search有時候叫g(shù)oogle_search。Embedding 時它們會被當(dāng)成不同的東西導(dǎo)致本該屬于同一類的 Session 被拆開。解法是做工具名歸一化維護(hù)一張別名映射表把所有變體映射到統(tǒng)一名稱。這個表要定期維護(hù)因?yàn)楣ぞ邥粩嘈略觥?.3 坑三聚類結(jié)果不穩(wěn)定每次跑都不一樣K-Means 對初始中心敏感HDBSCAN 對參數(shù)敏感導(dǎo)致每次跑出來的聚類結(jié)果都不太一樣。這在需要追蹤行為變化趨勢的場景下是致命的——你沒法比較這周和上周的分布。解法有兩個一是固定隨機(jī)種子保證可復(fù)現(xiàn)二是用增量聚類把歷史簇中心保存下來新數(shù)據(jù)來了先分配到已有簇只有明顯偏離的才新建簇。這樣分布就是連續(xù)可比的。6.4 坑四把聚類當(dāng)成終點(diǎn)而不是起點(diǎn)最常見的誤區(qū)是聚類跑完、標(biāo)簽打完項(xiàng)目就結(jié)束了。但實(shí)際上聚類只是把海量數(shù)據(jù)壓縮成可理解的幾個類別真正的價(jià)值在于基于這些類別去做優(yōu)化。我一般會把聚類結(jié)果接入三個下游一是評測針對每個簇設(shè)計(jì)專門的測試用例二是告警某個簇的占比突然飆升就觸發(fā)預(yù)警三是產(chǎn)品迭代高頻低質(zhì)的簇就是優(yōu)化優(yōu)先級最高的地方。7. 從離線聚類到在線行為監(jiān)控的演進(jìn)思路離線聚類跑通之后很自然會想能不能實(shí)時監(jiān)控 Agent 的行為分布我的做法是離線建庫、在線匹配。離線階段把歷史 Session 聚成若干簇保存每個簇的中心向量和標(biāo)簽。在線階段每條新 Session 來了先做 Embedding然后計(jì)算它到各個簇中心的距離分配到最近的簇。如果距離超過閾值說明這是一個新行為先標(biāo)記為待觀察積累到一定量后再觸發(fā)一次離線聚類。這樣既保證了實(shí)時性又能持續(xù)發(fā)現(xiàn)新行為模式。閾值怎么定我一般用歷史數(shù)據(jù)的距離分布取 95 分位數(shù)作為閾值這樣只有真正偏離的行為才會被標(biāo)記。這套機(jī)制跑起來之后你對 Agent 的理解就從事后分析變成了實(shí)時感知。哪個行為模式在增長、哪個在衰退、有沒有新行為冒出來一目了然。這才是智能聚類真正的價(jià)值所在——它不是一個分析工具而是一個持續(xù)理解 Agent 行為的感知系統(tǒng)。最后分享一個我個人的小習(xí)慣每次聚類結(jié)果出來后我都會隨機(jī)抽 20 條 Session 人工讀一遍看看聚類有沒有把明顯不同的東西混在一起。這個動作花不了多少時間但能幫你及時發(fā)現(xiàn) Embedding 或聚類參數(shù)的問題。機(jī)器再智能也需要人的眼睛做最后一道校驗(yàn)。