人工智能AI AgentAgent 框架后端多智能體RAG工具調(diào)用Agent 記憶【免費(fèi)下載鏈接】voltagentAI Agent Engineering Platform built on an Open Source TypeScript AI Agent Framework項(xiàng)目地址https://gitcode.com/gh_mirrors/vo/voltagent點(diǎn)擊查看免費(fèi)下載在 VoltAgent 的 VoltOps 可觀測(cè)平臺(tái)中User Analytics用戶分析頁(yè)面把零散的 trace 按用戶維度重新組織讓你從感覺哪里不對(duì)勁快速定位到具體的用戶、會(huì)話session/conversation乃至單條 trace。本文基于官方文檔 User Analytics 展開并結(jié)合倉(cāng)庫(kù)中 OpenTelemetry 埋點(diǎn)與導(dǎo)出的源碼實(shí)現(xiàn)講清楚用戶與會(huì)話標(biāo)識(shí)是如何進(jìn)入 trace 體系的、Users 頁(yè)面上三大模塊Key Metrics、User Feedback、Conversations各自解決什么問題以及如何設(shè)計(jì)一次從指標(biāo)異常到單條 trace 的完整排查路徑。為什么需要按用戶維度看 Trace單條 trace 回答的是這一次請(qǐng)求內(nèi)部發(fā)生了什么而用戶問題往往跨越多次請(qǐng)求某個(gè)用戶連續(xù)三天不滿意、某類會(huì)話成本異常高、某個(gè)版本發(fā)布后特定用戶群的成功率下降。Users 頁(yè)面正是為此設(shè)計(jì)的聚合視圖——它按 user 分組 trace幫助你判斷問題影響了誰、集中在哪里which user is impacted and where issues concentrate。排查路徑因此被壓縮為三級(jí)跳轉(zhuǎn)用戶 → 會(huì)話Conversation/Session→ 單條 Trace。這與 Tracing 總覽 中的過濾器設(shè)計(jì)一脈相承總覽頁(yè)提供 Status、Duration、Token usage / Cost、User ID / Conversation ID 等過濾條件其中User ID / Conversation ID過濾器就是專門用來鉆進(jìn)某一個(gè)用戶旅程的入口與 Users 頁(yè)面形成互補(bǔ)。前置條件讓 trace 帶上用戶與會(huì)話標(biāo)識(shí)Users 頁(yè)面的分組能力依賴于每條 trace 上攜帶用戶與會(huì)話信息。在 VoltAgent 中這一步通過agent.run的運(yùn)行選項(xiàng)完成參考 Observability Setup 文檔const agent new Agent({ name: Support Agent, model: openai(gpt-4), instructions: Help users with their questions, }); await agent.run(Hello, { userId: user-123, conversationId: conv-456, });字段說明userId將 trace 關(guān)聯(lián)到具體用戶Associates traces with a specific userconversationId按會(huì)話對(duì) trace 進(jìn)行分組Groups traces by conversation從源碼結(jié)構(gòu)看這兩個(gè)選項(xiàng)最終落成 OpenTelemetry 的 span 屬性并且是公共屬性——在 trace-context.ts 中TraceContext構(gòu)造時(shí)會(huì)把user.id、conversation.id以及operation.id、父 agent 信息等寫入commonAttributes被該次運(yùn)行的所有子 span 繼承// Store common attributes once - these will be inherited by all child spans const commonAttributes: Recordstring, any { ...(options.userId { user.id: options.userId }), ...(options.conversationId { conversation.id: options.conversationId }), ...(parentAgentId { agent.parent.id: parentAgentId }), ...(parentAgentName { agent.parent.name: parentAgentName }), operation.id: options.operationId, };這意味著無論一次運(yùn)行中發(fā)生多少次 LLM 調(diào)用、多少次工具執(zhí)行用戶與會(huì)話標(biāo)識(shí)都會(huì)隨整條 trace 鏈路一起上報(bào)為后續(xù)按用戶/會(huì)話聚合提供了數(shù)據(jù)基礎(chǔ)。數(shù)據(jù)如何到達(dá)觀測(cè)平臺(tái)兩條上報(bào)路徑根據(jù)部署形態(tài)trace 可以走兩條路徑二者在用戶/會(huì)話如何映射為 trace 級(jí)字段上的邏輯是文檔排查的關(guān)鍵VoltOps 托管路徑自動(dòng)檢測(cè)在 Setup 文檔 中說明配置VOLTAGENT_PUBLIC_KEYpk_xxxx與VOLTAGENT_SECRET_KEYsk_live_xxxx兩個(gè)環(huán)境變量后VoltAgent 會(huì)自動(dòng)檢測(cè)并連接 VoltOps無需額外觀測(cè)代碼需要更細(xì)粒度控制時(shí)可用VoltOpsClient顯式傳入密鑰或用createVoltAgentObservability配置服務(wù)名、采樣策略always/never/ratio/parent、隊(duì)列與批量導(dǎo)出參數(shù)等。Langfuse 自托管路徑LangfuseExporter 作為 OpenTelemetrySpanExporter實(shí)現(xiàn)把 span 批轉(zhuǎn)換為 Langfuse 的 trace/span/generation通過 README 中的示例掛載到VoltAgent的telemetryExporterimport { Agent, VoltAgent } from voltagent/core; import { LangfuseExporter } from voltagent/langfuse-exporter; const langfuseExporter new LangfuseExporter({ publicKey: process.env.LANGFUSE_PUBLIC_KEY, secretKey: process.env.LANGFUSE_SECRET_KEY, baseUrl: process.env.LANGFUSE_BASE_URL, // 可選默認(rèn) Langfuse Cloud // debug: true, // 可選開啟導(dǎo)出器詳細(xì)日志 }); new VoltAgent({ agents: { myAgent }, telemetryExporter: langfuseExporter, });LangfuseExporter在export時(shí)按traceId將本批 span 分組逐 trace 調(diào)用processTraceSpans其中的extractTraceInfo負(fù)責(zé)從任意 span 的屬性里提取 trace 級(jí)信息用戶與會(huì)話的取值優(yōu)先級(jí)值得注意exporter.ts用戶 ID優(yōu)先enduser.id其次user.id會(huì)話 ID優(yōu)先session.id其次conversation.idtrace 名稱優(yōu)先voltagent.agent.name其次entity.name另外還會(huì)提取tags、langfuseTraceId、langfuseUpdateParent。當(dāng)updateParent為真默認(rèn)值時(shí)buildTraceParams會(huì)把userId、sessionId、tags、輸入輸出、metadata 與模型名寫入 trace 記錄exporter.ts。這也解釋了為什么在應(yīng)用側(cè)只傳userId/conversationId兩個(gè)字段平臺(tái)側(cè)就擁有了 Users 頁(yè)面所需的分組鍵。Users 頁(yè)面模塊一Key Metrics關(guān)鍵指標(biāo)Key Metrics 提供對(duì)**請(qǐng)求量volume、成功率success rate、延遲latency、成本cost**隨時(shí)間變化的快速縱覽。官方文檔給出的使用定位是用它判斷當(dāng)前問題屬于質(zhì)量、性能還是花費(fèi)中的哪一類并把回歸regression關(guān)聯(lián)到模型切換等變更上。實(shí)操建議是把 Key Metrics 當(dāng)作排查的第一道分診臺(tái)成功率下跌→ 優(yōu)先在 trace 列表用 Status 過濾器隔離失敗或重試較多的運(yùn)行再進(jìn)入具體 trace 的 Waterfall 視圖看哪一步失敗延遲抬升→ 結(jié)合 Duration 過濾器找慢 trace關(guān)注 LLM 調(diào)用的首 chunk 延遲與工具調(diào)用耗時(shí)成本突增→ 用 Token usage / Cost 過濾器定位高價(jià)運(yùn)行并核對(duì)是否與模型切換、prompt 變長(zhǎng)相關(guān)——這正是文檔強(qiáng)調(diào)link regressions to model switches的場(chǎng)景。Users 頁(yè)面模塊二User Feedback用戶反饋User Feedback 模塊把用戶情緒轉(zhuǎn)化為可跟蹤的信號(hào)一方面用于確認(rèn)修復(fù)是否真正改善了體驗(yàn)對(duì)比修復(fù)前后另一方面用于看清用戶最在意哪些問題。文檔說明該模塊的圖表可以呈現(xiàn)反饋量feedback volume、情緒趨勢(shì)sentiment trends、評(píng)分聚集score clusters、主導(dǎo)反饋鍵dominant feedback keys以及用戶留下評(píng)論的時(shí)間點(diǎn)。這與單條 trace 級(jí)的 Trace Feedback 文檔構(gòu)成總—分關(guān)系trace 級(jí)反饋關(guān)注三個(gè)要點(diǎn)——History 與來源確認(rèn)這條 trace 被評(píng)過分、評(píng)分來自 app/API/model 哪一端、Key 與 Score保持信號(hào)一致例如統(tǒng)一使用 satisfaction 鍵以便跨運(yùn)行比較、Comments用簡(jiǎn)短上下文說明輸出為何好或壞。排查時(shí)的組合打法是在 Users 頁(yè)的反饋圖表中發(fā)現(xiàn)某類反饋鍵差評(píng)聚集再通過反饋源/反饋鍵過濾器下鉆到具體 trace核對(duì)評(píng)論與當(dāng)時(shí)的模型輸出。Users 頁(yè)面模塊三Conversations會(huì)話視圖Conversations 模塊按 session會(huì)話分組 trace讓你能端到端地跟隨一條用戶流程。每個(gè)會(huì)話以卡片形式呈現(xiàn)四個(gè)字段Status該會(huì)話內(nèi)運(yùn)行是否出現(xiàn)失敗Time range會(huì)話的時(shí)間跨度幫助區(qū)分長(zhǎng)對(duì)話與一次性請(qǐng)求Model會(huì)話中使用的模型便于關(guān)聯(lián)模型切換帶來的行為差異Cost會(huì)話累計(jì)成本用于發(fā)現(xiàn)異常昂貴的對(duì)話流。文檔給出的使用手法很直接從卡片中挑出最可疑的會(huì)話然后把 trace 列表過濾到該會(huì)話路徑上繼續(xù)分析。結(jié)合前文源碼部分可知會(huì)話卡片的數(shù)據(jù)基礎(chǔ)正是運(yùn)行選項(xiàng)conversationId寫入的conversation.id屬性——若你的應(yīng)用沒有為多輪對(duì)話維持穩(wěn)定的conversationIdConversations 視圖就無法把多輪 trace 歸并為一個(gè)會(huì)話這一點(diǎn)在集成時(shí)值得優(yōu)先保證。一次典型排查路徑從指標(biāo)到 trace綜合上述模塊可以沉淀出如下可復(fù)現(xiàn)的排查流程分診在 Users 頁(yè) Key Metrics 中確認(rèn)異常維度成功率 / 延遲 / 成本與時(shí)間范圍定位用戶查看受影響用戶列表找到問題集中的用戶定位會(huì)話在 Conversations 中按 Status / Time range / Model / Cost 四張卡片鎖定最可疑會(huì)話下鉆 trace把 trace 列表過濾到該會(huì)話結(jié)合 總覽文檔 中的 Status、Duration、Token usage / Cost 過濾器找到失敗或昂貴的單條運(yùn)行歸因與驗(yàn)證打開 Waterfall / Node-Based 視圖定位失敗步驟并檢查 User Feedback 與 trace 級(jí) Feedback來源、key、score、comment修復(fù)后再回到 Key Metrics 與反饋趨勢(shì)圖驗(yàn)證指標(biāo)與情緒是否回升。小結(jié)與適用前提Users 頁(yè)面的三大模塊各有分工Key Metrics 判斷問題類型User Feedback 判斷用戶感受Conversations 定位具體哪條會(huì)話路徑分組能力的前提是應(yīng)用側(cè)在agent.run中正確傳入userId與conversationId它們?cè)?trace-context.ts 中成為全鏈路繼承的公共屬性上報(bào)路徑支持 VoltOps 環(huán)境變量自動(dòng)接入與LangfuseExporter自托管兩種形態(tài)自托管路徑的用戶/會(huì)話字段映射邏輯可在 exporter.ts 中直接查閱本文描述的行為以當(dāng)前倉(cāng)庫(kù)文檔與源碼為準(zhǔn)控制臺(tái)的展示細(xì)節(jié)如圖表具體樣式可能隨平臺(tái)版本演進(jìn)建議以實(shí)際 Setup 后在控制臺(tái)中觀察到的界面為準(zhǔn)。贊分享人工智能AI AgentAgent 框架后端多智能體RAG工具調(diào)用Agent 記憶【免費(fèi)下載鏈接】voltagentAI Agent Engineering Platform built on an Open Source TypeScript AI Agent Framework項(xiàng)目地址https://gitcode.com/gh_mirrors/vo/voltagent點(diǎn)擊查看免費(fèi)下載相關(guān)推薦es-toolkit 的 invertBy 使用指南反向映射對(duì)象鍵值并按組聚合es toolkit 的 invertBy 使用指南反向映射對(duì)象鍵值并按組聚合 invertBy 是 es toolkit 的 lodash 兼容層 es前端后端agno 如何讀取 Agent 運(yùn)行軌跡的 trace 并聚合按天的 metrics 指標(biāo)agno 如何讀取 Agent 運(yùn)行軌跡的 trace 并聚合按天的 metrics 指標(biāo) 在 agno 的 AgentOS 上運(yùn)行 Agent 后你會(huì)經(jīng)常人工智能大模型AI AgentAgent 框架多智能體工具調(diào)用RAGAgent 工作流Agent 記憶Hugo Pages.GroupByPublishDate 方法詳解按發(fā)布時(shí)間分組頁(yè)面并排序Hugo Pages.GroupByPublishDate 方法詳解按發(fā)布時(shí)間分組頁(yè)面并排序 本文是 Hugo 頁(yè)面集合方法系列中的一篇聚焦于 Pages.開發(fā)工具前端CLI上一篇Obsidian中文社區(qū)論壇免費(fèi)開源5 分鐘跑起來的 Markdown 論壇下一篇m4s轉(zhuǎn)mp4保姆級(jí)教程3 步合并B站緩存視頻換設(shè)備也能隨時(shí)看創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考